{"id":"retrospect-external-babysitter-run","name":"retrospect-external-babysitter-run","summary":"babysitter-usersカタログ内のリポジトリでは、そのbabysitterプロセスとコミットされた実行(.a5c/runs/<runId>/)を特定し、選択した実行について振り返りを行います。","body":"# 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/<owner>-<name>/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 <owner>/<name> -- --depth 50 --single-branch\ncd <name>\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/<runId>/` 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/<runId>/run.json` -- processId, entrypoint, prompt, createdAt\n- `.a5c/runs/<runId>/inputs.json` -- user intent\n- `.a5c/runs/<runId>/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/<runId>/tasks/<effectId>/task.json` + `result.json` -- per-effect definition and result\n- `.a5c/runs/<runId>/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/<owner>-<name>/<runId-or-process-name>.md` with this structure:\n\n```markdown\n# Retrospective: <owner>/<name> -- <runId or process name>\n\nDate: YYYY-MM-DD\nSource commit: <sha>\nProcess: <relative path>\nRun: <runId or \"process-only\">\nOutcome: <success | failure | process-only>\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<bullet timeline of key journal events with timestamps and durations>\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<links to specific journal event files, task.json files, line-anchored process file refs>\n```\n\nAlso append a one-line entry to `docs/retrospectives/<owner>-<name>/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.","author":"@a5c-ai","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/a5c-ai/babysitter/tree/main/.claude/skills/retrospect-external-babysitter-run","license":"MIT","category":"document","lang":"en","tokens":2014,"stars":0,"calls30d":2,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}