Assimilate Popular Workflows

Mapping Process

For each extractable process identified in Phase 3 research documents:

1. Search for existing implementations:

   # Look for similar process names/concepts
   find library -name "*.js" -type f | grep -i "<process-concept>"
   
   # Check for methodology matches
   ls library/methodologies/
   
   # Check specialization domains
   ls library/specializations/

2. Classify the relationship:

   • UPGRADE - existing process that could be enhanced with new patterns/insights from the repo
   • VARIANT - similar process that could be generalized or adapted
   • NEW - novel process not represented in the library
   • OBSOLETE - existing process that could be replaced with superior approach from repo

3. Document the mapping: Add a "Library Mapping" section to each research.md:

   ## Library Mapping
   
   | Extractable Process | Library Status | Action | Existing Path | Target Placement |
   |-------------------|----------------|--------|---------------|------------------|
   | Superpowers Debugging | UPGRADE | Enhance with new TDD integration patterns | methodologies/superpowers/superpowers-workflow.js | methodologies/superpowers/ (enhancement) |
   | TDD Workflow | VARIANT | Could generalize atdd-tdd with pure TDD variant | methodologies/atdd-tdd/atdd-tdd.js | methodologies/pure-tdd/ (new variant) |
   | Research Pipeline | NEW | Novel 23-stage autonomous research methodology | - | specializations/shared/autonomous-research.js |
   | Security Audit | NEW | K8s security scanning process | - | specializations/security-compliance/k8s-security-audit.js |

   Library placement rules for Target Placement:

   • methodologies/[name]/: Full generic dev methodologies only (agile, tdd, scrum, kanban)
   • specializations/shared/: Cross-domain reusable patterns (audit-pipeline, research-methodology)
   • specializations/[domain]/: Domain-specific processes:
     • security-compliance/ - Security, compliance, auditing, scanning
     • devops-sre-platform/ - Infrastructure, deployment, monitoring, platform
     • data-science-ml/ - Data processing, ML workflows, analytics
     • frontend/ - UI/UX, component architecture, design systems
     • backend/ - API design, microservices, database, performance
     • mobile/ - iOS, Android, cross-platform mobile development
     • ai-agents-conversational/ - Agent development, LLM integration patterns

Re-extraction Strategy

When a repository offers improvements to existing processes:

1. Read the existing process to understand current implementation
2. Extract the novel insights - what does the repository add that we don't have?
3. Plan the enhancement - how to integrate new patterns without breaking existing functionality
4. Document the upgrade path - what changes would be made and why

Example upgrade documentation:

### Upgrade Analysis: superpowers-workflow.js ← obra/superpowers debugging enhancements

**Current implementation**: Agent development methodology with TDD, debugging, and planning frameworks

**Repository insights**: 
- Binary search debugging strategy
- Systematic error categorization (syntax/logic/integration/environment)  
- Rubber duck debugging integration
- Prevention-focused root cause analysis

**Proposed enhancements**:
- Add binary search phase for large codebase debugging
- Implement error taxonomy classification within superpowers workflow
- Enhance debugging strategy selection logic
- Integrate prevention analysis into superpowers methodology

**Backward compatibility**: Existing superpowers methodology preserved, enhanced with new debugging patterns

Phase 5 -- Process Codification

For entries marked as NEW or UPGRADE from the library mapping analysis, proceed with process extraction. Use the process-builder skill patterns from .claude/skills/process-builder/SKILL.md.

For NEW processes:

Process files go in .a5c/processes/assimilated/ as staging candidates. After review, they are promoted into the process library at their designated placement path.

For UPGRADE processes:

1. Create enhanced version in .a5c/processes/assimilated/ with suffix -v2 or -enhanced
2. Document the differences from the current version
3. Plan migration strategy for existing users
4. After review, replace or merge with existing process

.a5c/processes/assimilated/
├── [org]-[repo]-[process-name].cjs          # Staged NEW candidate
├── [existing-process]-enhanced.cjs          # Staged UPGRADE candidate  
└── ...

# After review, promoted to process library:
# methodologies/<name>/                       # Full generic dev methodologies only
# specializations/shared/                     # Cross-domain reusable patterns
# specializations/<domain>/                   # Domain-specific processes

Use .cjs extension because .a5c/package.json sets "type": "module".

Each process must:

• Import defineTask from @a5c-ai/babysitter-sdk
• Export async function process(inputs, ctx)
• Include @references pointing back to the source SKILL.md
• Include @process assimilated/[name] tag
• Include @placement tag indicating the target library path (e.g. @placement specializations/security-compliance/k8s-audit)
• Include a @graph JSDoc block referencing relevant atlas graph node IDs (domains, skillAreas, topics, roles, workflows). Read packages/atlas/graph/domain/ to find valid IDs. At minimum include one domain: node. Example: @graph\n * domains: [domain:software-engineering]\n * topics: [topic:security-scanning]\n * roles: [role:sre]
• Honour the source repo's license in the JSDoc header

Phase 6 -- Maintain indexes and history

Maintain three files in docs/reference-repos/ alongside the per-repo research directories:

README.md -- Master index of tracked repos

The main index of all repos with extractable value. Only repos that have research docs with at least one extractable process or plugin idea belong here.

# Reference Repos

<!-- Generated by .claude/skills/assimilate-popular-workflows. Re-run to refresh. -->

Last refreshed: YYYY-MM-DD
Total repos tracked: N

## By Archetype

### Mega Skill Packs
| Repo | Stars | Skills | Extraction Priority |
|------|-------|--------|---------------------|
| [org/name](org/name/research.md) | N | M | High |

### Methodology Repos
...

### Claude Plugins
...

### Domain Skill Packs
...

### Utilities with Skills
...

backlog.md -- Candidate repos to investigate

Repos discovered during Phase 1 that haven't been investigated yet. Append new candidates here during discovery; remove them once classified and either tracked (moved to README.md) or rejected (moved to processed.md).

# Candidate Backlog

| Repo | Stars | Source | Notes | Added |
|------|-------|--------|-------|-------|
| org/name | N | gh-search / clawhub / topic:X | Brief note on why it's a candidate | YYYY-MM-DD |

processed.md -- History of all evaluated repos

Every repo that has been investigated goes here, regardless of outcome. This prevents re-processing the same repo in future discovery runs. Include the classification result and reason for skipping (if skipped).

# Processed Repos

| Repo | Stars | Archetype | Outcome | Date |
|------|-------|-----------|---------|------|
| org/name | N | mega-skill-pack | Tracked -- 3 processes, 2 plugins | YYYY-MM-DD |
| org/other | M | internal-maintenance | Skipped -- no transferable value | YYYY-MM-DD |
| org/another | K | not-a-skill | Skipped -- generic docs, no agent context | YYYY-MM-DD |

Cleanup rules

• Do NOT keep research directories for skipped repos with no extractable value. If a repo is classified as internal-maintenance, other-harness, not-a-skill, or otherwise has zero extractable processes and zero plugin ideas, record it in processed.md only. Do not create a directory under docs/reference-repos/.
• Only create research.md for repos that have at least one extractable process or plugin idea. Each repo gets exactly one file (research.md), not separate index/extractable-value files.
• CRITICAL: Check for duplicates before processing. Before investigating ANY repository:
  1. Check processed.md - skip if already evaluated
  2. Check README.md - skip if already tracked
  3. Check existing docs/reference-repos/[org]/[repo]/ directories
  4. Remove duplicates from backlog.md when found
• License must be verified. Every research.md must include the license field. During enrichment, extract license.spdx_id from the GitHub API. If the license is not MIT, BSD, or Apache-2.0, skip the repo and record it in processed.md with the reason.

Notes

• ALWAYS check existing library first. Before extracting any process, map it against the current process library (library/methodologies/, library/specializations/) to identify UPGRADE opportunities rather than duplicating effort.
• Prioritize upgrades over new processes. Enhancing existing processes with new insights from high-value repositories often provides more value than creating entirely new processes.
• Never copy SKILL.md content wholesale. Extract the procedural insight, not the prose.
• Respect source licenses. Include attribution in every extracted process file.
• Skills that are purely prompt-engineering (just a system prompt with no procedure) have no extractable process value -- note them as not-transferable in the inventory.
• Domain-specific skills are extraction targets, not just methodologies. A "kubernetes-specialist" skill may contain a k8s deployment audit process (specializations/devops-sre-platform/). A "react-expert" may contain a component architecture review (specializations/frontend/). A "debugging-wizard" may contain a systematic debugging process (specializations/shared/). Always read domain skills for multi-step procedural content before dismissing them as "expert personas." The process library has three placement tiers: methodologies/ (full dev paradigms), specializations/shared/ (cross-domain patterns), and specializations/<domain>/ (domain-specific processes). Most extracted value goes into specializations, not methodologies.
• Skip skill-management processes (skill-routing, skill-discovery pipelines, skill-validation, skill-metadata checks). These are babysitter-internal concerns, not transferable domain processes. Their associated plugin ideas (e.g., a skill-registry-browser plugin) may still be valid.
• Skip multi-model coordination processes (multi-model review, heterogeneous AI team orchestration). Babysitter's harness adapter system already handles multi-model dispatch natively. These don't add value as library processes.
• Skip patterns already covered by the SDK: human-in-the-loop review cycles (covered by breakpoints), harness CLI invocation/degradation (covered by harness adapters), effect dispatch coordination (covered by the runtime). Only extract processes that add domain-specific or workflow-specific value beyond what the SDK primitives provide.
• Memory systems are always plugins, never processes. Memory management (tiered storage, decay, reflection, promotion) belongs in the Context & Memory plugin category. Do not place memory-related workflows in the process library -- they are plugin-internal logic installed via install.md.
• The internal-maintenance archetype is the most common. Expect 60-70% of hits to be skipped.
• Rate-limit awareness: gh search code is throttled at 30 req/min. Split searches by language qualifier if hitting caps.
• When a repo appears in processed.md, skip it unless explicitly asked to re-evaluate. For tracked repos (directory exists under docs/reference-repos/), compare pushedAt dates to decide if re-investigation is needed -- update in-place rather than recreating.
• Re-extraction for process upgrades: When explicitly asked to re-extract from high-value repositories to upgrade existing processes, update the existing research.md with new insights and add the "Library Mapping" section to identify UPGRADE opportunities.
• For very large skill packs (20+ skills), sample the most-starred or most-recently-updated skills rather than researching all of them in a single pass.
• After completing research, suggest the user run /babysitter:contrib for any upstream-worthy process candidates.
• See references/classification-heuristics.md for detailed archetype classification examples and edge cases.