{"items":[{"id":"cmugwijyv0285qu06t4ztmctl","slug":"a5c-ai-babysitter-catalog-babysitter-users","name":"catalog-babysitter-users","description":"Discover public GitHub repositories that import defineTask from @a5c-ai/babysitter-sdk and maintain a deduplicated catalog of those repositories in docs/repo-with-babysitter-processes.md. Excludes any repo named \"babysitter\" (to filter out forks of this monorepo). Invoke when asked to find, discover, catalog, or refresh \"repos using babysitter\", \"babysitter in the wild\", or \"who else is using babysitter\".","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"catalog-babysitter-users","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Discover public GitHub repositories that import defineTask from @a5c-ai/babysitter-sdk and maintain a deduplicated catalog of those repositories in docs/repo-with-babysitter-processes.md. Excludes any repo named \"babysitter\" (to filter out forks of this monorepo). Invoke when asked to find, discover, catalog, or refresh \"repos using babysitter\", \"babysitter in the wild\", or \"who else is using babysitter\".","permissions":[],"systemPrompt":"# Catalog Babysitter Users\n\nProduce a curated, deduplicated catalog of public GitHub repositories that import `defineTask` from `@a5c-ai/babysitter-sdk`, stored at `docs/repo-with-babysitter-processes.md`. Refresh the catalog in-place when re-run; do not delete entries that no longer match (mark them as \"last seen\" instead, so the catalog is additive over time).\n\n## When to use\n\n- User asks \"who's using babysitter in the wild?\", \"find repos with babysitter processes\", \"refresh the catalog\", \"update the babysitter-users list\".\n- After a release, to see whether new adopters have appeared.\n- Before a retrospective across external runs (see the sibling skill `retrospect-external-babysitter-run`).\n\n## Prerequisites\n\n- `gh` CLI installed and authenticated (`gh auth status` must be OK). GitHub code search requires an authenticated user.\n- Writable working tree (the catalog file gets updated).\n\n## Exact search\n\nSearch the literal import statement across public code:\n\n```bash\ngh search code \\\n \"import { defineTask } from '@a5c-ai/babysitter-sdk'\" \\\n --json repository,path,url \\\n --limit 200\n```\n\nAlso run the double-quote variant to catch formatter differences:\n\n```bash\ngh search code \\\n 'import { defineTask } from \"@a5c-ai/babysitter-sdk\"' \\\n --json repository,path,url \\\n --limit 200\n```\n\nUnion the two result sets. If the CLI caps out at 100 per query, paginate by adding `language:javascript`, `language:typescript`, and `extension:js`, `extension:ts` qualifiers to split the search space.\n\n## Filtering rules (apply in order)\n\n1. Drop any hit whose `repository.name` (case-insensitive) equals `babysitter`. This excludes forks of this monorepo.\n2. Drop any hit whose `repository.nameWithOwner` starts with `a5c-ai/` -- those are first-party and already known.\n3. Drop archived repos (`repository.isArchived === true`). Enrich via `gh api repos//` if the search JSON lacks it.\n4. Dedupe by `repository.nameWithOwner` -- one entry per repo, even if multiple files match. Keep the count of matching files as evidence.\n5. Drop private-visible-as-public fluke hits (repository.visibility !== 'public').\n\n## Enrichment per surviving repo\n\nFor each repo, fetch:\n\n```bash\ngh api repos// \\\n --jq '{nameWithOwner, description, stargazerCount: .stargazers_count, pushedAt: .pushed_at, defaultBranch: .default_branch, license: .license.spdx_id, topics}'\n```\n\nAlso record:\n\n- `processFiles`: the list of matching file paths from the search (cap at 10 per repo in the catalog; note total count if higher).\n- `firstSeen`: if the repo is new to the catalog, today's date (ISO). If already present, preserve the existing value.\n- `lastSeen`: today's date (ISO) for every repo that matched this run.\n\n## Catalog file format\n\nMaintain `docs/repo-with-babysitter-processes.md` as an additive, idempotent document. Structure:\n\n```markdown\n# Repositories Using Babysitter\n\n\n\nLast refreshed: YYYY-MM-DD\nTotal repos tracked: N\nNew this run: M\nNo longer matching: K\n\n## Active\n\n| Repository | Stars | Description | License | Pushed | Process files | First seen | Last seen |\n|------------|-------|-------------|---------|--------|---------------|------------|-----------|\n| [owner/name](https://github.com/owner/name) | 123 | ... | MIT | 2026-04-01 | 3 | 2026-03-15 | 2026-04-12 |\n\n### owner/name\n\n- Default branch: `main`\n- Topics: `a5c`, `orchestration`\n- Matching files:\n - [`src/processes/build.js`](https://github.com/owner/name/blob/main/src/processes/build.js)\n - ...\n\n## Stale (no longer matching at last refresh)\n\n| Repository | Last seen | Notes |\n|------------|-----------|-------|\n| ... | ... | Import removed / repo archived / ... |\n```\n\nRules when updating:\n\n- Preserve every existing entry's `firstSeen`.\n- Move a repo from Active to Stale only if it didn't match this run AND was Active last run. Include the reason if derivable (archived, 404, import removed).\n- Never delete a Stale entry; only update its `lastSeen` note if the situation changes (e.g. re-matched -> move back to Active).\n- Sort Active rows by stars descending, then by `pushedAt` descending.\n- Keep the summary counters at the top accurate.\n\n## Procedure\n\n1. Read the current `docs/repo-with-babysitter-processes.md` (if absent, treat as an empty catalog).\n2. Parse existing entries into a map keyed by `nameWithOwner`.\n3. Run both `gh search code` queries above; union results.\n4. Apply the filtering rules.\n5. Enrich each surviving repo via `gh api repos/...`.\n6. Build the merged catalog: existing entries + new entries; move absent-this-run Active entries to Stale.\n7. Write the updated markdown file.\n8. Print a short summary to the user: N total, M new, K moved to stale, top 5 new repos by stars.\n\n## Notes on rate limits\n\n`gh search code` is throttled (30 req/min for authenticated users). If the first pass returns the default cap, split by `language:` qualifier and by file `extension:` rather than spamming retries. Always include `--limit 100` (max) and paginate via qualifier-splitting, not `--page` (code search doesn't page).\n\n## After running\n\nSuggest the sibling skill `retrospect-external-babysitter-run` to go deeper on any specific entry -- \"pick a repo from the catalog and retrospect on one of its runs\".","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/catalog-babysitter-users","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":".claude/skills/catalog-babysitter-users/SKILL.md","defaultBranch":"main"},"readme":"# Catalog Babysitter Users\n\nProduce a curated, deduplicated catalog of public GitHub repositories that import `defineTask` from `@a5c-ai/babysitter-sdk`, stored at `docs/repo-with-babysitter-processes.md`. Refresh the catalog in-place when re-run; do not delete entries that no longer match (mark them as \"last seen\" instead, so the catalog is additive over time).\n\n## When to use\n\n- User asks \"who's using babysitter in the wild?\", \"find repos with babysitter processes\", \"refresh the catalog\", \"update the babysitter-users list\".\n- After a release, to see whether new adopters have appeared.\n- Before a retrospective across external runs (see the sibling skill `retrospect-external-babysitter-run`).\n\n## Prerequisites\n\n- `gh` CLI installed and authenticated (`gh auth status` must be OK). GitHub code search requires an authenticated user.\n- Writable working tree (the catalog file gets updated).\n\n## Exact search\n\nSearch the literal import statement across public code:\n\n```bash\ngh search code \\\n \"import { defineTask } from '@a5c-ai/babysitter-sdk'\" \\\n --json repository,path,url \\\n --limit 200\n```\n\nAlso run the double-quote variant to catch formatter differences:\n\n```bash\ngh search code \\\n 'import { defineTask } from \"@a5c-ai/babysitter-sdk\"' \\\n --json repository,path,url \\\n --limit 200\n```\n\nUnion the two result sets. If the CLI caps out at 100 per query, paginate by adding `language:javascript`, `language:typescript`, and `extension:js`, `extension:ts` qualifiers to split the search space.\n\n## Filtering rules (apply in order)\n\n1. Drop any hit whose `repository.name` (case-insensitive) equals `babysitter`. This excludes forks of this monorepo.\n2. Drop any hit whose `repository.nameWithOwner` starts with `a5c-ai/` -- those are first-party and already known.\n3. Drop archived repos (`repository.isArchived === true`). Enrich via `gh api repos//` if the search JSON lacks it.\n4. Dedupe by `repository.nameWithOwner` -- one entry per repo, even if multiple files match. Keep the count of matching files as evidence.\n5. Drop private-visible-as-public fluke hits (repository.visibility !== 'public').\n\n## Enrichment per surviving repo\n\nFor each repo, fetch:\n\n```bash\ngh api repos// \\\n --jq '{nameWithOwner, description, stargazerCount: .stargazers_count, pushedAt: .pushed_at, defaultBranch: .default_branch, license: .license.spdx_id, topics}'\n```\n\nAlso record:\n\n- `processFiles`: the list of matching file paths from the search (cap at 10 per repo in the catalog; note total count if higher).\n- `firstSeen`: if the repo is new to the catalog, today's date (ISO). If already present, preserve the existing value.\n- `lastSeen`: today's date (ISO) for every repo that matched this run.\n\n## Catalog file format\n\nMaintain `docs/repo-with-babysitter-processes.md` as an additive, idempotent document. Structure:\n\n```markdown\n# Repositories Using Babysitter\n\n\n\nLast refreshed: YYYY-MM-DD\nTotal repos tracked: N\nNew this run: M\nNo longer matching: K\n\n## Active\n\n| Repository | Stars | Description | License | Pushed | Process files | First seen | Last seen |\n|------------|-------|-------------|---------|--------|---------------|------------|-----------|\n| [owner/name](https://github.com/owner/name) | 123 | ... | MIT | 2026-04-01 | 3 | 2026-03-15 | 2026-04-12 |\n\n### owner/name\n\n- Default branch: `main`\n- Topics: `a5c`, `orchestration`\n- Matching files:\n - [`src/processes/build.js`](https://github.com/owner/name/blob/main/src/processes/build.js)\n - ...\n\n## Stale (no longer matching at last refresh)\n\n| Repository | Last seen | Notes |\n|------------|-----------|-------|\n| ... | ... | Import removed / repo archived / ... |\n```\n\nRules when updating:\n\n- Preserve every existing entry's `firstSeen`.\n- Move a repo from Active to Stale only if it didn't match this run AND was Active last run. Include the reason if derivable (archived, 404, import removed).\n- Neve","createdAt":"2026-09-25T11:52:32.407Z","updatedAt":"2026-09-25T11:52:32.407Z"},{"id":"cmugwijz70288qu06x6e25yh8","slug":"a5c-ai-babysitter-fix-failing-pipelines","name":"fix-failing-pipelines","description":"This skill should be used when the user asks to \"fix pipelines\", \"fix CI\", \"check staging pipelines\", \"fix failing workflows\", \"fix failing actions\", or wants to find and fix failing GitHub Actions workflows on the staging branch of the babysitter repo.","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"fix-failing-pipelines","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"This skill should be used when the user asks to \"fix pipelines\", \"fix CI\", \"check staging pipelines\", \"fix failing workflows\", \"fix failing actions\", or wants to find and fix failing GitHub Actions workflows on the staging branch of the babysitter repo.","permissions":[],"systemPrompt":"# Fix Failing Pipelines\n\nCheck GitHub Actions workflows on the `staging` branch of https://github.com/a5c-ai/babysitter/actions, identify workflows whose most recent run is failing, and dispatch `/babysitter:yolo` to fix each one.\n\n## Workflow\n\n### Step 1: Fetch Most Recent Run Per Workflow\n\nUse the `gh` CLI to list recent workflow runs on the `staging` branch:\n\n```bash\ngh run list --repo a5c-ai/babysitter --branch staging --limit 50 --json databaseId,workflowName,status,conclusion,createdAt,headBranch\n```\n\nGroup the results by `workflowName`. For each workflow, keep only the **most recent** run (by `createdAt`). Discard workflows where the most recent run is still `in_progress` -- we only care about completed runs.\n\n### Step 2: Identify Failures\n\nFrom the grouped results, select only workflows where the most recent completed run has `conclusion: \"failure\"`. Skip workflows whose latest run succeeded, was cancelled, or is still running.\n\nIf no workflows have a failing most-recent run, report that all staging pipelines are green and stop.\n\n### Step 3: Get Failure Details\n\nFor each failing workflow run, fetch the failed job and step details:\n\n```bash\ngh run view --repo a5c-ai/babysitter --json jobs --jq '.jobs[] | select(.conclusion == \"failure\") | {name, conclusion, steps: [.steps[] | select(.conclusion == \"failure\") | .name]}'\n```\n\nThen fetch the logs to understand the actual error:\n\n```bash\ngh run view --repo a5c-ai/babysitter --log-failed 2>&1 | tail -100\n```\n\n### Step 4: Present Failures\n\nDisplay the list of failing workflows to the user with:\n- Workflow name\n- Run ID and link\n- Failed job name(s) and failed step name(s)\n- Brief summary of the error from the logs\n\n### Step 5: Fix via Babysitter\n\nFor each failing workflow, invoke the `babysitter:yolo` skill with a prompt that includes the failure context:\n\n```\n/babysitter:yolo fix the failing \"\" pipeline on staging. The most recent run () failed in job \"\" at step \"\". Error details: . Investigate the failure, fix the root cause, and push a fix to the staging branch. Do not create a new branch -- commit directly to staging.\n```\n\nIf multiple workflows are failing, process them sequentially -- complete one before starting the next. Present a summary after each fix attempt.\n\n### Step 6: Verify Fixes\n\nAfter pushing a fix for each workflow, wait briefly then check if a new run was triggered:\n\n```bash\ngh run list --repo a5c-ai/babysitter --branch staging --workflow \"\" --limit 1 --json databaseId,status,conclusion\n```\n\nReport whether a new run was triggered and its current status. Do not wait for it to complete -- just confirm it was triggered.\n\n### Step 7: Summary\n\nAfter all failing workflows have been addressed, provide a summary:\n- Which workflows were failing\n- What was fixed for each\n- Whether new runs were triggered\n- Any workflows that could not be fixed (with reason)\n\n## Notes\n\n- Only the **most recent** run per workflow type matters. Older failures that have since been superseded by a success are not actionable.\n- Runs that are `in_progress` are skipped entirely -- they haven't concluded yet.\n- Cancelled runs are not treated as failures.\n- The `gh` CLI must be authenticated. If authentication fails, prompt the user to run `gh auth login`.\n- Each fix is handed off to `/babysitter:yolo` which handles the actual implementation work non-interactively.\n- Fixes are committed directly to `staging` -- no feature branches or PRs for pipeline fixes.\n- The entire workflow should be without any user interaction or breakpoints in the run, allowing for seamless pipeline repair.\n- if you fixed it, wait for the new run to be completed and check if it succeeded. if it failed again, iterate on the fix until it succeeds.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/fix-failing-pipelines","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":".claude/skills/fix-failing-pipelines/SKILL.md","defaultBranch":"main"},"readme":"# Fix Failing Pipelines\n\nCheck GitHub Actions workflows on the `staging` branch of https://github.com/a5c-ai/babysitter/actions, identify workflows whose most recent run is failing, and dispatch `/babysitter:yolo` to fix each one.\n\n## Workflow\n\n### Step 1: Fetch Most Recent Run Per Workflow\n\nUse the `gh` CLI to list recent workflow runs on the `staging` branch:\n\n```bash\ngh run list --repo a5c-ai/babysitter --branch staging --limit 50 --json databaseId,workflowName,status,conclusion,createdAt,headBranch\n```\n\nGroup the results by `workflowName`. For each workflow, keep only the **most recent** run (by `createdAt`). Discard workflows where the most recent run is still `in_progress` -- we only care about completed runs.\n\n### Step 2: Identify Failures\n\nFrom the grouped results, select only workflows where the most recent completed run has `conclusion: \"failure\"`. Skip workflows whose latest run succeeded, was cancelled, or is still running.\n\nIf no workflows have a failing most-recent run, report that all staging pipelines are green and stop.\n\n### Step 3: Get Failure Details\n\nFor each failing workflow run, fetch the failed job and step details:\n\n```bash\ngh run view --repo a5c-ai/babysitter --json jobs --jq '.jobs[] | select(.conclusion == \"failure\") | {name, conclusion, steps: [.steps[] | select(.conclusion == \"failure\") | .name]}'\n```\n\nThen fetch the logs to understand the actual error:\n\n```bash\ngh run view --repo a5c-ai/babysitter --log-failed 2>&1 | tail -100\n```\n\n### Step 4: Present Failures\n\nDisplay the list of failing workflows to the user with:\n- Workflow name\n- Run ID and link\n- Failed job name(s) and failed step name(s)\n- Brief summary of the error from the logs\n\n### Step 5: Fix via Babysitter\n\nFor each failing workflow, invoke the `babysitter:yolo` skill with a prompt that includes the failure context:\n\n```\n/babysitter:yolo fix the failing \"\" pipeline on staging. The most recent run () failed in job \"\" at step \"\". Error details: . Investigate the failure, fix the root cause, and push a fix to the staging branch. Do not create a new branch -- commit directly to staging.\n```\n\nIf multiple workflows are failing, process them sequentially -- complete one before starting the next. Present a summary after each fix attempt.\n\n### Step 6: Verify Fixes\n\nAfter pushing a fix for each workflow, wait briefly then check if a new run was triggered:\n\n```bash\ngh run list --repo a5c-ai/babysitter --branch staging --workflow \"\" --limit 1 --json databaseId,status,conclusion\n```\n\nReport whether a new run was triggered and its current status. Do not wait for it to complete -- just confirm it was triggered.\n\n### Step 7: Summary\n\nAfter all failing workflows have been addressed, provide a summary:\n- Which workflows were failing\n- What was fixed for each\n- Whether new runs were triggered\n- Any workflows that could not be fixed (with reason)\n\n## Notes\n\n- Only the **most recent** run per workflow type matters. Older failures that have since been superseded by a success are not actionable.\n- Runs that are `in_progress` are skipped entirely -- they haven't concluded yet.\n- Cancelled runs are not treated as failures.\n- The `gh` CLI must be authenticated. If authentication fails, prompt the user to run `gh auth login`.\n- Each fix is handed off to `/babysitter:yolo` which handles the actual implementation work non-interactively.\n- Fixes are committed directly to `staging` -- no feature branches or PRs for pipeline fixes.\n- The entire workflow should be without any user interaction or breakpoints in the run, allowing for seamless pipeline repair.\n- if you fixed it, wait for the new run to be completed and check if it succeeded. if it failed again, iterate on the fix until it succeeds.","createdAt":"2026-09-25T11:52:32.419Z","updatedAt":"2026-09-25T11:52:32.419Z"},{"id":"cmugwijzh028bqu069gnufg7h","slug":"a5c-ai-babysitter-process-builder","name":"process-builder","description":"Scaffold new babysitter process definitions following SDK patterns, proper structure, and best practices. Guides the 3-phase workflow from research to implementation.","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"process-builder","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Scaffold new babysitter process definitions following SDK patterns, proper structure, and best practices. Guides the 3-phase workflow from research to implementation.","permissions":[],"systemPrompt":"# Process Builder\n\nCreate new process definitions for the babysitter event-sourced orchestration framework.\n\n## Quick Reference\n\n```\nProcesses live in: library/\n├── methodologies/ # Reusable development approaches (TDD, BDD, Scrum, etc.)\n│ └── [name]/\n│ ├── README.md # Documentation\n│ ├── [name].js # Main process\n│ └── examples/ # Sample inputs\n│\n└── specializations/ # Domain-specific processes\n ├── [category]/ # Engineering specializations (direct children)\n │ └── [process].js\n └── domains/\n └── [domain]/ # Business, Science, Social Sciences\n └── [spec]/\n ├── README.md\n ├── references.md\n ├── processes-backlog.md\n └── [process].js\n```\n\n## 3-Phase Workflow\n\n### Phase 1: Research & Documentation\n\nCreate foundational documentation:\n\n```bash\n# Check existing specializations\nls library/specializations/\n\n# Check methodologies\nls library/methodologies/\n```\n\n**Create:**\n- `README.md` - Overview, roles, goals, use cases, common flows\n- `references.md` - External references, best practices, links to sources\n\n### Phase 2: Identify Processes\n\nCreate `processes-backlog.md` with identified processes:\n\n```markdown\n# Processes Backlog - [Specialization Name]\n\n## Identified Processes\n\n- [ ] **process-name** - Short description of what this process accomplishes\n - Reference: [Link to methodology or standard]\n - Inputs: list key inputs\n - Outputs: list key outputs\n\n- [ ] **another-process** - Description\n ...\n```\n\n### Phase 3: Create Process Files\n\nCreate `.js` process files following SDK patterns (see below).\n\n---\n\n## Process File Structure\n\nEvery process file follows this pattern:\n\n```javascript\n/**\n * @process [category]/[process-name]\n * @description Clear description of what the process accomplishes end-to-end\n * @inputs { inputName: type, optionalInput?: type }\n * @outputs { success: boolean, outputName: type, artifacts: array }\n *\n * @graph\n * domains: [domain:software-engineering]\n * skillAreas: [skill-area:your-skill-area]\n * topics: [topic:your-topic]\n * roles: [role:your-role]\n * workflows: [workflow:your-workflow]\n *\n * @example\n * const result = await orchestrate('[category]/[process-name]', {\n * inputName: 'value',\n * optionalInput: 'optional-value'\n * });\n *\n * @references\n * - Book: \"Relevant Book Title\" by Author\n * - Article: [Title](https://link)\n * - Standard: ISO/IEEE reference\n */\n\nimport { defineTask } from '@a5c-ai/babysitter-sdk';\n\n/**\n * [Process Name] Process\n *\n * Methodology: Brief description of the approach\n *\n * Phases:\n * 1. Phase Name - What happens\n * 2. Phase Name - What happens\n * ...\n *\n * Benefits:\n * - Benefit 1\n * - Benefit 2\n *\n * @param {Object} inputs - Process inputs\n * @param {string} inputs.inputName - Description of input\n * @param {Object} ctx - Process context (see SDK)\n * @returns {Promise} Process result\n */\nexport async function process(inputs, ctx) {\n const {\n inputName,\n optionalInput = 'default-value',\n // ... destructure with defaults\n } = inputs;\n\n const artifacts = [];\n\n // ============================================================================\n // PHASE 1: [PHASE NAME]\n // ============================================================================\n\n ctx.log?.('info', 'Starting Phase 1...');\n\n const phase1Result = await ctx.task(someTask, {\n // task inputs\n });\n\n artifacts.push(...(phase1Result.artifacts || []));\n\n // Breakpoint for human review (when needed)\n await ctx.breakpoint({\n question: 'Review the results and approve to continue?',\n title: 'Phase 1 Review',\n context: {\n runId: ctx.runId,\n files: [\n { path: 'artifacts/output.md', format: 'markdown', label: 'Output' }\n ]\n }\n });\n\n // ============================================================================\n // PHASE 2: [PHASE NAME] - Parallel Execution Example\n // ============================================================================\n\n const [result1, result2, result3] = await ctx.parallel.all([\n () => ctx.task(task1, { /* args */ }),\n () => ctx.task(task2, { /* args */ }),\n () => ctx.task(task3, { /* args */ })\n ]);\n\n // ============================================================================\n // PHASE 3: [ITERATION EXAMPLE]\n // ============================================================================\n\n let iteration = 0;\n let targetMet = false;\n\n while (!targetMet && iteration < maxIterations) {\n iteration++;\n\n const iterResult = await ctx.task(iterativeTask, {\n iteration,\n previousResults: /* ... */\n });\n\n targetMet = iterResult.meetsTarget;\n\n if (!targetMet && iteration % 3 === 0) {\n // Periodic checkpoint\n await ctx.breakpoint({\n question: `Iteration ${iteration}: Target not met. Continue?`,\n title: 'Progress Checkpoint',\n context: { /* ... */ }\n });\n }\n }\n\n // ============================================================================\n // COMPLETION\n // ============================================================================\n\n return {\n success: targetMet,\n iterations: iteration,\n artifacts,\n // ... other outputs matching @outputs\n };\n}\n\n// ============================================================================\n// TASK DEFINITIONS\n// ============================================================================\n\n/**\n * Task: [Task Name]\n * Purpose: What this task accomplishes\n */\nconst someTask = defineTask({\n name: 'task-name',\n description: 'What this task does',\n\n // Task definition - executed externally by orchestrator\n // This returns a TaskDef that describes HOW to run the task\n\n inputs: {\n inputName: { type: 'string', required: true },\n optionalInput: { type: 'number', default: 10 }\n },\n\n outputs: {\n result: { type: 'object' },\n artifacts: { type: 'array' }\n },\n\n async run(inputs, taskCtx) {\n const effectId = taskCtx.effectId;\n\n return {\n kind: 'node', // or 'agent', 'skill', 'shell', 'breakpoint'\n title: `Task: ${inputs.inputName}`,\n node: {\n entry: 'scripts/task-runner.js',\n args: ['--input', inputs.inputName, '--effect-id', effectId]\n },\n io: {\n inputJsonPath: `tasks/${effectId}/input.json`,\n outputJsonPath: `tasks/${effectId}/result.json`\n },\n labels: ['category', 'subcategory']\n };\n }\n});\n```\n\n---\n\n## SDK Context API Reference\n\nThe `ctx` object provides these intrinsics:\n\n| Method | Purpose | Behavior |\n|--------|---------|----------|\n| `ctx.task(taskDef, args, opts?)` | Execute a task | Returns result or throws typed exception |\n| `ctx.breakpoint(payload)` | Human approval gate | Pauses until approved via human |\n| `ctx.sleepUntil(isoOrEpochMs)` | Time-based gate | Pauses until specified time |\n| `ctx.parallel.all([...thunks])` | Parallel execution | Runs independent tasks concurrently |\n| `ctx.parallel.map(items, fn)` | Parallel map | Maps items through task function |\n| `ctx.now()` | Deterministic time | Returns current Date (or provided time) |\n| `ctx.log?.(level, msg, data?)` | Logging | Optional logging helper |\n| `ctx.runId` | Run identifier | Current run's unique ID |\n\n### Task Kinds\n\n| Kind | Use Case | Executor |\n|------|----------|----------|\n| `node` | Scripts, builds, tests | Node.js process |\n| `agent` | LLM-powered analysis, generation | Claude Code agent |\n| `skill` | Claude Code skills | Skill invocation |\n| `shell` | System commands | Shell execution |\n| `breakpoint` | Human approval | Breakpoints UI/service |\n| `sleep` | Time gates | Orchestrator scheduling |\n| `orchestrator_task` | Internal orchestrator work | Self-routed |\n\n---\n\n## Breakpoint Patterns\n\n### Basic Approval Gate\n\n```javascript\nawait ctx.breakpoint({\n question: 'Approve to continue?',\n title: 'Checkpoint',\n context: { runId: ctx.runId }\n});\n```\n\n### With File References (for UI display)\n\n```javascript\nawait ctx.breakpoint({\n question: 'Review the generated specification. Does it meet requirements?',\n title: 'Specification Review',\n context: {\n runId: ctx.runId,\n files: [\n { path: 'artifacts/spec.md', format: 'markdown', label: 'Specification' },\n { path: 'artifacts/spec.json', format: 'json', label: 'JSON Schema' },\n { path: 'src/implementation.ts', format: 'code', language: 'typescript', label: 'Implementation' }\n ]\n }\n});\n```\n\n### Conditional Breakpoint\n\n```javascript\nif (qualityScore < targetScore) {\n await ctx.breakpoint({\n question: `Quality score ${qualityScore} is below target ${targetScore}. Continue iterating or accept current result?`,\n title: 'Quality Gate',\n context: {\n runId: ctx.runId,\n data: { qualityScore, targetScore, iteration }\n }\n });\n}\n```\n\n---\n\n## Common Patterns\n\n### Quality Convergence Loop\n\n```javascript\nlet quality = 0;\nlet iteration = 0;\nconst targetQuality = inputs.targetQuality || 85;\nconst maxIterations = inputs.maxIterations || 10;\n\nwhile (quality < targetQuality && iteration < maxIterations) {\n iteration++;\n ctx.log?.('info', `Iteration ${iteration}/${maxIterations}`);\n\n // Execute improvement tasks\n const improvement = await ctx.task(improveTask, { iteration });\n\n // Score quality (parallel checks)\n const [coverage, lint, security, tests] = await ctx.parallel.all([\n () => ctx.task(coverageTask, {}),\n () => ctx.task(lintTask, {}),\n () => ctx.task(securityTask, {}),\n () => ctx.task(runTestsTask, {})\n ]);\n\n // Agent scores overall quality\n const score = await ctx.task(agentScoringTask, {\n coverage, lint, security, tests, iteration\n });\n\n quality = score.overall;\n ctx.log?.('info', `Quality: ${quality}/${targetQuality}`);\n\n if (quality >= targetQuality) {\n ctx.log?.('info', 'Quality target achieved!');\n break;\n }\n}\n\nreturn {\n success: quality >= targetQuality,\n quality,\n iterations: iteration\n};\n```\n\n### Phased Workflow with Reviews\n\n```javascript\n// Phase 1: Research\nconst research = await ctx.task(researchTask, { topic: inputs.topic });\n\nawait ctx.breakpoint({\n question: 'Review research findings before proceeding to planning.',\n title: 'Research Review',\n context: { runId: ctx.runId }\n});\n\n// Phase 2: Planning\nconst plan = await ctx.task(planningTask, { research });\n\nawait ctx.breakpoint({\n question: 'Review plan before implementation.',\n title: 'Plan Review',\n context: { runId: ctx.runId }\n});\n\n// Phase 3: Implementation\nconst implementation = await ctx.task(implementTask, { plan });\n\n// Phase 4: Verification\nconst verification = await ctx.task(verifyTask, { implementation, plan });\n\nawait ctx.breakpoint({\n question: 'Final review before completion.',\n title: 'Final Approval',\n context: { runId: ctx.runId }\n});\n\nreturn { success: verification.passed, plan, implementation };\n```\n\n### Parallel Fan-out with Aggregation\n\n```javascript\n// Fan out to multiple parallel analyses\nconst analyses = await ctx.parallel.map(components, component =>\n ctx.task(analyzeTask, { component }, { label: `analyze:${component.name}` })\n);\n\n// Aggregate results\nconst aggregated = await ctx.task(aggregateTask, { analyses });\n\nreturn { analyses, summary: aggregated.summary };\n```\n\n---\n\n## Testing Processes\n\n### CLI Commands\n\n```bash\n# Create a new run\nbabysitter run:create \\\n --process-id methodologies/my-process \\\n --entry ./library/methodologies/my-process.js#process \\\n --inputs ./test-inputs.json \\\n --json\n\n# Iterate the run\nbabysitter run:iterate .a5c/runs/ --json\n\n# List pending tasks\nbabysitter task:list .a5c/runs/ --pending --json\n\n# Post a task result\nbabysitter task:post .a5c/runs/ \\\n --status ok \\\n --value ./result.json\n\n# Check run status\nbabysitter run:status .a5c/runs/\n\n# View events\nbabysitter run:events .a5c/runs/ --limit 20 --reverse\n```\n\n### Sample Test Input File\n\n```json\n{\n \"feature\": \"User authentication with JWT\",\n \"acceptanceCriteria\": [\n \"Users can register with email and password\",\n \"Users can login and receive a JWT token\",\n \"Invalid credentials are rejected\"\n ],\n \"testFramework\": \"jest\",\n \"targetQuality\": 85,\n \"maxIterations\": 5\n}\n```\n\n---\n\n## Process Builder Workflow\n\n### 1. Gather Requirements\n\nAsk the user:\n\n| Question | Purpose |\n|----------|---------|\n| **Domain/Category** | Determines directory location |\n| **Process Name** | kebab-case identifier |\n| **Goal** | What should the process accomplish? |\n| **Inputs** | What data does the process need? |\n| **Outputs** | What artifacts/results does it produce? |\n| **Phases** | What are the major steps? |\n| **Quality Gates** | Where should humans review? |\n| **Iteration Strategy** | Fixed phases vs. convergence loop? |\n\n### 2. Research Similar Processes\n\n```bash\n# Find similar processes\nls library/methodologies/\nls library/specializations/\n\n# Read similar process for patterns\ncat library/methodologies/atdd-tdd/atdd-tdd.js | head -200\n\n# Check methodology README structure\ncat library/methodologies/atdd-tdd/README.md\n```\n\n### 3. Check Methodologies Backlog\n\n```bash\ncat library/methodologies/backlog.md\n```\n\n### 4. Create the Process\n\n**For Methodologies:**\n1. Create `methodologies/[name]/README.md` (comprehensive documentation)\n2. Create `methodologies/[name]/[name].js` (process implementation)\n3. Create `methodologies/[name]/examples/` (sample inputs)\n\n**For Specializations:**\n1. If domain-specific: `specializations/domains/[domain]/[spec]/`\n2. If engineering: `specializations/[category]/[process].js`\n3. Create README.md, references.md, processes-backlog.md first\n4. Then create individual process.js files\n\n### 5. Validate Structure\n\nChecklist:\n- [ ] JSDoc header with @process, @description, @inputs, @outputs, @example, @references\n- [ ] `@graph` block with relevant atlas node IDs (at minimum one domain)\n- [ ] Import from `@a5c-ai/babysitter-sdk`\n- [ ] Main `export async function process(inputs, ctx)`\n- [ ] Input destructuring with defaults\n- [ ] Clear phase comments (`// === PHASE N: NAME ===`)\n- [ ] Logging via `ctx.log?.('info', message)`\n- [ ] Tasks via `ctx.task(taskDef, inputs)`\n- [ ] Breakpoints at key decision points\n- [ ] Artifact collection throughout\n- [ ] Return object matches @outputs schema\n\n---\n\n## Examples by Type\n\n### Methodology Process (atdd-tdd style)\n\n```javascript\n/**\n * @process methodologies/my-methodology\n * @description My development methodology with quality convergence\n * @inputs { feature: string, targetQuality?: number }\n * @outputs { success: boolean, quality: number, artifacts: array }\n */\nexport async function process(inputs, ctx) {\n const { feature, targetQuality = 85 } = inputs;\n // ... implementation\n}\n```\n\n### Specialization Process (game-development style)\n\n```javascript\n/**\n * @process specializations/game-development/core-mechanics-prototyping\n * @description Prototype and validate core gameplay mechanics through iteration\n * @inputs { prototypeName: string, mechanicsToTest: array, engine?: string }\n * @outputs { success: boolean, mechanicsValidated: array, playtestResults: object }\n */\nexport async function process(inputs, ctx) {\n const { prototypeName, mechanicsToTest, engine = 'Unity' } = inputs;\n // ... implementation\n}\n```\n\n### Domain Process (science/research style)\n\n```javascript\n/**\n * @process specializations/domains/science/bioinformatics/sequence-analysis\n * @description Analyze genomic sequences using standard bioinformatics workflows\n * @inputs { sequences: array, analysisType: string, referenceGenome?: string }\n * @outputs { success: boolean, alignments: array, variants: array, report: object }\n */\nexport async function process(inputs, ctx) {\n const { sequences, analysisType, referenceGenome = 'GRCh38' } = inputs;\n // ... implementation\n}\n```\n\n---\n\n## Atlas Graph Metadata\n\nEvery generated process file MUST include a `@graph` JSDoc block in its file header comment alongside the standard `@process`, `@description`, `@inputs`, and `@outputs` tags.\n\n### Format\n\n```javascript\n/**\n * @process specializations/my-domain/my-process\n * @description ...\n * @inputs { ... }\n * @outputs { ... }\n *\n * @graph\n * domains: [domain:software-engineering, domain:devops]\n * skillAreas: [skill-area:caching-strategies]\n * topics: [topic:microservices, topic:event-sourcing]\n * roles: [role:backend-engineer, role:sre]\n * workflows: [workflow:code-review]\n */\n```\n\n### How to choose node IDs\n\nRead the atlas graph domain directory (`packages/atlas/graph/domain/`) to find valid node IDs. The directory contains YAML files grouped by category:\n\n- `domains/` — high-level domain nodes (e.g. `domain:software-engineering`, `domain:devops`, `domain:data-engineering`)\n- `skill-areas/` — specific skill area nodes\n- `topics/` — granular topic nodes\n- `roles/` — role nodes (engineers, practitioners, researchers)\n- `workflows/` — workflow nodes\n\nPick **2–4 edges** that genuinely relate to the process. Do not guess IDs — read the actual YAML files to find valid ones. At minimum, **every process must reference at least one `domain:` node**.\n\n### Why this matters\n\nThis metadata connects the process to the atlas knowledge graph. A pre-build generator script parses the `@graph` block and creates graph nodes and edges for discoverability. Processes without this block will not appear in graph-based search results or recommendations.\n\n---\n\n## Resources\n\n- **SDK Reference**: `library/reference/sdk.md`\n- **Methodology Backlog**: `library/methodologies/backlog.md`\n- **Specializations Backlog**: `library/specializations/backlog.md`\n- **Example: ATDD/TDD**: `library/methodologies/atdd-tdd/`\n- **Example: Spec-Driven**: `library/methodologies/spec-driven-development.js`\n- **README**: Root `README.md` for full framework documentation","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/process-builder","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":".claude/skills/process-builder/SKILL.md","defaultBranch":"main"},"readme":"# Process Builder\n\nCreate new process definitions for the babysitter event-sourced orchestration framework.\n\n## Quick Reference\n\n```\nProcesses live in: library/\n├── methodologies/ # Reusable development approaches (TDD, BDD, Scrum, etc.)\n│ └── [name]/\n│ ├── README.md # Documentation\n│ ├── [name].js # Main process\n│ └── examples/ # Sample inputs\n│\n└── specializations/ # Domain-specific processes\n ├── [category]/ # Engineering specializations (direct children)\n │ └── [process].js\n └── domains/\n └── [domain]/ # Business, Science, Social Sciences\n └── [spec]/\n ├── README.md\n ├── references.md\n ├── processes-backlog.md\n └── [process].js\n```\n\n## 3-Phase Workflow\n\n### Phase 1: Research & Documentation\n\nCreate foundational documentation:\n\n```bash\n# Check existing specializations\nls library/specializations/\n\n# Check methodologies\nls library/methodologies/\n```\n\n**Create:**\n- `README.md` - Overview, roles, goals, use cases, common flows\n- `references.md` - External references, best practices, links to sources\n\n### Phase 2: Identify Processes\n\nCreate `processes-backlog.md` with identified processes:\n\n```markdown\n# Processes Backlog - [Specialization Name]\n\n## Identified Processes\n\n- [ ] **process-name** - Short description of what this process accomplishes\n - Reference: [Link to methodology or standard]\n - Inputs: list key inputs\n - Outputs: list key outputs\n\n- [ ] **another-process** - Description\n ...\n```\n\n### Phase 3: Create Process Files\n\nCreate `.js` process files following SDK patterns (see below).\n\n---\n\n## Process File Structure\n\nEvery process file follows this pattern:\n\n```javascript\n/**\n * @process [category]/[process-name]\n * @description Clear description of what the process accomplishes end-to-end\n * @inputs { inputName: type, optionalInput?: type }\n * @outputs { success: boolean, outputName: type, artifacts: array }\n *\n * @graph\n * domains: [domain:software-engineering]\n * skillAreas: [skill-area:your-skill-area]\n * topics: [topic:your-topic]\n * roles: [role:your-role]\n * workflows: [workflow:your-workflow]\n *\n * @example\n * const result = await orchestrate('[category]/[process-name]', {\n * inputName: 'value',\n * optionalInput: 'optional-value'\n * });\n *\n * @references\n * - Book: \"Relevant Book Title\" by Author\n * - Article: [Title](https://link)\n * - Standard: ISO/IEEE reference\n */\n\nimport { defineTask } from '@a5c-ai/babysitter-sdk';\n\n/**\n * [Process Name] Process\n *\n * Methodology: Brief description of the approach\n *\n * Phases:\n * 1. Phase Name - What happens\n * 2. Phase Name - What happens\n * ...\n *\n * Benefits:\n * - Benefit 1\n * - Benefit 2\n *\n * @param {Object} inputs - Process inputs\n * @param {string} inputs.inputName - Description of input\n * @param {Object} ctx - Process context (see SDK)\n * @returns {Promise} Process result\n */\nexport async function process(inputs, ctx) {\n const {\n inputName,\n optionalInput = 'default-value',\n // ... destructure with defaults\n } = inputs;\n\n const artifacts = [];\n\n // ============================================================================\n // PHASE 1: [PHASE NAME]\n // ============================================================================\n\n ctx.log?.('info', 'Starting Phase 1...');\n\n const phase1Result = await ctx.task(someTask, {\n // task inputs\n });\n\n artifacts.push(...(phase1Result.artifacts || []));\n\n // Breakpoint for human review (when needed)\n await ctx.breakpoint({\n question: 'Review the results and approve to continue?',\n title: 'Phase 1 Review',\n context: {\n runId: ctx.runId,\n files: [\n { path: 'artifacts/output.md', format: 'markdown', label: 'Output' }\n ]\n }\n });\n\n // ============================================================================\n // PHASE 2: [PHASE NAME] - Parallel Execution Example\n // =================","createdAt":"2026-09-25T11:52:32.429Z","updatedAt":"2026-09-25T11:52:32.429Z"},{"id":"cmugwijzv028equ067ufe4n4y","slug":"a5c-ai-babysitter-retrospect-external-babysitter-run","name":"retrospect-external-babysitter-run","description":"For a repository in the babysitter-users catalog, locate its babysitter processes and any committed runs (.a5c/runs//) and perform a retrospective on a chosen run -- what went well, what failed, process suggestions, quality of effect design, breakpoint patterns -- mirroring the /babysitter:retrospect workflow but applied to an external repo. Invoke when asked to \"retrospect on repo X's run\", \"analyze how someone else used babysitter\", or \"review an external babysitter run\".","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"retrospect-external-babysitter-run","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"For a repository in the babysitter-users catalog, locate its babysitter processes and any committed runs (.a5c/runs//) and perform a retrospective on a chosen run -- what went well, what failed, process suggestions, quality of effect design, breakpoint patterns -- mirroring the /babysitter:retrospect workflow but applied to an external repo. Invoke when asked to \"retrospect on repo X's run\", \"analyze how someone else used babysitter\", or \"review an external babysitter run\".","permissions":[],"systemPrompt":"# Retrospect External Babysitter Run\n\nAnalyse a babysitter run that lives in an external public repository, using the same lens as the in-repo `/babysitter:retrospect` command. Produce a written retrospective with concrete suggestions for the process author (or, if the insight generalizes, for the babysitter project itself).\n\n## When to use\n\n- User names an external repo and asks for a retrospective.\n- User asks \"find a babysitter run to retrospect on\" (combine with the `catalog-babysitter-users` skill to pick one).\n- User asks \"how are other people using babysitter processes? What do they get wrong?\".\n\n## Prerequisites\n\n- `gh` CLI authenticated.\n- `docs/repo-with-babysitter-processes.md` exists (if not, run the `catalog-babysitter-users` skill first).\n- A workspace directory where external repos can be shallow-cloned (default: `/tmp/babysitter-retrospect/` or `.a5c/tmp/external-runs/`).\n\n## Phase 1 -- Target selection\n\n1. Read `docs/repo-with-babysitter-processes.md` and list Active repos with stars + description. If the user already named a repo, skip to step 3.\n2. Ask the user which repo to retrospect on (use AskUserQuestion in interactive mode; if non-interactive, pick the highest-starred Active repo that wasn't retrospected in the last 30 days -- track via `docs/retrospectives/-/log.md`).\n3. Confirm the target with the user before cloning.\n\n## Phase 2 -- Discover processes and runs\n\nShallow clone the target:\n\n```bash\nmkdir -p .a5c/tmp/external-runs\ncd .a5c/tmp/external-runs\ngh repo clone / -- --depth 50 --single-branch\ncd \n```\n\nLocate:\n\n- **Process files**: files importing `defineTask` from `@a5c-ai/babysitter-sdk`. Use Grep: `grep -rl \"from '@a5c-ai/babysitter-sdk'\" -- . --include='*.js' --include='*.ts'`.\n- **Committed runs**: `.a5c/runs//` directories. Many repos gitignore `.a5c/runs/` entirely -- that's fine; note it and proceed with process-only retrospective. When runs ARE committed, look for `run.json`, `journal/`, `tasks/`, `state/output.json`.\n- **Historical runs via git log**: `git log --all --diff-filter=A --name-only -- '.a5c/runs/'` surfaces runs that existed at some commit even if later cleaned up. Check out the commit that introduced the run if you want the journal content.\n\nSummarize to the user:\n\n- N process files found, by top-level directory\n- M run directories present in HEAD; P additional historical runs reachable via git history\n- Which runs completed vs failed (grep `RUN_COMPLETED` / `RUN_FAILED` in the journal)\n\n## Phase 3 -- Pick a run to retrospect\n\nIf multiple runs exist, ask the user (interactive) or default (non-interactive) to:\n\n- The most recent failed run (highest signal for process improvement), OR\n- If no failures, the most recent completed run.\n\nIf no runs are committed at all, switch to a **process-only retrospective**: analyse the process file(s) for quality issues without run evidence. Mark the output clearly as process-only.\n\n## Phase 4 -- Load the run\n\nInspect, in order:\n\n- `.a5c/runs//run.json` -- processId, entrypoint, prompt, createdAt\n- `.a5c/runs//inputs.json` -- user intent\n- `.a5c/runs//journal/*.json` -- event stream (RUN_CREATED, EFFECT_REQUESTED, EFFECT_RESOLVED, RUN_COMPLETED / RUN_FAILED). Read every journal entry; it is the authoritative record.\n- `.a5c/runs//tasks//task.json` + `result.json` -- per-effect definition and result\n- `.a5c/runs//state/output.json` (if present) -- final output\n- The process file referenced by `run.json.entrypoint` -- cross-reference against the journal to see what the author intended vs what happened.\n\n## Phase 5 -- Retrospective analysis\n\nMirror the in-repo `/babysitter:retrospect` workflow. Produce notes under each heading:\n\n### 5.1 Outcome\n\n- Success / partial success / failure.\n- Total iterations, duration, distinct effect count, retry count.\n- Final output quality (from `state/output.json` shape + content).\n\n### 5.2 What went well\n\n- Effects that resolved on first try.\n- Process sections with clear inputs/outputs and no re-runs.\n- Useful breakpoints that caught real issues before they propagated.\n\n### 5.3 What went poorly\n\n- Effects that were re-dispatched (same invocationKey or similar taskId appearing repeatedly).\n- Long gaps between EFFECT_REQUESTED and EFFECT_RESOLVED (external bottlenecks).\n- Breakpoints that looped (approval -> reject -> retry -> reject).\n- Tasks that crashed and what the error category was (Configuration / Validation / Runtime / External / Internal).\n- Any RUN_FAILED: trace the last few events and the thrown error.\n\n### 5.4 Process-quality review\n\nEvaluate the process file itself against these criteria:\n\n- Determinism: does every effect have stable invocation keys (processId:stepId:taskId)? Any non-deterministic branching based on wall-clock time, random, or unpinned env vars?\n- Effect granularity: are tasks too coarse (one huge agent task vs several narrower ones) or too fine (dozens of tiny tasks)?\n- Idempotency: can the process be re-run safely? Does it use `ctx.task()` for all side effects, or does it write files outside a task?\n- Breakpoint discipline: are breakpoints used to gate irreversible actions? Do they follow the robust rejection pattern (loop with feedback)?\n- Error surfacing: does the process throw with useful context, or swallow errors?\n- Labels: are task labels meaningful and consistent (enables filtering / observability)?\n- Re-use: could any section be replaced by a shared component from `library/processes/shared/`?\n\n### 5.5 Suggestions\n\nConcrete, actionable suggestions in three buckets:\n\n- **For the run** (if still in progress): what to retry, rollback, or fix first.\n- **For the process** (always): specific edits to the process file -- split this task, add this breakpoint, move that side-effect inside a task, use stableKey here.\n\nCan it be generalized into a reusable pattern or library process in the processes library? If so, suggest that too. (also using `/babysitter:contrib library ...`)\n\n- **For babysitter upstream** (when the insight generalizes): missing primitives, confusing SDK behavior, documentation gaps worth filing via `/babysitter:contrib`.\n\nEvery suggestion must cite evidence -- a journal event, a file path, a line range.\n\n## Phase 6 -- Write the retrospective\n\nWrite to `docs/retrospectives/-/.md` with this structure:\n\n```markdown\n# Retrospective: / -- \n\nDate: YYYY-MM-DD\nSource commit: \nProcess: \nRun: \nOutcome: \n\n## Context\n<1-3 sentences on what the process is trying to do and the user intent from inputs.json>\n\n## Timeline\n\n\n## What went well\n...\n\n## What went poorly\n...\n\n## Process-quality review\n...\n\n## Suggestions\n### For the run\n### For the process\n### For babysitter upstream\n\n## Evidence\n\n```\n\nAlso append a one-line entry to `docs/retrospectives/-/log.md` with the date, runId, and outcome, so we don't re-retrospect the same run.\n\n## Phase 7 -- Cleanup and callbacks\n\n- Leave the shallow clone under `.a5c/tmp/external-runs/` in place (it's cheap). If disk pressure, note this to the user; do NOT auto-delete.\n- Suggest the user use `/babysitter:contrib` for any upstream-worthy insight:\n - Process/skill improvement idea -> `/babysitter:contrib library contribution: [description]`\n - SDK/CLI bug or missing primitive -> `/babysitter:contrib bug report: [description]`\n - Documentation gap that tripped the external author -> `/babysitter:contrib documentation question: [what was unclear]`\n- If the process author is findable (repo owner, git author of the process file), suggest opening an issue on their repo with a pointer to the retrospective document.\n\n## Notes\n\n- Honour the target repo's LICENSE when quoting code in the retrospective. Short excerpts for analysis are fair use; do not wholesale copy process files into this repo.\n- Never execute the external process -- retrospectives are read-only analysis.\n- If the run journal is very large (>500 events), sample: first 20, last 20, plus every EFFECT that transitioned to resolved or failed.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/retrospect-external-babysitter-run","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":".claude/skills/retrospect-external-babysitter-run/SKILL.md","defaultBranch":"main"},"readme":"# Retrospect External Babysitter Run\n\nAnalyse a babysitter run that lives in an external public repository, using the same lens as the in-repo `/babysitter:retrospect` command. Produce a written retrospective with concrete suggestions for the process author (or, if the insight generalizes, for the babysitter project itself).\n\n## When to use\n\n- User names an external repo and asks for a retrospective.\n- User asks \"find a babysitter run to retrospect on\" (combine with the `catalog-babysitter-users` skill to pick one).\n- User asks \"how are other people using babysitter processes? What do they get wrong?\".\n\n## Prerequisites\n\n- `gh` CLI authenticated.\n- `docs/repo-with-babysitter-processes.md` exists (if not, run the `catalog-babysitter-users` skill first).\n- A workspace directory where external repos can be shallow-cloned (default: `/tmp/babysitter-retrospect/` or `.a5c/tmp/external-runs/`).\n\n## Phase 1 -- Target selection\n\n1. Read `docs/repo-with-babysitter-processes.md` and list Active repos with stars + description. If the user already named a repo, skip to step 3.\n2. Ask the user which repo to retrospect on (use AskUserQuestion in interactive mode; if non-interactive, pick the highest-starred Active repo that wasn't retrospected in the last 30 days -- track via `docs/retrospectives/-/log.md`).\n3. Confirm the target with the user before cloning.\n\n## Phase 2 -- Discover processes and runs\n\nShallow clone the target:\n\n```bash\nmkdir -p .a5c/tmp/external-runs\ncd .a5c/tmp/external-runs\ngh repo clone / -- --depth 50 --single-branch\ncd \n```\n\nLocate:\n\n- **Process files**: files importing `defineTask` from `@a5c-ai/babysitter-sdk`. Use Grep: `grep -rl \"from '@a5c-ai/babysitter-sdk'\" -- . --include='*.js' --include='*.ts'`.\n- **Committed runs**: `.a5c/runs//` directories. Many repos gitignore `.a5c/runs/` entirely -- that's fine; note it and proceed with process-only retrospective. When runs ARE committed, look for `run.json`, `journal/`, `tasks/`, `state/output.json`.\n- **Historical runs via git log**: `git log --all --diff-filter=A --name-only -- '.a5c/runs/'` surfaces runs that existed at some commit even if later cleaned up. Check out the commit that introduced the run if you want the journal content.\n\nSummarize to the user:\n\n- N process files found, by top-level directory\n- M run directories present in HEAD; P additional historical runs reachable via git history\n- Which runs completed vs failed (grep `RUN_COMPLETED` / `RUN_FAILED` in the journal)\n\n## Phase 3 -- Pick a run to retrospect\n\nIf multiple runs exist, ask the user (interactive) or default (non-interactive) to:\n\n- The most recent failed run (highest signal for process improvement), OR\n- If no failures, the most recent completed run.\n\nIf no runs are committed at all, switch to a **process-only retrospective**: analyse the process file(s) for quality issues without run evidence. Mark the output clearly as process-only.\n\n## Phase 4 -- Load the run\n\nInspect, in order:\n\n- `.a5c/runs//run.json` -- processId, entrypoint, prompt, createdAt\n- `.a5c/runs//inputs.json` -- user intent\n- `.a5c/runs//journal/*.json` -- event stream (RUN_CREATED, EFFECT_REQUESTED, EFFECT_RESOLVED, RUN_COMPLETED / RUN_FAILED). Read every journal entry; it is the authoritative record.\n- `.a5c/runs//tasks//task.json` + `result.json` -- per-effect definition and result\n- `.a5c/runs//state/output.json` (if present) -- final output\n- The process file referenced by `run.json.entrypoint` -- cross-reference against the journal to see what the author intended vs what happened.\n\n## Phase 5 -- Retrospective analysis\n\nMirror the in-repo `/babysitter:retrospect` workflow. Produce notes under each heading:\n\n### 5.1 Outcome\n\n- Success / partial success / failure.\n- Total iterations, duration, distinct effect count, retry count.\n- Final output quality (from `state/output.json` shape + content).\n\n### 5.2 What went well\n\n- Effects that resolve","createdAt":"2026-09-25T11:52:32.443Z","updatedAt":"2026-09-25T11:52:32.443Z"},{"id":"cmugwijxq027wqu06c9gaojl8","slug":"a5c-ai-babysitter-atlas","name":"atlas","description":"Babysitter enforces obedience on agentic workforces and enables them to manage extremely complex tasks and workflows through deterministic, hallucination-free self-orchestration","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"MCP","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"atlas","tools":[],"category":"MCP","entrypoint":{"args":["-y","mcp-remote","https://atlas-staging.a5c.ai/api/mcp"],"type":"mcp-stdio","command":"npx"},"description":"","permissions":["shell","network"],"requiredEnv":[],"schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":".mcp.json","manifestPath":".mcp.json","defaultBranch":"main"},"readme":"
\n\n# Babysitter\n> **Enforce obedience on agentic workforces. Manage extremely complex workflows through deterministic, hallucination-free self-orchestration.**\n\n[![npm version](https://img.shields.io/npm/v/@a5c-ai/babysitter.svg)](https://www.npmjs.com/package/@a5c-ai/babysitter)\n[![CI](https://img.shields.io/github/actions/workflow/status/a5c-ai/babysitter/ci.yml?branch=staging)](https://github.com/a5c-ai/babysitter/actions/workflows/ci.yml)\n[![npm downloads](https://img.shields.io/npm/dm/@a5c-ai/babysitter?label=downloads)](https://www.npmjs.com/package/@a5c-ai/babysitter)\n[![Node.js](https://img.shields.io/node/v/@a5c-ai/babysitter)](https://nodejs.org/)\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![GitHub issues](https://img.shields.io/github/issues/a5c-ai/babysitter.svg)](https://github.com/a5c-ai/babysitter/issues)\n[![GitHub stars](https://img.shields.io/github/stars/a5c-ai/babysitter.svg)](https://github.com/a5c-ai/babysitter/stargazers)\n\n---\n\n[Getting Started](#installation) | [Documentation](#documentation) | [Community](#community-and-support)\n\n
\n\n---\n\nhttps://github.com/user-attachments/assets/8c3b0078-9396-48e8-aa43-5f40da30c20b\n\n---\n\n## Table of Contents\n\n- [What is Babysitter?](#what-is-babysitter)\n- [Prerequisites](#prerequisites)\n- [Installation](#installation)\n- [First Steps](#first-steps)\n- [Quick Start](#quick-start)\n- [Agent Runtime CLI](#agent-runtime-cli)\n- [How It Works](#how-it-works)\n- [Why Babysitter?](#why-babysitter)\n- [Blueprints](#blueprints)\n- [Compression](#compression)\n- [Documentation](#documentation)\n- [Contributing](#contributing)\n- [Community and Support](#community-and-support)\n- [License](#license)\n\n---\n\n## What is Babysitter?\n\nBabysitter enforces obedience to agentic workforces, enabling them to manage extremely complex tasks and workflows through deterministic, hallucination-free self-orchestration. Define your workflow in code - Babysitter enforces every step, ensures quality gates pass before progression, requires human approval at breakpoints, and records every decision in an immutable journal. Your agents do exactly what the process permits, nothing more.\n\nAs of v6, Babysitter is harness-agnostic via its **Adapters** runtime: the same processes run across the 12 supported AI coding harnesses, so you are not locked to a single tool. See [Adapters](docs/user-guide/features/adapters.md) and the [harness install matrix](docs/user-guide/harnesses/install-matrix.md).\n\n---\n\n## Prerequisites\n\n- **Node.js**: Version 20.0.0+ (22.x LTS recommended). The host-side `adapters` CLI pins a higher floor of 22.13.0+ (it loads the gateway's built-in `node:sqlite`, unflagged only from Node 22.13.0).\n- **A supported AI coding harness**: any of the 12 harnesses covered in the [install matrix](docs/user-guide/harnesses/install-matrix.md) (e.g. Claude Code — [docs](https://code.claude.com/docs/en/quickstart)).\n- **Git**: For cloning (optional)\n\n---\n\n## Installation\n\nBabysitter v6 has two install tracks that should not be conflated: the **host-side `adapters` CLI** for running any harness directly from your shell, and the **in-session per-harness plugin** for driving full orchestration runs from inside your harness. Most people want both. The package split is:\n\n- `@a5c-ai/babysitter` is the recommended end-user install for the main `babysitter` CLI.\n- `@a5c-ai/adapters-cli` provides the host-side `adapters` CLI (Node >=22.13.0) for running and managing any supported harness from your shell. See the [Adapters CLI reference](docs/user-guide/reference/adapters-cli.md).\n- `@a5c-ai/babysitter-sdk` is the public SDK/library package and the underlying implementation behind the core CLI.\n- `@a5c-ai/genty-platform` is the optional runtime CLI for `genty call`, `resume`, `start-server`, `tui`, and other orchestration/runtime commands.\n- Harness plugins such as `@a5c-ai/babysitter-codex` or `@a5c-ai/babysitter-cursor` integrate Ba","createdAt":"2026-09-25T11:52:32.366Z","updatedAt":"2026-09-25T11:52:32.366Z"},{"id":"cmugwijy5027zqu06ioa9ol0d","slug":"a5c-ai-babysitter-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/.","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"assimilate-popular-workflows","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"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/.","permissions":[],"systemPrompt":"# 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//` | 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//` | 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// \\\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/ 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: \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\n- **Process name**: Description of what it does\n - Source: path/to/SKILL.md (lines N-M)\n - Placement: methodologies/ | specializations/shared | specializations/\n - Inputs/Outputs: ...\n - Complexity: simple | moderate | complex\n - Notes: ...\n\n## Plugin Ideas\n\n- **Plugin name**: What it installs and configures\n - What install.md would do: \n - Processes it would copy: \n - Configs/hooks it would create: \n - Source evidence: \n - Marketplace placement: \n\n## Plugin Marketplace Mapping\n\n\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\n- **Harness Adapter**: New harness integration (like plugins/babysitter-codex for Codex)\n - Adapter implementation: \n - Plugin structure: \n - CLI integration: \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: \n - Babysitter integration: \n - Capability bridge: \n - Major limitations: \n- **TUI/Orchestration Improvement**: Enhancement to our internal agent harness\n - Current limitation: \n - Integration approach: \n - Implementation scope: \n\n## Implicit Procedural Knowledge\n\n- **Procedure name**: What it accomplishes\n - Source: SKILL.md section or description text\n - Placement: methodologies/ | specializations/shared | specializations/\n - Why codify: \n - Sketch: \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 \"\"\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// # Full generic dev methodologies only\n# specializations/shared/ # Cross-domain reusable patterns\n# specializations// # 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\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-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.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/assimilate-popular-workflows","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":".claude/skills/assimilate-popular-workflows/SKILL.md","defaultBranch":"main"},"readme":"# 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//` | 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//` | 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 th","createdAt":"2026-09-25T11:52:32.382Z","updatedAt":"2026-09-25T11:52:32.382Z"},{"id":"cmugwijym0282qu0627n1x7jo","slug":"a5c-ai-babysitter-babysit-babysitter-issues","name":"babysit-babysitter-issues","description":"This skill should be used when the user asks to \"babysit issues\", \"work on assigned issues\", \"check a5c-agent issues\", \"process babysitter issues\", or wants to find and work on open GitHub issues assigned to a5c-agent in the babysitter repo.","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"babysit-babysitter-issues","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"This skill should be used when the user asks to \"babysit issues\", \"work on assigned issues\", \"check a5c-agent issues\", \"process babysitter issues\", or wants to find and work on open GitHub issues assigned to a5c-agent in the babysitter repo.","permissions":[],"systemPrompt":"# Babysit Babysitter Issues\n\nFetch open GitHub issues from https://github.com/a5c-ai/babysitter/issues assigned to `a5c-agent`, then orchestrate work on each issue via `/babysitter:call`.\n\n## Workflow\n\n### Step 1: Fetch Assigned Issues\n\nUse the `gh` CLI to list open issues assigned to `a5c-agent`:\n\n```bash\ngh issue list --repo a5c-ai/babysitter --assignee a5c-agent --state open --json number,title,url,labels --limit 50\n```\n\nIf no issues are found, report that there are no open issues assigned to `a5c-agent` and stop.\n\n### Step 2: Present Issues\n\nDisplay the list of open issues to the user with their number, title, labels, and URL. \n\n### Step 3: Orchestrate via Babysitter\n\nFor each issue, invoke the `babysitter:yolo` skill with a prompt that includes the issue URL and context:\n\n```\n/babysitter:yolo work on this GitHub issue: \n```\n\nIf multiple issues are selected, process them sequentially -- complete one before starting the next. Present a summary after each issue is processed. as part of the process, create a new branch from staging named `issue-` and push commits to that branch. then create a pull request against staging with a meaningful name and a description of the work done (with link to the original issue). if the issue has a \"bug\" label, prioritize fixing the bug and include details about the bug and how it was fixed in the pull request description.\n\n### Step 4: Summary\n\nAfter all open a5c-assigned issues have been processed, provide a summary of what was done for each issue.\n\n## Notes\n\n- Only issues assigned to `a5c-agent` are fetched. Other assignees are ignored.\n- The `gh` CLI must be authenticated. If authentication fails, prompt the user to run `gh auth login`.\n- Each issue is handed off to `/babysitter:yolo` which handles the actual implementation work.\n- the entire workflow should be without any user interaction or breakpoints in the run, allowing for a seamless babysitting experience. do not let the user select which issues to work on -- just process all open a5c-assigned issues sequentially.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/babysit-babysitter-issues","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":".claude/skills/babysit-babysitter-issues/SKILL.md","defaultBranch":"main"},"readme":"# Babysit Babysitter Issues\n\nFetch open GitHub issues from https://github.com/a5c-ai/babysitter/issues assigned to `a5c-agent`, then orchestrate work on each issue via `/babysitter:call`.\n\n## Workflow\n\n### Step 1: Fetch Assigned Issues\n\nUse the `gh` CLI to list open issues assigned to `a5c-agent`:\n\n```bash\ngh issue list --repo a5c-ai/babysitter --assignee a5c-agent --state open --json number,title,url,labels --limit 50\n```\n\nIf no issues are found, report that there are no open issues assigned to `a5c-agent` and stop.\n\n### Step 2: Present Issues\n\nDisplay the list of open issues to the user with their number, title, labels, and URL. \n\n### Step 3: Orchestrate via Babysitter\n\nFor each issue, invoke the `babysitter:yolo` skill with a prompt that includes the issue URL and context:\n\n```\n/babysitter:yolo work on this GitHub issue: \n```\n\nIf multiple issues are selected, process them sequentially -- complete one before starting the next. Present a summary after each issue is processed. as part of the process, create a new branch from staging named `issue-` and push commits to that branch. then create a pull request against staging with a meaningful name and a description of the work done (with link to the original issue). if the issue has a \"bug\" label, prioritize fixing the bug and include details about the bug and how it was fixed in the pull request description.\n\n### Step 4: Summary\n\nAfter all open a5c-assigned issues have been processed, provide a summary of what was done for each issue.\n\n## Notes\n\n- Only issues assigned to `a5c-agent` are fetched. Other assignees are ignored.\n- The `gh` CLI must be authenticated. If authentication fails, prompt the user to run `gh auth login`.\n- Each issue is handed off to `/babysitter:yolo` which handles the actual implementation work.\n- the entire workflow should be without any user interaction or breakpoints in the run, allowing for a seamless babysitting experience. do not let the user select which issues to work on -- just process all open a5c-assigned issues sequentially.","createdAt":"2026-09-25T11:52:32.399Z","updatedAt":"2026-09-25T11:52:32.399Z"},{"id":"cmugwik05028hqu06u71o7c77","slug":"a5c-ai-babysitter-babysit","name":"babysit","description":"Orchestrate via @babysitter. Use this skill when asked to babysit a run, orchestrate a process or whenever it is called explicitly. (babysit, babysitter, orchestrate, orchestrate a run, workflow, etc.)","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"babysit","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Orchestrate via @babysitter. Use this skill when asked to babysit a run, orchestrate a process or whenever it is called explicitly. (babysit, babysitter, orchestrate, orchestrate a run, workflow, etc.)","permissions":[],"systemPrompt":"# babysit\n\nOrchestrate `.a5c/runs//` through iterative execution.\n\nSubagents that need a scratch checkout or working directory must create it under\n`/tmp//`, not under `.a5c/runs//work`. Before returning\ndeliverables, validate that no run-dir worktree was left behind, for example:\n\n```bash\nfind .a5c/runs -maxdepth 3 -name work -type d -print\n```\n\nThat command should print nothing. If it prints a non-empty work directory, move\nor remove only the scratch data you created before returning.\n\n## Dependencies\n\n### Babysitter SDK and CLI\n\nRead the SDK version from `versions.json` to ensure version compatibility:\n\n```bash\nSDK_VERSION=$(node -e \"try{console.log(JSON.parse(require('fs').readFileSync('${CODEX_PLUGIN_ROOT}/versions.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}\")\n```\n\nUse an installed `babysitter` command only after proving it can execute:\n\n```bash\nif command -v babysitter >/dev/null 2>&1 && babysitter --version >/dev/null 2>&1; then\n CLI=\"babysitter\"\nelse\n CLI=\"npm exec --yes --package @a5c-ai/babysitter-sdk@$SDK_VERSION -- babysitter\"\nfi\n```\n\nIf a stale or broken global shim fails with `MODULE_NOT_FOUND`, repair it with `npm rm -g @a5c-ai/babysitter @a5c-ai/babysitter-sdk && npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION`, then re-run `babysitter --version`.\n\n### jq\n\nMake sure `jq` is installed and available in the path. If not, install it.\n\n## Instructions\n\nRun the following command to get full orchestration instructions:\n\n```bash\n$CLI instructions:babysit-skill --harness codex --interactive\n```\n\nFor non-interactive runs (e.g., with `-p` flag or no question tool):\n\n```bash\n$CLI instructions:babysit-skill --harness codex --no-interactive\n```\n\nFollow the instructions returned by the command above to orchestrate the run.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/.codex/skills/babysit","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":".codex/skills/babysit/SKILL.md","defaultBranch":"main"},"readme":"# babysit\n\nOrchestrate `.a5c/runs//` through iterative execution.\n\nSubagents that need a scratch checkout or working directory must create it under\n`/tmp//`, not under `.a5c/runs//work`. Before returning\ndeliverables, validate that no run-dir worktree was left behind, for example:\n\n```bash\nfind .a5c/runs -maxdepth 3 -name work -type d -print\n```\n\nThat command should print nothing. If it prints a non-empty work directory, move\nor remove only the scratch data you created before returning.\n\n## Dependencies\n\n### Babysitter SDK and CLI\n\nRead the SDK version from `versions.json` to ensure version compatibility:\n\n```bash\nSDK_VERSION=$(node -e \"try{console.log(JSON.parse(require('fs').readFileSync('${CODEX_PLUGIN_ROOT}/versions.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}\")\n```\n\nUse an installed `babysitter` command only after proving it can execute:\n\n```bash\nif command -v babysitter >/dev/null 2>&1 && babysitter --version >/dev/null 2>&1; then\n CLI=\"babysitter\"\nelse\n CLI=\"npm exec --yes --package @a5c-ai/babysitter-sdk@$SDK_VERSION -- babysitter\"\nfi\n```\n\nIf a stale or broken global shim fails with `MODULE_NOT_FOUND`, repair it with `npm rm -g @a5c-ai/babysitter @a5c-ai/babysitter-sdk && npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION`, then re-run `babysitter --version`.\n\n### jq\n\nMake sure `jq` is installed and available in the path. If not, install it.\n\n## Instructions\n\nRun the following command to get full orchestration instructions:\n\n```bash\n$CLI instructions:babysit-skill --harness codex --interactive\n```\n\nFor non-interactive runs (e.g., with `-p` flag or no question tool):\n\n```bash\n$CLI instructions:babysit-skill --harness codex --no-interactive\n```\n\nFollow the instructions returned by the command above to orchestrate the run.","createdAt":"2026-09-25T11:52:32.453Z","updatedAt":"2026-09-25T11:52:32.453Z"},{"id":"cmugwik0c028kqu068dkfslhv","slug":"a5c-ai-babysitter-integrate-harness","name":"integrate-harness","description":"Use when adding a new agent harness (CLI-based coding agent) adapter to adapters. Covers capability audit, adapter scaffold, session parsing, auth detection, hooks/plugins wiring, tests, and docs.","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"integrate-harness","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Use when adding a new agent harness (CLI-based coding agent) adapter to adapters. Covers capability audit, adapter scaffold, session parsing, auth detection, hooks/plugins wiring, tests, and docs.","permissions":[],"systemPrompt":"# integrate-harness\n\nGoal: produce a production-quality `XAdapter extends BaseAgentAdapter` with full test coverage and documentation, matching the level of the existing 11 adapters (claude, codex, cursor, gemini, opencode, openclaw, copilot, hermes, pi, omp, adapters-remote).\n\n## Checklist\n\n1. **Capability audit** — read the harness's CLI docs. Fill in every `AgentCapabilities` field. Unknown? Set conservatively (`false`) and note in PR.\n2. **Create `packages/adapters/src/-adapter.ts`** extending `BaseAgentAdapter`. Required: `agent`, `displayName`, `cliCommand`, `minVersion`, `hostEnvSignals`, `capabilities`, `models[]`, `defaultModelId`, `configSchema`, `buildSpawnArgs`, `parseEvent`, `detectAuth`, `getAuthGuidance`, `sessionDir`, `parseSessionFile`, `listSessionFiles`, `readConfig`, `writeConfig`.\n3. **Session parsing** — if the harness stores JSONL sessions, delegate to `parseJsonlSessionFile`; otherwise write a custom parser and unit-test each event shape.\n4. **Hooks** — if the harness supports native hooks, override `writeNativeHook` and mirror into `HookConfigManager`. If not, rely on the base class's virtual hooks.\n5. **Plugins** — if it supports MCP servers under `mcpServers` in its config JSON, flip `supportsPlugins: true`, add `pluginFormats: ['mcp-server']`, and delegate to `mcp-plugins.ts` (see cursor/gemini/opencode/openclaw for the pattern).\n6. **Register** — add to `packages/adapters/src/index.ts` exports and to the default registry in `packages/core/src/client.ts` (if applicable).\n7. **Tests** — in `packages/adapters/tests/-adapter.test.ts`:\n - capability shape\n - `buildSpawnArgs` for a few representative `RunOptions`\n - `parseEvent` for each JSONL type the harness emits\n - `detectAuth` for authenticated + unauthenticated states\n - session file parsing from a real fixture (redacted)\n - If plugins: add the adapter to `mcp-plugins-parity.test.ts`.\n8. **CLI audit test** — ensure `packages/cli/tests/commands-audit.test.ts` passes (it exercises every adapter via the built CLI).\n9. **File-size limit** — each source file must stay under 400 effective lines (`local/max-file-lines`). Split helpers into sibling modules if you're close.\n10. **Docs** — add a row to the README capabilities matrix and a paragraph in `docs/02-agents/.md`.\n11. **Changeset** — `npm run changeset`, pick `minor` (new adapter), summarize.\n\n## Verification\n\n```bash\nnpm run typecheck\nnpm run lint\nnpm test\nnpx vitest run packages/adapters/tests/-adapter.test.ts\n```\n\nAll existing tests must continue to pass — no regressions in commands-audit.\n\n## Common pitfalls\n\n- Forgetting to add the adapter to the default registry → `commands-audit.test.ts` won't exercise it.\n- JSONL parsers that assume a single event per line — some harnesses emit arrays.\n- Auth detection that reads env vars synchronously at construction time instead of `detectAuth()` — breaks testability.\n- `buildSpawnArgs` returning the string `\"undefined\"` for missing options — always gate with `if (options.X != null)`.\n- Hook writers that overwrite rather than merge — use `appendJsonHook` or `appendYamlHook`.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/packages/adapters/skills/integrate-harness","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":"packages/adapters/skills/integrate-harness/SKILL.md","defaultBranch":"main"},"readme":"# integrate-harness\n\nGoal: produce a production-quality `XAdapter extends BaseAgentAdapter` with full test coverage and documentation, matching the level of the existing 11 adapters (claude, codex, cursor, gemini, opencode, openclaw, copilot, hermes, pi, omp, adapters-remote).\n\n## Checklist\n\n1. **Capability audit** — read the harness's CLI docs. Fill in every `AgentCapabilities` field. Unknown? Set conservatively (`false`) and note in PR.\n2. **Create `packages/adapters/src/-adapter.ts`** extending `BaseAgentAdapter`. Required: `agent`, `displayName`, `cliCommand`, `minVersion`, `hostEnvSignals`, `capabilities`, `models[]`, `defaultModelId`, `configSchema`, `buildSpawnArgs`, `parseEvent`, `detectAuth`, `getAuthGuidance`, `sessionDir`, `parseSessionFile`, `listSessionFiles`, `readConfig`, `writeConfig`.\n3. **Session parsing** — if the harness stores JSONL sessions, delegate to `parseJsonlSessionFile`; otherwise write a custom parser and unit-test each event shape.\n4. **Hooks** — if the harness supports native hooks, override `writeNativeHook` and mirror into `HookConfigManager`. If not, rely on the base class's virtual hooks.\n5. **Plugins** — if it supports MCP servers under `mcpServers` in its config JSON, flip `supportsPlugins: true`, add `pluginFormats: ['mcp-server']`, and delegate to `mcp-plugins.ts` (see cursor/gemini/opencode/openclaw for the pattern).\n6. **Register** — add to `packages/adapters/src/index.ts` exports and to the default registry in `packages/core/src/client.ts` (if applicable).\n7. **Tests** — in `packages/adapters/tests/-adapter.test.ts`:\n - capability shape\n - `buildSpawnArgs` for a few representative `RunOptions`\n - `parseEvent` for each JSONL type the harness emits\n - `detectAuth` for authenticated + unauthenticated states\n - session file parsing from a real fixture (redacted)\n - If plugins: add the adapter to `mcp-plugins-parity.test.ts`.\n8. **CLI audit test** — ensure `packages/cli/tests/commands-audit.test.ts` passes (it exercises every adapter via the built CLI).\n9. **File-size limit** — each source file must stay under 400 effective lines (`local/max-file-lines`). Split helpers into sibling modules if you're close.\n10. **Docs** — add a row to the README capabilities matrix and a paragraph in `docs/02-agents/.md`.\n11. **Changeset** — `npm run changeset`, pick `minor` (new adapter), summarize.\n\n## Verification\n\n```bash\nnpm run typecheck\nnpm run lint\nnpm test\nnpx vitest run packages/adapters/tests/-adapter.test.ts\n```\n\nAll existing tests must continue to pass — no regressions in commands-audit.\n\n## Common pitfalls\n\n- Forgetting to add the adapter to the default registry → `commands-audit.test.ts` won't exercise it.\n- JSONL parsers that assume a single event per line — some harnesses emit arrays.\n- Auth detection that reads env vars synchronously at construction time instead of `detectAuth()` — breaks testability.\n- `buildSpawnArgs` returning the string `\"undefined\"` for missing options — always gate with `if (options.X != null)`.\n- Hook writers that overwrite rather than merge — use `appendJsonHook` or `appendYamlHook`.","createdAt":"2026-09-25T11:52:32.461Z","updatedAt":"2026-09-25T11:52:32.461Z"},{"id":"cmugwik0m028nqu06fvohh0t8","slug":"a5c-ai-babysitter-atlas-graph-query","name":"atlas-graph-query","description":"Reference for querying the Atlas knowledge graph through its MCP tools — the SECONDARY enrichment/comparison layer that adds best-practice context to systems you have ALREADY scanned from your real sources (`az`, repos, dirs). Use when you need to look up nodes, edges, kinds, clusters, stats, or wiki pages in Atlas to compare against your real inventory. (atlas graph, query atlas, atlas mcp, search the graph, graph neighbors, atlas record, atlas kinds, enrichment layer)","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"atlas-graph-query","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Reference for querying the Atlas knowledge graph through its MCP tools — the SECONDARY enrichment/comparison layer that adds best-practice context to systems you have ALREADY scanned from your real sources (`az`, repos, dirs). Use when you need to look up nodes, edges, kinds, clusters, stats, or wiki pages in Atlas to compare against your real inventory. (atlas graph, query atlas, atlas mcp, search the graph, graph neighbors, atlas record, atlas kinds, enrichment layer)","permissions":[],"systemPrompt":"# atlas-graph-query\n\nA thin reference for the Atlas knowledge-graph MCP tool surface so any agent\n(including sub-agents) can query the graph without re-deriving conventions. The\nserver URL is wired natively by the `atlas` plugin and is overridable via\n`ATLAS_MCP_URL`. Never invent node ids — only use ids returned by these tools.\n\n> **Position: this is the SECONDARY / enrichment layer.** The `atlas` plugin is\n> scan-first — it inventories your REAL systems by scanning your actual sources\n> (Azure via read-only `az`, git repos, local directories) and process/data\n> mining them. The graph queries below are used ONLY to add best-practice /\n> comparison context to those already-discovered real systems. Do NOT use the\n> graph as the primary content, and never pad a real inventory with generic\n> catalog nodes. Tie every graph lookup back to a real scanned system.\n\n## Tools\n\n### `mcp__atlas__atlas_public_search`\nFull-text/semantic search over the graph. Key params: `q` (query), optional\n`kind` filter, `limit`. Prefer it to find seed/anchor nodes from need terms.\n\n### `mcp__atlas__atlas_public_record`\nFetch one node's full record by `id` (fields + edges). Use `expandNeighbors` to\npull immediate relations in one call. Prefer it to read detail once you have ids.\n\n### `mcp__atlas__atlas_public_neighbors`\nTraverse the graph from a node. Key params: `id`, `depth`, `edges` (edge-kind\nfilter), `kinds` (node-kind filter). Prefer it to expand a subsystem from anchors.\n\n### `mcp__atlas__atlas_public_kinds`\nList all node kinds in the graph. Use to scope a domain to relevant kinds.\n\n### `mcp__atlas__atlas_public_kind`\nDescribe a single node kind (schema/fields). Use before relying on a kind's shape.\n\n### `mcp__atlas__atlas_public_edge_kinds`\nList all edge kinds. Use to understand how nodes relate.\n\n### `mcp__atlas__atlas_public_edge_kind`\nDescribe a single edge kind. Use to interpret a specific relation type.\n\n### `mcp__atlas__atlas_public_clusters`\nList graph clusters (thematic groupings). Use to scope a domain to cluster(s).\n\n### `mcp__atlas__atlas_public_stats`\nGraph-level counts/metrics. Use for sizing and sanity checks.\n\n### `mcp__atlas__atlas_public_wiki_page`\nFetch a narrative wiki page for context. Use to capture human-readable nuance.\n\n## Query recipes\n\n- **Find by need** — `atlas_public_search(q=)` → take top ids.\n- **Expand a subsystem** — `atlas_public_neighbors(id, depth=2, kinds=[...])`.\n- **Inspect a node** — `atlas_public_record(id, expandNeighbors=true)`.\n- **Browse a cluster** — `atlas_public_clusters` → pick cluster → `search`/\n `neighbors` scoped to it.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/plugins/atlas-unified/skills/atlas-graph-query","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":"plugins/atlas-unified/skills/atlas-graph-query/SKILL.md","defaultBranch":"main"},"readme":"# atlas-graph-query\n\nA thin reference for the Atlas knowledge-graph MCP tool surface so any agent\n(including sub-agents) can query the graph without re-deriving conventions. The\nserver URL is wired natively by the `atlas` plugin and is overridable via\n`ATLAS_MCP_URL`. Never invent node ids — only use ids returned by these tools.\n\n> **Position: this is the SECONDARY / enrichment layer.** The `atlas` plugin is\n> scan-first — it inventories your REAL systems by scanning your actual sources\n> (Azure via read-only `az`, git repos, local directories) and process/data\n> mining them. The graph queries below are used ONLY to add best-practice /\n> comparison context to those already-discovered real systems. Do NOT use the\n> graph as the primary content, and never pad a real inventory with generic\n> catalog nodes. Tie every graph lookup back to a real scanned system.\n\n## Tools\n\n### `mcp__atlas__atlas_public_search`\nFull-text/semantic search over the graph. Key params: `q` (query), optional\n`kind` filter, `limit`. Prefer it to find seed/anchor nodes from need terms.\n\n### `mcp__atlas__atlas_public_record`\nFetch one node's full record by `id` (fields + edges). Use `expandNeighbors` to\npull immediate relations in one call. Prefer it to read detail once you have ids.\n\n### `mcp__atlas__atlas_public_neighbors`\nTraverse the graph from a node. Key params: `id`, `depth`, `edges` (edge-kind\nfilter), `kinds` (node-kind filter). Prefer it to expand a subsystem from anchors.\n\n### `mcp__atlas__atlas_public_kinds`\nList all node kinds in the graph. Use to scope a domain to relevant kinds.\n\n### `mcp__atlas__atlas_public_kind`\nDescribe a single node kind (schema/fields). Use before relying on a kind's shape.\n\n### `mcp__atlas__atlas_public_edge_kinds`\nList all edge kinds. Use to understand how nodes relate.\n\n### `mcp__atlas__atlas_public_edge_kind`\nDescribe a single edge kind. Use to interpret a specific relation type.\n\n### `mcp__atlas__atlas_public_clusters`\nList graph clusters (thematic groupings). Use to scope a domain to cluster(s).\n\n### `mcp__atlas__atlas_public_stats`\nGraph-level counts/metrics. Use for sizing and sanity checks.\n\n### `mcp__atlas__atlas_public_wiki_page`\nFetch a narrative wiki page for context. Use to capture human-readable nuance.\n\n## Query recipes\n\n- **Find by need** — `atlas_public_search(q=)` → take top ids.\n- **Expand a subsystem** — `atlas_public_neighbors(id, depth=2, kinds=[...])`.\n- **Inspect a node** — `atlas_public_record(id, expandNeighbors=true)`.\n- **Browse a cluster** — `atlas_public_clusters` → pick cluster → `search`/\n `neighbors` scoped to it.","createdAt":"2026-09-25T11:52:32.470Z","updatedAt":"2026-09-25T11:52:32.470Z"},{"id":"cmugwik0w028qqu06hog34w9v","slug":"a5c-ai-babysitter-atlas-2","name":"atlas","description":"Atlas turns your STATED NEED into a real systems atlas by SCANNING your actual sources (Azure via `az`, git repos, local dirs) and process/data mining them, THEN enriching against the Atlas knowledge graph. Use this skill when asked to inventory/map your real systems, scan your cloud + repos + directories, mine the real processes or data they contain, or collect their real constraints/gotchas. (atlas, scan my systems, inventory our azure account, map my repos, real systems atlas, process mining, data mining, collect nuances, system discovery)","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"atlas","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Atlas turns your STATED NEED into a real systems atlas by SCANNING your actual sources (Azure via `az`, git repos, local dirs) and process/data mining them, THEN enriching against the Atlas knowledge graph. Use this skill when asked to inventory/map your real systems, scan your cloud + repos + directories, mine the real processes or data they contain, or collect their real constraints/gotchas. (atlas, scan my systems, inventory our azure account, map my repos, real systems atlas, process mining, data mining, collect nuances, system discovery)","permissions":["shell"],"systemPrompt":"# atlas\n\nThis skill turns a stated need into a **real systems atlas** by SCANNING your\nactual sources — Azure subscriptions (via read-only `az`), git repos, and local\ndirectories — and process/data mining them, THEN enriching the result against the\nAtlas knowledge graph. It is the brain of the `atlas` plugin. The scan is\nPRIMARY; the graph is SECONDARY. For non-trivial runs it delegates orchestration\nto `babysitter:babysit` using an atlas-specific `.a5c` process; for simple\nlookups it queries the graph directly.\n\n## 1. Scan-first, graph-second\n\nThe output you want is an evidence-backed inventory of **your** systems — e.g.\n`azure-inventory.json` (every real resource id + RG from `az`),\n`workspace-inventory.json` (real repo/dir scan), `processes.json` (real mined\nCI/CD/IaC/.a5c processes), and a cross-linked `SYSTEMS-ATLAS.md`. Every item must\ncite its REAL source. Generic catalog nodes are NOT the deliverable.\n\n- **Primary — scan the user's real sources.** Use `Bash` to run READ-ONLY scans:\n `az` (account/group/resource list + per-service list/show) for Azure;\n `git` + filesystem (`Read`/`Glob`) for repos and directories. NEVER invent\n resource ids, regions, SKUs, or file paths — if you didn't observe it in real\n output, it does not go in the atlas. Only scan the sources named in the need\n (scoping, not a fallback).\n- **Secondary — the Atlas knowledge graph.** Atlas is a knowledge graph of\n agents, processes, data models, capabilities, workflows, and wiki pages reached\n through the `mcp__atlas__atlas_public_*` MCP tools (server URL overridable via\n `ATLAS_MCP_URL`). Use it ONLY to add best-practice / comparison context for the\n real systems you found — never as the primary content, never to pad the atlas\n with generic nodes. See the `atlas-graph-query` skill for the tool surface.\n\n## 2. When to use\n\n| Trigger phrase | Command |\n|----------------|---------|\n| scan/inventory my real systems (azure + repos + dirs), map them | `/atlas:discover` |\n| mine the real processes in my repos/cloud (CI/CD, IaC, .a5c, cron) | `/atlas:mine-processes` |\n| mine the real data stores/models in my cloud + repos | `/atlas:mine-data` |\n| collect the real constraints/gotchas of my scanned systems | `/atlas:collect-nuances` |\n\n## 3. The need → real atlas pipeline (core method)\n\n1. **Parse sources** — interpret the stated need into concrete SOURCES: Azure\n subscription(s), git repos, local directories, URLs, plus the output dir. If\n the sources are genuinely ambiguous, run a short interview\n (`AskUserQuestion`). Per repo policy, interview ONLY when truly unclear.\n2. **Scan cloud (primary)** — for each Azure source, run read-only `az` and write\n a real cloud inventory citing resource ids/RGs. Skip cleanly (record a reason)\n if no cloud source is in scope — only scan what's named.\n3. **Scan local (primary)** — for each repo/dir, scan the filesystem + git\n (structure, submodules, manifests, languages, services, IaC) and write a real\n inventory citing real paths.\n4. **Enrich (secondary)** — map the discovered real systems against the Atlas\n graph for comparison context. Clearly secondary; never the headline.\n5. **Synthesize** — assemble a real, cross-linked layered atlas (components /\n processes / data / integrations / nuances) where EVERY item cites its real\n source, like `SYSTEMS-ATLAS.md`, plus a machine mirror.\n6. **Converge (TDD)** — each phase asserts its own checkable outputs before\n proceeding (see the atlas processes), iterating until the assertions pass.\n\n## 4. How to delegate\n\nFor any non-trivial run, hand off to `babysitter:babysit` (via the Skill tool)\nnaming the matching atlas process:\n\n- `/atlas:discover` → `atlas-systems-discovery`\n- `/atlas:mine-processes` → `atlas-process-mining`\n- `/atlas:mine-data` → `atlas-data-mining`\n- `/atlas:collect-nuances` → `atlas-collect-nuances`\n\nDo not hand-roll orchestration when a process exists.\n\n## 5. Guardrails\n\n- No fallbacks (repo rule). Skipping an out-of-scope source class (e.g. no cloud\n named) is correct scoping and must be recorded with a reason — it is NOT a\n silent fallback to the public graph. If you find yourself writing a real\n fallback, stop and fix the root cause.\n- Scan-first: every system/item in the atlas MUST cite a REAL source (an `az`\n resource id / RG, or a file path). Never invent resource ids, regions, SKUs, or\n file paths. Never invent graph node ids either — only reference ids returned by\n the Atlas tools, and keep graph content strictly secondary.\n- Read-only scanning only: `az` read verbs, `git` status/remote/log, filesystem\n reads. Never run mutating cloud/git/fs commands and never read secret values.\n- Keep breakpoints sparse; use them only when the sources to scan are genuinely\n ambiguous.\n- The real scanning is done BY the agent via its `Bash` tool inside the agent\n task prompt. Do not emit `kind: 'shell'` subtasks unless the user explicitly\n asks for a shell-oriented workflow.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/plugins/atlas-unified/skills/atlas","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":"plugins/atlas-unified/skills/atlas/SKILL.md","defaultBranch":"main"},"readme":"# atlas\n\nThis skill turns a stated need into a **real systems atlas** by SCANNING your\nactual sources — Azure subscriptions (via read-only `az`), git repos, and local\ndirectories — and process/data mining them, THEN enriching the result against the\nAtlas knowledge graph. It is the brain of the `atlas` plugin. The scan is\nPRIMARY; the graph is SECONDARY. For non-trivial runs it delegates orchestration\nto `babysitter:babysit` using an atlas-specific `.a5c` process; for simple\nlookups it queries the graph directly.\n\n## 1. Scan-first, graph-second\n\nThe output you want is an evidence-backed inventory of **your** systems — e.g.\n`azure-inventory.json` (every real resource id + RG from `az`),\n`workspace-inventory.json` (real repo/dir scan), `processes.json` (real mined\nCI/CD/IaC/.a5c processes), and a cross-linked `SYSTEMS-ATLAS.md`. Every item must\ncite its REAL source. Generic catalog nodes are NOT the deliverable.\n\n- **Primary — scan the user's real sources.** Use `Bash` to run READ-ONLY scans:\n `az` (account/group/resource list + per-service list/show) for Azure;\n `git` + filesystem (`Read`/`Glob`) for repos and directories. NEVER invent\n resource ids, regions, SKUs, or file paths — if you didn't observe it in real\n output, it does not go in the atlas. Only scan the sources named in the need\n (scoping, not a fallback).\n- **Secondary — the Atlas knowledge graph.** Atlas is a knowledge graph of\n agents, processes, data models, capabilities, workflows, and wiki pages reached\n through the `mcp__atlas__atlas_public_*` MCP tools (server URL overridable via\n `ATLAS_MCP_URL`). Use it ONLY to add best-practice / comparison context for the\n real systems you found — never as the primary content, never to pad the atlas\n with generic nodes. See the `atlas-graph-query` skill for the tool surface.\n\n## 2. When to use\n\n| Trigger phrase | Command |\n|----------------|---------|\n| scan/inventory my real systems (azure + repos + dirs), map them | `/atlas:discover` |\n| mine the real processes in my repos/cloud (CI/CD, IaC, .a5c, cron) | `/atlas:mine-processes` |\n| mine the real data stores/models in my cloud + repos | `/atlas:mine-data` |\n| collect the real constraints/gotchas of my scanned systems | `/atlas:collect-nuances` |\n\n## 3. The need → real atlas pipeline (core method)\n\n1. **Parse sources** — interpret the stated need into concrete SOURCES: Azure\n subscription(s), git repos, local directories, URLs, plus the output dir. If\n the sources are genuinely ambiguous, run a short interview\n (`AskUserQuestion`). Per repo policy, interview ONLY when truly unclear.\n2. **Scan cloud (primary)** — for each Azure source, run read-only `az` and write\n a real cloud inventory citing resource ids/RGs. Skip cleanly (record a reason)\n if no cloud source is in scope — only scan what's named.\n3. **Scan local (primary)** — for each repo/dir, scan the filesystem + git\n (structure, submodules, manifests, languages, services, IaC) and write a real\n inventory citing real paths.\n4. **Enrich (secondary)** — map the discovered real systems against the Atlas\n graph for comparison context. Clearly secondary; never the headline.\n5. **Synthesize** — assemble a real, cross-linked layered atlas (components /\n processes / data / integrations / nuances) where EVERY item cites its real\n source, like `SYSTEMS-ATLAS.md`, plus a machine mirror.\n6. **Converge (TDD)** — each phase asserts its own checkable outputs before\n proceeding (see the atlas processes), iterating until the assertions pass.\n\n## 4. How to delegate\n\nFor any non-trivial run, hand off to `babysitter:babysit` (via the Skill tool)\nnaming the matching atlas process:\n\n- `/atlas:discover` → `atlas-systems-discovery`\n- `/atlas:mine-processes` → `atlas-process-mining`\n- `/atlas:mine-data` → `atlas-data-mining`\n- `/atlas:collect-nuances` → `atlas-collect-nuances`\n\nDo not hand-roll orchestration when a process exists.\n\n## 5. Guardrails\n\n- No fallbacks (repo rule). Skipping an out-of-scope source c","createdAt":"2026-09-25T11:52:32.480Z","updatedAt":"2026-09-25T11:52:32.480Z"},{"id":"cmugwik1b028tqu065akauozx","slug":"a5c-ai-babysitter-babysit-2","name":"babysit","description":"Execute via @babysitter. Use this skill when asked to babysit a task, do anything that is structured process-driven (even a loop) or whenever it is called explicitly. (babysit, babysitter, with a process, orchestrate, orchestrate a run, workflow, loop until, etc.)","authorId":"gh:a5c-ai","authorName":"a5c-ai","version":"0.1.0","category":"Prompt","securityLevel":"Sandbox","downloadsCount":0,"githubStars":1810,"pricePerCall":0,"manifest":{"name":"babysit","tools":[],"category":"Prompt","entrypoint":{"type":"prompt"},"description":"Execute via @babysitter. Use this skill when asked to babysit a task, do anything that is structured process-driven (even a loop) or whenever it is called explicitly. (babysit, babysitter, with a process, orchestrate, orchestrate a run, workflow, loop until, etc.)","permissions":["shell"],"systemPrompt":"# babysit\n\nFollow the commands below exactly. but apply judgement and creativity to get the job done. no matter how small or simple the task may seem, you must use the babysitter SDK and run lifecycle to execute it. This is non-negotiable. If you are asked to do something that seems like it could be done with a simple tool call, you must still use the babysitter SDK to create a run, define tasks, execute them, and complete the run. This is how you will learn and demonstrate mastery of the babysitter system. Always follow the full process, even for trivial tasks.\n\nSubagents that need a scratch checkout or working directory must create it under\n`/tmp//`, not under `.a5c/runs//work`. Before returning\ndeliverables, validate that no run-dir worktree was left behind, for example:\n\n```bash\nfind .a5c/runs -maxdepth 3 -name work -type d -print\n```\n\nThat command should print nothing. If it prints a non-empty work directory, move\nor remove only the scratch data you created before returning.\n\n## Dependencies\n\n### Babysitter SDK and CLI\n\nRead the SDK version from `versions.json` to ensure version compatibility:\n\n```bash\nSDK_VERSION=$(node -e \"try{console.log(JSON.parse(require('fs').readFileSync('${{{pluginRootEnvVar}}}/versions.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}\")\nnpm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION || npm i -g @a5c-ai/babysitter-sdk@latest\n\nif command -v babysitter >/dev/null 2>&1 && babysitter --version >/dev/null 2>&1; then\n CLI=\"babysitter\"\nelse\n CLI=\"npm exec --yes --package @a5c-ai/babysitter-sdk@$SDK_VERSION -- babysitter\"\nfi\n```\n\nIf the pinned version fails to install (e.g. not yet published), the fallback installs `latest`.\n\nIf a stale or broken global shim fails with `MODULE_NOT_FOUND`, repair it with `npm rm -g @a5c-ai/babysitter @a5c-ai/babysitter-sdk && npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION`, then re-run `babysitter --version`.\n\n### jq\n\nMake sure `jq` is installed and available in the path. If not, install it.\n\n## Instructions\n\nRun the following command to get full instructions:\n\n```bash\n$CLI instructions:babysit-skill --harness {{harness}} --interactive\n```\n\nFor non-interactive mode (running with `-p` flag or no AskUserQuestion tool):\n\n```bash\n$CLI instructions:babysit-skill --harness {{harness}} --no-interactive\n```\n\nFollow the instructions returned by the command above to orchestrate the run.","schemaVersion":1},"repoUrl":"https://github.com/a5c-ai/babysitter/tree/main/plugins/babysitter-unified/skills/babysit","tags":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows"],"stats":{"installVelocity7d":0,"retentionRate":0,"executions":0,"rating":null},"origin":"github","source":{"repo":"babysitter","audit":{"files":["package-lock.json","package.json"],"binaries":[],"findings":[{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Potential XSS in HTML session exports via Markdown URL sanitization bypass.","surface":"package-lock.json, package.json","evidence":"GHSA-7v5m-pr3q-6453 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Predictable temporary extension install paths allow local privilege escalation on shared Linux hosts.","surface":"package-lock.json, package.json","evidence":"GHSA-jfgx-wxx8-mp94 · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"high"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Pi loads project-local extensions without approval.","surface":"package-lock.json, package.json","evidence":"GHSA-mqxh-6gq7-558m · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"medium"},{"kind":"dependency","rule":"DP-01","message":"@earendil-works/pi-coding-agent@0.75.5 has a known vulnerability: Pi Agent: Race condition in Pi auth.json writes could expose stored credentials.","surface":"package-lock.json, package.json","evidence":"GHSA-r95r-rj6r-c39x · npm:@earendil-works/pi-coding-agent@0.75.5","severity":"low"},{"kind":"dependency","rule":"DP-05","message":"Dependencies younger than 30 days or with fewer than 100 weekly downloads.","surface":"package-lock.json, package.json","evidence":"@a5c-ai/compendium","severity":"low"}],"packages":9,"auditedAt":"2026-09-25T11:52:32.344Z","lockfiles":["package-lock.json"]},"forks":110,"owner":"a5c-ai","stars":1810,"topics":["agent-orchestration","agent-skills","agentic-ai","agentic-workflow","ai-agents","ai-automation","babysitter","claude-code","claude-code-skills","claude-code-workflows","claude-skills","claude-workflows","codex-plugin","codex-skills","codex-workflow","hermes-plugin","pi-extension","trustworthy-ai","vibe-coding"],"license":"MIT","fullName":"a5c-ai/babysitter","homepage":"https://a5c.ai","language":"JavaScript","pushedAt":"2026-09-16T19:59:50Z","avatarUrl":"https://avatars.githubusercontent.com/u/197881114?v=4","crawledAt":"2026-09-25T11:52:22.521Z","openIssues":434,"manifestFile":"SKILL.md","manifestPath":"plugins/babysitter-unified/skills/babysit/SKILL.md","defaultBranch":"main"},"readme":"# babysit\n\nFollow the commands below exactly. but apply judgement and creativity to get the job done. no matter how small or simple the task may seem, you must use the babysitter SDK and run lifecycle to execute it. This is non-negotiable. If you are asked to do something that seems like it could be done with a simple tool call, you must still use the babysitter SDK to create a run, define tasks, execute them, and complete the run. This is how you will learn and demonstrate mastery of the babysitter system. Always follow the full process, even for trivial tasks.\n\nSubagents that need a scratch checkout or working directory must create it under\n`/tmp//`, not under `.a5c/runs//work`. Before returning\ndeliverables, validate that no run-dir worktree was left behind, for example:\n\n```bash\nfind .a5c/runs -maxdepth 3 -name work -type d -print\n```\n\nThat command should print nothing. If it prints a non-empty work directory, move\nor remove only the scratch data you created before returning.\n\n## Dependencies\n\n### Babysitter SDK and CLI\n\nRead the SDK version from `versions.json` to ensure version compatibility:\n\n```bash\nSDK_VERSION=$(node -e \"try{console.log(JSON.parse(require('fs').readFileSync('${{{pluginRootEnvVar}}}/versions.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}\")\nnpm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION || npm i -g @a5c-ai/babysitter-sdk@latest\n\nif command -v babysitter >/dev/null 2>&1 && babysitter --version >/dev/null 2>&1; then\n CLI=\"babysitter\"\nelse\n CLI=\"npm exec --yes --package @a5c-ai/babysitter-sdk@$SDK_VERSION -- babysitter\"\nfi\n```\n\nIf the pinned version fails to install (e.g. not yet published), the fallback installs `latest`.\n\nIf a stale or broken global shim fails with `MODULE_NOT_FOUND`, repair it with `npm rm -g @a5c-ai/babysitter @a5c-ai/babysitter-sdk && npm i -g @a5c-ai/babysitter-sdk@$SDK_VERSION`, then re-run `babysitter --version`.\n\n### jq\n\nMake sure `jq` is installed and available in the path. If not, install it.\n\n## Instructions\n\nRun the following command to get full instructions:\n\n```bash\n$CLI instructions:babysit-skill --harness {{harness}} --interactive\n```\n\nFor non-interactive mode (running with `-p` flag or no AskUserQuestion tool):\n\n```bash\n$CLI instructions:babysit-skill --harness {{harness}} --no-interactive\n```\n\nFollow the instructions returned by the command above to orchestrate the run.","createdAt":"2026-09-25T11:52:32.495Z","updatedAt":"2026-09-25T11:52:32.495Z"}],"total":12,"limit":24,"offset":0}