/assimilate-popular-workflows

name: assimilate-popular-workflows
description: This skill should be used when the user asks to "find skills in the wild", "assimilate popular workflows", "discover SKILL.md files in repos", "research external skills", "find workflow patterns", "survey the skill landscape", "what skills exist out there", or wants to investigate public repositories for extractable processes, babysitter plugins, and reusable procedural insights. Searches GitHub for SKILL.md files, classifies repos by archetype, and maintains structured research under docs/reference-repos/.

Assimilate Popular Workflows

Search 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.

Process Library Placement Rules

Extracted processes go into the babysitter process library (`library/`). Placement depends on scope:

| What it is | Where it goes | Examples | |------------|---------------|---------| | Full generic dev methodology (entire workflow paradigm) | `methodologies/<name>/` | agile, gsd, tdd, scrum, kanban, waterfall | | Common cross-domain pattern (reusable across many specializations) | `specializations/shared/` | audit-pipeline, expert-advisory, progressive-disclosure | | Domain-specific process | `specializations/<domain>/` | security-compliance, devops-sre-platform, data-science-ml |

**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).

Plugin Ideas = Babysitter Marketplace Plugins

A 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.

**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:

• **Skill pack collections**: If you mark processes for extraction, don't suggest a plugin that just bundles those processes
• **Expert/Role plugins**: ".NET Expert", "React Native Expert", "Vue Development Suite", "Security Expert" - these are just skill packs
• **Domain suites**: "Frontend Development Suite", "DevOps Toolkit", "Data Science Suite" - these bundle processes
• **Orchestration patterns**: Multi-agent coordination, session continuity, workflow orchestration belong in babysitter core or as processes
• **Process repackaging**: Any plugin that just wraps processes you already marked for extraction

Valid plugin ideas change the project or setup (may not install skills at all):

• **Project configuration changes**: Modify CLAUDE.md/AGENTS.md instructions, update settings, configure behaviors
• **External service integrations**: GitHub API, Slack API, database connections, CLI tools, MCP servers
• **Project enforcement mechanisms**: Git hooks, ESLint rules, pre-commit checks, CI/CD pipeline templates
• **Infrastructure and deployment**: Docker configs, cloud provider setup, deployment templates, containerization
• **Memory and persistence systems**: Context storage, session state, cross-run memory, caching layers
• **Development environment changes**: IDE integrations, build tool configs, linting setups, editor extensions
• **Workflow enforcement**: Harness hooks, commit policies, pipeline triggers, quality gates, approval workflows
• **Project structure modifications**: Directory layouts, file templates, scaffolding, boilerplate generation
• **Additional project functionality**: New capabilities, tool chains, automation layers, monitoring integration

**Rule of thumb**: If it teaches babysitter how to do something → process. If it changes the project, adds external connections, or modifies behavior → plugin.

**Valid plugin use case categories** (derived from the existing marketplace):

| Category | What the plugin installs | Examples | |----------|-------------------------|----------| | Security & Sandboxing | Lint rules, git hooks, scanning processes, sandboxing policies | basic-security, agentsh | | Context & Memory | MCP servers for memory, lifecycle hooks for auto-capture | claude-mem, mempalace | | Knowledge Management | Wiki systems, knowledge graphs, semantic search engines | llm-wiki, graphify, qmd | | Developer Experience & UX | Status indicators, session landing pages, skill recommenders | ctx, status-line, welcome | | Tools Integration | Browser automation, external tool integration, MCP tools for new capabilities | dev-browser, prompt-master | | CI/CD Integration | GitHub Actions workflows, harness-specific pipeline templates | github-actions-cicd-* | | DevOps & Infrastructure | IaC templates, deployment configs, cloud provider setup | project-deployment | | Quality Assurance & Testing | Test frameworks, coverage gates, linting configs, pre-commit hooks | testing-suite | | Workflow Automation | Rate limit handling, auto-retry logic, lifecycle event hooks | rate-limit-handler | | Theming & Environment | Sound hooks, design systems, conversational personality, themed assets | themes, sound-hooks | | Harness Integration | Alternative harness adapters, TUI improvements, orchestration frameworks | opencode-adapter, workflow-orchestration |

**IMPORTANT DISTINCTION**: Do NOT confuse babysitter marketpl