{"id":"assimilate-popular-workflows","name":"assimilate-popular-workflows","summary":"このスキルは、「野外でスキルを見つける」「人気のあるワークフローを同化する」「リポジトリ内の SKILL.md ファイルを発見する」「外部スキルを調査する」「ワークフローパターンを見つける」「スキルの状況を調査する」「どんなスキルが存在するか」、または公開リポジトリを調査したい場合に使うべきです。","body":"# Assimilate Popular Workflows\n\nSearch public GitHub repositories for SKILL.md files, classify each repo by archetype, and maintain structured research documents under `docs/reference-repos/[org]/[repo-name]/`. The goal is not to copy skills verbatim but to extract transferable value: processes for the babysitter process library, babysitter marketplace plugin ideas, and implicit procedural knowledge that can be codified into babysitter JS processes.\n\n### Process Library Placement Rules\n\nExtracted processes go into the babysitter process library (`library/`). Placement depends on scope:\n\n| What it is | Where it goes | Examples |\n|------------|---------------|---------|\n| Full generic dev methodology (entire workflow paradigm) | `methodologies/<name>/` | agile, gsd, tdd, scrum, kanban, waterfall |\n| Common cross-domain pattern (reusable across many specializations) | `specializations/shared/` | audit-pipeline, expert-advisory, progressive-disclosure |\n| Domain-specific process | `specializations/<domain>/` | security-compliance, devops-sre-platform, data-science-ml |\n\n**Important**: Do NOT place domain-specific processes in `methodologies/`. Only full, generic development methodologies belong there. A \"k8s security audit\" is `specializations/security-compliance/`, not a methodology. A \"deep research pipeline\" is `specializations/shared/` (cross-domain). A \"TDD agent workflow\" is `methodologies/atdd-tdd/` (full dev methodology).\n\n### Plugin Ideas = Babysitter Marketplace Plugins\n\nA babysitter plugin is a set of natural language instructions (markdown) or deterministic coded processes (JS) that an AI agent reads and executes to install a modular set of capabilities. A plugin contains at minimum `install.md` with instructions the AI agent follows to modify the user's project. See `docs/plugins.md` for the full specification.\n\n**CRITICAL DISTINCTION**: Plugin ideas should ONLY be things that modify project setup, install external integrations, or enforce workflows beyond just adding processes. Do NOT suggest plugins for:\n- **Skill pack collections**: If you mark processes for extraction, don't suggest a plugin that just bundles those processes\n- **Expert/Role plugins**: \".NET Expert\", \"React Native Expert\", \"Vue Development Suite\", \"Security Expert\" - these are just skill packs\n- **Domain suites**: \"Frontend Development Suite\", \"DevOps Toolkit\", \"Data Science Suite\" - these bundle processes\n- **Orchestration patterns**: Multi-agent coordination, session continuity, workflow orchestration belong in babysitter core or as processes\n- **Process repackaging**: Any plugin that just wraps processes you already marked for extraction\n\nValid plugin ideas change the project or setup (may not install skills at all):\n- **Project configuration changes**: Modify CLAUDE.md/AGENTS.md instructions, update settings, configure behaviors\n- **External service integrations**: GitHub API, Slack API, database connections, CLI tools, MCP servers\n- **Project enforcement mechanisms**: Git hooks, ESLint rules, pre-commit checks, CI/CD pipeline templates\n- **Infrastructure and deployment**: Docker configs, cloud provider setup, deployment templates, containerization\n- **Memory and persistence systems**: Context storage, session state, cross-run memory, caching layers\n- **Development environment changes**: IDE integrations, build tool configs, linting setups, editor extensions\n- **Workflow enforcement**: Harness hooks, commit policies, pipeline triggers, quality gates, approval workflows\n- **Project structure modifications**: Directory layouts, file templates, scaffolding, boilerplate generation\n- **Additional project functionality**: New capabilities, tool chains, automation layers, monitoring integration\n\n**Rule of thumb**: If it teaches babysitter how to do something → process. If it changes the project, adds external connections, or modifies behavior → plugin.\n\n**Valid plugin use case categories** (derived from the existing marketplace):\n\n| Category | What the plugin installs | Examples |\n|----------|-------------------------|----------|\n| Security & Sandboxing | Lint rules, git hooks, scanning processes, sandboxing policies | basic-security, agentsh |\n| Context & Memory | MCP servers for memory, lifecycle hooks for auto-capture | claude-mem, mempalace |\n| Knowledge Management | Wiki systems, knowledge graphs, semantic search engines | llm-wiki, graphify, qmd |\n| Developer Experience & UX | Status indicators, session landing pages, skill recommenders | ctx, status-line, welcome |\n| Tools Integration | Browser automation, external tool integration, MCP tools for new capabilities | dev-browser, prompt-master |\n| CI/CD Integration | GitHub Actions workflows, harness-specific pipeline templates | github-actions-cicd-* |\n| DevOps & Infrastructure | IaC templates, deployment configs, cloud provider setup | project-deployment |\n| Quality Assurance & Testing | Test frameworks, coverage gates, linting configs, pre-commit hooks | testing-suite |\n| Workflow Automation | Rate limit handling, auto-retry logic, lifecycle event hooks | rate-limit-handler |\n| Theming & Environment | Sound hooks, design systems, conversational personality, themed assets | themes, sound-hooks |\n| Harness Integration | Alternative harness adapters, TUI improvements, orchestration frameworks | opencode-adapter, workflow-orchestration |\n\n**IMPORTANT DISTINCTION**: Do NOT confuse babysitter marketplace plugins with harness assimilation:\n- **Babysitter marketplace plugins**: Install INTO user projects via `install.md` to add capabilities\n- **Harness assimilation**: Create plugins FOR other harnesses (like hermes-agent) that integrate babysitter INTO those harnesses\n\n## When to use\n\n- User asks to discover what skills or workflows exist in popular repos.\n- User asks to research a specific repo's skill ecosystem.\n- User asks to extract processes or patterns from external skills.\n- Periodic refresh to track the evolving skill landscape.\n\n## Phase 1 -- Discovery\n\nSearch GitHub for repositories containing SKILL.md files. Use multiple search strategies to cast a wide net:\n\n```bash\n# Primary: find SKILL.md files in public repos\ngh search code \"filename:SKILL.md\" --json repository,path,url --limit 100\n\n# Supplementary: search for skill frontmatter patterns\ngh search code \"description:\" \"filename:SKILL.md\" --json repository,path,url --limit 100\n\n# Claude Code plugin skills specifically\ngh search code \"plugin.json\" \"skills\" --json repository,path,url --limit 100\n```\n\n### Topic-based discovery\n\nSearch for repos tagged with relevant GitHub topics. These are high-signal candidates even without SKILL.md files:\n\n```bash\n# Search by topic tags (each is a separate query)\nfor topic in claude-code claude-skills mcp agentic-workflow agent-skills skills agent-harness ai-agents; do\n  gh search repos --topic \"$topic\" --stars=\">50\" --sort stars --limit 50 --json fullName,stargazersCount,description\ndone\n\n# Combined keyword + star searches for broader coverage\ngh search repos \"agent skill\" --stars=\">50\" --sort stars --limit 50 --json fullName,stargazersCount,description\ngh search repos \"claude code skills\" --stars=\">100\" --sort stars --limit 30 --json fullName,stargazersCount,description\ngh search repos \"workflow automation skill\" --stars=\">100\" --sort stars --limit 30 --json fullName,stargazersCount,description\n```\n\nTopic-tagged repos that lack SKILL.md files may still contain extractable processes or plugin ideas if they implement multi-step workflows, domain pipelines, or tool integrations. Classify and research them using the same Phase 2/3 pipeline.\n\n### Marketplace/registry discovery\n\nBrowse public skill and plugin registries for high-download or featured entries. These surface popular repos that may not appear in GitHub search:\n\n- **ClawHub Skills**: https://clawhub.ai/skills?sort=downloads -- browse top skills by download count. Each skill links to a GitHub repo. Extract repo URLs and cross-reference with the tracked set.\n- **ClawHub Plugins**: https://clawhub.ai/plugins -- browse plugins by popularity. Each plugin links to a GitHub repo. Extract repo URLs and cross-reference.\n\nUse a browser tool or `curl` to fetch these pages and extract GitHub repo links. For each new repo found, enrich and classify using the standard pipeline.\n\n### Filtering rules\n\n1. Drop any hit from `a5c-ai/babysitter` (this repo).\n2. **Handle archived/moved repos.** If a repo is archived, check for a successor/migration notice. If the archive points to a new location (e.g., \"moved to org/new-repo\"), skip the archived repo and evaluate the new location instead. Only track active, maintained repositories.\n3. **Drop repos without a permissive license.** Only track repos with MIT, BSD (2-clause or 3-clause), or Apache-2.0 licenses. Drop repos with GPL, AGPL, CC-NC, CC-SA, proprietary, or no license specified. Check `license.spdx_id` during enrichment.\n4. Dedupe by `repository.nameWithOwner`.\n5. Group hits by repo -- one repo may contain many SKILL.md files.\n6. **Prefer repos with 50+ stars.** Lower-star repos may be included only if they contain exceptionally novel processes not found elsewhere. Use `gh search repos` with `--stars=\">50\"` to find higher-quality repos.\n\n### Enrichment\n\nFor each surviving repo:\n\n```bash\ngh api repos/<owner>/<name> \\\n  --jq '{nameWithOwner, description, stargazerCount: .stargazers_count, pushedAt: .pushed_at, topics, license: .license.spdx_id}'\n```\n\nRecord the list of SKILL.md paths found per repo.\n\n## Phase 2 -- Classification\n\nFor each repo, shallow-clone into `.a5c/tmp/skill-discovery/` and investigate the structure. Classify into exactly one archetype:\n\n| Archetype | Description | Action |\n|-----------|-------------|--------|\n| `mega-skill-pack` | Repo exists to distribute many skills across domains | Deep-dive: catalog all skills, extract patterns |\n| `methodology-repo` | Repo represents a specific workflow or methodology | Extract the methodology as a potential babysitter process |\n| `internal-maintenance` | Skills exist only for the repo's own CI/dev workflow | **Skip** -- not transferable |\n| `other-harness` | Skill is specific to a non-Claude harness (Codex, Cursor, etc.) or focused on harness invocation/CLI orchestration | **Skip** -- not transferable to babysitter processes |\n| `claude-plugin` | A Claude Code plugin with skills as part of its offering | Investigate plugin structure, extractable integrations |\n| `harness-framework` | Alternative AI coding harness/framework (OpenCode, Antigravity, etc.) or Claude Code orchestration/TUI improvements | Extract for harness assimilation (new adapter + plugin) and/or TUI/orchestration improvements |\n| `domain-skill-pack` | Skills focused on a specific domain (e.g., data science, DevOps) | Extract domain processes and patterns |\n| `utility-with-skill` | A tool/library that ships a SKILL.md for usage guidance | Extract the usage pattern as a potential shared process |\n| `not-a-skill` | Repo uses SKILL.md as generic docs, no Claude Code connection | **Skip** -- no frontmatter, no agent context |\n\n### Classification signals\n\nRead the repo's top-level README, plugin.json (if present), directory structure, and a sample of SKILL.md files. Look for:\n\n- **mega-skill-pack**: `skills/` directory with 5+ subdirectories, no primary application code\n- **methodology-repo**: Process/workflow documentation dominates, SKILL.md describes a methodology\n- **internal-maintenance**: SKILL.md references only internal paths, CI pipelines, repo-specific tooling\n- **other-harness**: Skill is for Codex, Cursor, or another non-Claude harness; or focuses on CLI orchestration / harness invocation patterns\n- **claude-plugin**: `.claude-plugin/plugin.json` or `plugin.json` with skill registrations\n- **harness-framework**: CLI executable for AI interaction (like `opencode`, `antigravity`), or Claude Code orchestration/TUI/hook improvements (workflow automation, delegation frameworks, status line enhancements)\n- **domain-skill-pack**: Skills all relate to one domain; directory structure groups by topic\n- **utility-with-skill**: Repo is primarily a library/tool; SKILL.md is usage documentation\n\n## Phase 3 -- Deep Research\n\nFor each non-skipped repo, produce a single `research.md` file containing overview, assessment, and extractable value.\n\n**Harness Capability Verification**: For repos classified as `harness-framework`, verify three critical capabilities for babysitter integration:\n1. **Custom Tools/MCP**: Can execute custom tools, MCP servers, or bash commands\n2. **Stop Hooks**: Has stop-hooks or end-turn hooks to interrupt agent conversation for feedback\n3. **Plugin System**: Plugin/extension system with manifests and optionally marketplace\n\nUse WebSearch/WebFetch to research the harness documentation and verify these capabilities. Stop hooks are CRITICAL - without them, babysitter's orchestration loop cannot function (harness must be interruptible between iterations for feedback).\n\n### Directory layout\n\n- **GitHub-sourced repos**: `docs/reference-repos/[org]/[repo-name]/research.md`\n- **ClawHub-sourced skills/plugins**: `docs/reference-repos/clawhub/[author]/[skill-name]/research.md`\n\nEach tracked repo gets exactly **one file** (`research.md`) in its directory. Do not split into multiple files (no separate `index.md` or `extractable-value.md`).\n\n### `research.md` -- Unified research document\n\n```markdown\n# [org]/[repo-name]\n\n- **Archetype**: mega-skill-pack | methodology-repo | claude-plugin | domain-skill-pack | utility-with-skill\n- **Stars**: N\n- **Last pushed**: YYYY-MM-DD\n- **License**: MIT / Apache-2.0 / BSD-2-Clause / BSD-3-Clause\n- **Discovered**: YYYY-MM-DD\n- **Source**: gh-search | clawhub-skills | clawhub-plugins | topic:X\n- **Skills found**: N\n\n## Summary\n<2-3 sentences on what the repo provides and why it's interesting>\n\n## Assessment\n<What is transferable? What is repo-specific? Quality of skill design?\nLook beyond methodologies -- domain-specific skills (DevOps, security, frontend, data, etc.)\noften contain multi-step processes extractable as specializations/<domain>/ entries.\nA \"kubernetes-specialist\" skill may encode a k8s deployment audit process.\nA \"debugging-wizard\" may encode a systematic debugging process.\nFor harness-framework repos, assess: TUI/orchestration improvements for our internal agent harness,\nCLI patterns for new harness adapter creation, and workflow automation patterns.\nAssess each skill for procedural content, not just methodology content.>\n\n## Extraction Priority\n- High / Medium / Low\n- Rationale: <why>\n\n## Skills Inventory\n\n| Skill | Path | Domain | Transferable? | Notes |\n|-------|------|--------|---------------|-------|\n| skill-name | skills/foo/SKILL.md | DevOps | Yes - pattern | Describes a CI/CD workflow |\n\n## Processes\n<Workflows that can be codified as babysitter JS processes.\nDomain-specific skills are prime extraction targets -- a \"react-expert\" skill may contain\na component architecture review process (specializations/frontend/), a \"terraform-engineer\"\nmay contain an IaC audit process (specializations/devops-sre-platform/), etc.\nDon't dismiss domain skills as \"just expert personas\" -- read them for procedural content.>\n- **Process name**: Description of what it does\n  - Source: path/to/SKILL.md (lines N-M)\n  - Placement: methodologies/<name> | specializations/shared | specializations/<domain>\n  - Inputs/Outputs: ...\n  - Complexity: simple | moderate | complex\n  - Notes: ...\n\n## Plugin Ideas\n<Ideas for babysitter marketplace plugins -- installable packages with install.md\nthat an AI agent executes to set up capabilities in a user's project>\n- **Plugin name**: What it installs and configures\n  - What install.md would do: <what the AI agent does during install -- detect stack, interview user, copy processes, set up hooks/configs>\n  - Processes it would copy: <which process library entries>\n  - Configs/hooks it would create: <ESLint rules, git hooks, CI/CD templates, etc.>\n  - Source evidence: <what in the repo inspires this plugin idea>\n  - Marketplace placement: <plugins/a5c/marketplace/blueprints/[category]/[plugin-name]/>\n\n## Plugin Marketplace Mapping\n\n<Check existing marketplace plugins before proposing new ones. Map plugin ideas against current plugins/a5c/marketplace/blueprints/ structure>\n\n| Plugin Idea | Marketplace Status | Action | Existing Plugin | Target Placement |\n|-------------|-------------------|--------|-----------------|------------------|\n| Security Toolkit | UPGRADE | Enhance existing with new scanning processes | plugins/a5c/marketplace/blueprints/basic-security/ | plugins/a5c/marketplace/blueprints/security-toolkit/ |\n| Testing Suite | NEW | Comprehensive testing framework | - | plugins/a5c/marketplace/blueprints/testing-suite/ |\n\n**Example existing plugins** (from plugins/a5c/marketplace/blueprints/):\n- `basic-security`, `agentsh`, `container-security` - Security tools and sandboxing\n- `claude-mem` - Memory and context management\n- `dev-browser` - Browser automation and tools integration\n- `ctx` - Developer experience enhancements  \n- `github-actions-cicd-*` - CI/CD integration templates\n- `argocd-gitops`, `devcontainer` - DevOps and infrastructure\n- `api-contract`, `changelog-enforcer` - Quality assurance tools\n- `autorelease`, `changesets` - Workflow automation\n- `contribution-graph`, `community-health` - Project health and metrics\n\n**Plugin naming pattern**: `[descriptive-name]` - no category prefixes, direct plugin names\n\n## Harness Integration Ideas\n<For harness-framework repos: ideas for new harness adapters and TUI improvements>\n- **Harness Adapter**: New harness integration (like plugins/babysitter-codex for Codex)\n  - Adapter implementation: <what would go in packages/babysitter-sdk/src/harness/adapters/>\n  - Plugin structure: <what would go in plugins/babysitter-[harness]/>\n  - CLI integration: <command patterns, flag mapping, capability detection>\n- **Harness Assimilation**: Plugin FOR the target harness that integrates babysitter (NOT a babysitter marketplace plugin)\n  - **Capability Assessment**: Verify the harness supports babysitter's orchestration requirements:\n    | Capability | Status | Details |\n    |------------|---------|---------|\n    | **Custom Tools/MCP** | ✅/⚠️/❌ | Can the harness execute custom tools, MCP servers, or bash commands? |\n    | **Stop Hooks** | ✅/⚠️/❌ | Does it have stop-hooks or end-turn hooks to interrupt agent conversation for feedback? |\n    | **Plugin System** | ✅/⚠️/❌ | Plugin/extension system with manifests and optionally marketplace? |\n  - **Integration Viability**: EXCELLENT/GOOD/PARTIAL/POOR based on capabilities (stop hooks are CRITICAL)\n  - Target harness plugin: <plugin that goes into the other harness to bring babysitter capabilities>\n  - Babysitter integration: <how the other harness would invoke babysitter processes>\n  - Capability bridge: <what babysitter features would be accessible from the target harness>\n  - Major limitations: <any critical missing capabilities that would prevent full integration>\n- **TUI/Orchestration Improvement**: Enhancement to our internal agent harness\n  - Current limitation: <what our harness lacks that this repo provides>\n  - Integration approach: <how to incorporate the improvement>\n  - Implementation scope: <where in our codebase this would go>\n\n## Implicit Procedural Knowledge\n<Procedures that are described narratively in SKILL.md files but should be\ncodified as deterministic JS processes for the babysitter process library>\n- **Procedure name**: What it accomplishes\n  - Source: SKILL.md section or description text\n  - Placement: methodologies/<name> | specializations/shared | specializations/<domain>\n  - Why codify: <what makes this better as a process than a skill>\n  - Sketch: <brief outline of phases/tasks>\n```\n\n## Phase 4 -- Library Mapping and Re-extraction Analysis\n\n**CRITICAL: Check existing process library before creating new processes.** Many high-value repositories have already been assimilated into the babysitter process library. Before extracting processes, map them against existing library content to identify:\n\n1. **Direct matches** - processes already implemented that could be enhanced with new insights\n2. **Near matches** - similar processes that could be generalized or specialized \n3. **Gaps** - novel processes not yet in the library\n\n### Library Structure Check\n\nThe babysitter process library is located at `library/` with these key directories:\n\n- `library/methodologies/` - Full development methodologies (agile.js, atdd-tdd/, bmad-method/, cc10x/, etc.)\n- `library/specializations/` - Domain-specific processes (ai-agents-conversational/, etc.)\n- `library/cradle/` - Core babysitter processes (bug-report.js, feature-request.js, etc.)\n- `library/contrib/` - User-contributed processes\n\n### Mapping Process\n\nFor each extractable process identified in Phase 3 research documents:\n\n1. **Search for existing implementations:**\n   ```bash\n   # Look for similar process names/concepts\n   find library -name \"*.js\" -type f | grep -i \"<process-concept>\"\n   \n   # Check for methodology matches\n   ls library/methodologies/\n   \n   # Check specialization domains\n   ls library/specializations/\n   ```\n\n2. **Classify the relationship:**\n   - **UPGRADE** - existing process that could be enhanced with new patterns/insights from the repo\n   - **VARIANT** - similar process that could be generalized or adapted\n   - **NEW** - novel process not represented in the library\n   - **OBSOLETE** - existing process that could be replaced with superior approach from repo\n\n3. **Document the mapping:**\n   Add a \"Library Mapping\" section to each `research.md`:\n   ```markdown\n   ## Library Mapping\n   \n   | Extractable Process | Library Status | Action | Existing Path | Target Placement |\n   |-------------------|----------------|--------|---------------|------------------|\n   | Superpowers Debugging | UPGRADE | Enhance with new TDD integration patterns | methodologies/superpowers/superpowers-workflow.js | methodologies/superpowers/ (enhancement) |\n   | TDD Workflow | VARIANT | Could generalize atdd-tdd with pure TDD variant | methodologies/atdd-tdd/atdd-tdd.js | methodologies/pure-tdd/ (new variant) |\n   | Research Pipeline | NEW | Novel 23-stage autonomous research methodology | - | specializations/shared/autonomous-research.js |\n   | Security Audit | NEW | K8s security scanning process | - | specializations/security-compliance/k8s-security-audit.js |\n   ```\n   \n   **Library placement rules for Target Placement:**\n   - **methodologies/[name]/**: Full generic dev methodologies only (agile, tdd, scrum, kanban)\n   - **specializations/shared/**: Cross-domain reusable patterns (audit-pipeline, research-methodology) \n   - **specializations/[domain]/**: Domain-specific processes:\n     - `security-compliance/` - Security, compliance, auditing, scanning\n     - `devops-sre-platform/` - Infrastructure, deployment, monitoring, platform\n     - `data-science-ml/` - Data processing, ML workflows, analytics\n     - `frontend/` - UI/UX, component architecture, design systems\n     - `backend/` - API design, microservices, database, performance\n     - `mobile/` - iOS, Android, cross-platform mobile development\n     - `ai-agents-conversational/` - Agent development, LLM integration patterns\n\n### Re-extraction Strategy\n\nWhen a repository offers improvements to existing processes:\n\n1. **Read the existing process** to understand current implementation\n2. **Extract the novel insights** - what does the repository add that we don't have?\n3. **Plan the enhancement** - how to integrate new patterns without breaking existing functionality\n4. **Document the upgrade path** - what changes would be made and why\n\nExample upgrade documentation:\n```markdown\n### Upgrade Analysis: superpowers-workflow.js ← obra/superpowers debugging enhancements\n\n**Current implementation**: Agent development methodology with TDD, debugging, and planning frameworks\n\n**Repository insights**: \n- Binary search debugging strategy\n- Systematic error categorization (syntax/logic/integration/environment)  \n- Rubber duck debugging integration\n- Prevention-focused root cause analysis\n\n**Proposed enhancements**:\n- Add binary search phase for large codebase debugging\n- Implement error taxonomy classification within superpowers workflow\n- Enhance debugging strategy selection logic\n- Integrate prevention analysis into superpowers methodology\n\n**Backward compatibility**: Existing superpowers methodology preserved, enhanced with new debugging patterns\n```\n\n## Phase 5 -- Process Codification\n\nFor 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`.\n\n### For NEW processes:\nProcess files go in `.a5c/processes/assimilated/` as staging candidates. After review, they are promoted into the process library at their designated placement path.\n\n### For UPGRADE processes:\n1. Create enhanced version in `.a5c/processes/assimilated/` with suffix `-v2` or `-enhanced`\n2. Document the differences from the current version\n3. Plan migration strategy for existing users\n4. After review, replace or merge with existing process\n\n```\n.a5c/processes/assimilated/\n├── [org]-[repo]-[process-name].cjs          # Staged NEW candidate\n├── [existing-process]-enhanced.cjs          # Staged UPGRADE candidate  \n└── ...\n\n# After review, promoted to process library:\n# methodologies/<name>/                       # Full generic dev methodologies only\n# specializations/shared/                     # Cross-domain reusable patterns\n# specializations/<domain>/                   # Domain-specific processes\n```\n\nUse `.cjs` extension because `.a5c/package.json` sets `\"type\": \"module\"`.\n\nEach process must:\n- Import `defineTask` from `@a5c-ai/babysitter-sdk`\n- Export `async function process(inputs, ctx)`\n- Include `@references` pointing back to the source SKILL.md\n- Include `@process assimilated/[name]` tag\n- Include `@placement` tag indicating the target library path (e.g. `@placement specializations/security-compliance/k8s-audit`)\n- 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]`\n- Honour the source repo's license in the JSDoc header\n\n## Phase 6 -- Maintain indexes and history\n\nMaintain three files in `docs/reference-repos/` alongside the per-repo research directories:\n\n### `README.md` -- Master index of tracked repos\n\nThe 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.\n\n```markdown\n# Reference Repos\n\n<!-- Generated by .claude/skills/assimilate-popular-workflows. Re-run to refresh. -->\n\nLast refreshed: YYYY-MM-DD\nTotal repos tracked: N\n\n## By Archetype\n\n### Mega Skill Packs\n| Repo | Stars | Skills | Extraction Priority |\n|------|-------|--------|---------------------|\n| [org/name](org/name/research.md) | N | M | High |\n\n### Methodology Repos\n...\n\n### Claude Plugins\n...\n\n### Domain Skill Packs\n...\n\n### Utilities with Skills\n...\n```\n\n### `backlog.md` -- Candidate repos to investigate\n\nRepos 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).\n\n```markdown\n# Candidate Backlog\n\n| Repo | Stars | Source | Notes | Added |\n|------|-------|--------|-------|-------|\n| org/name | N | gh-search / clawhub / topic:X | Brief note on why it's a candidate | YYYY-MM-DD |\n```\n\n### `processed.md` -- History of all evaluated repos\n\nEvery 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).\n\n```markdown\n# Processed Repos\n\n| Repo | Stars | Archetype | Outcome | Date |\n|------|-------|-----------|---------|------|\n| org/name | N | mega-skill-pack | Tracked -- 3 processes, 2 plugins | YYYY-MM-DD |\n| org/other | M | internal-maintenance | Skipped -- no transferable value | YYYY-MM-DD |\n| org/another | K | not-a-skill | Skipped -- generic docs, no agent context | YYYY-MM-DD |\n```\n\n### Cleanup rules\n\n- **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/`.\n- **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.\n- **CRITICAL: Check for duplicates before processing.** Before investigating ANY repository:\n  1. Check `processed.md` - skip if already evaluated\n  2. Check `README.md` - skip if already tracked  \n  3. Check existing `docs/reference-repos/[org]/[repo]/` directories\n  4. Remove duplicates from `backlog.md` when found\n- **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.\n\n## Notes\n\n- **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.\n- **Prioritize upgrades over new processes.** Enhancing existing processes with new insights from high-value repositories often provides more value than creating entirely new processes.\n- Never copy SKILL.md content wholesale. Extract the *procedural insight*, not the prose.\n- Respect source licenses. Include attribution in every extracted process file.\n- 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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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`.\n- The `internal-maintenance` archetype is the most common. Expect 60-70% of hits to be skipped.\n- Rate-limit awareness: `gh search code` is throttled at 30 req/min. Split searches by language qualifier if hitting caps.\n- 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.\n- **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.\n- 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.\n- After completing research, suggest the user run `/babysitter:contrib` for any upstream-worthy process candidates.\n- See `references/classification-heuristics.md` for detailed archetype classification examples and edge cases.","author":"@a5c-ai","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/assimilate-popular-workflows","license":"MIT","category":"writing","lang":"en","tokens":7417,"stars":0,"calls30d":1,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/classification-heuristics.md","size":7469,"sha256":"7bc4ce58efb7e8a11831d23d68bf1f1e969b58d42267b99205f2caa16161692a"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":["clawhub.ai"]}}