@a5c-ai/babysitter-github 0.1.1-staging.0825aadb

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (44) hide show
  1. package/.github/plugin.json +25 -0
  2. package/AGENTS.md +41 -0
  3. package/README.md +545 -0
  4. package/bin/cli.js +104 -0
  5. package/bin/install-shared.js +450 -0
  6. package/bin/install.js +81 -0
  7. package/bin/uninstall.js +76 -0
  8. package/commands/assimilate.md +37 -0
  9. package/commands/call.md +7 -0
  10. package/commands/cleanup.md +20 -0
  11. package/commands/contrib.md +33 -0
  12. package/commands/doctor.md +426 -0
  13. package/commands/forever.md +7 -0
  14. package/commands/help.md +244 -0
  15. package/commands/observe.md +12 -0
  16. package/commands/plan.md +7 -0
  17. package/commands/plugins.md +255 -0
  18. package/commands/project-install.md +17 -0
  19. package/commands/resume.md +8 -0
  20. package/commands/retrospect.md +55 -0
  21. package/commands/user-install.md +17 -0
  22. package/commands/yolo.md +7 -0
  23. package/hooks/session-end.ps1 +68 -0
  24. package/hooks/session-end.sh +65 -0
  25. package/hooks/session-start.ps1 +110 -0
  26. package/hooks/session-start.sh +100 -0
  27. package/hooks/user-prompt-submitted.ps1 +51 -0
  28. package/hooks/user-prompt-submitted.sh +41 -0
  29. package/hooks.json +29 -0
  30. package/package.json +50 -0
  31. package/plugin.json +25 -0
  32. package/scripts/sync-command-surfaces.js +62 -0
  33. package/scripts/team-install.js +86 -0
  34. package/skills/assimilate/SKILL.md +38 -0
  35. package/skills/babysit/SKILL.md +77 -0
  36. package/skills/call/SKILL.md +8 -0
  37. package/skills/doctor/SKILL.md +427 -0
  38. package/skills/help/SKILL.md +245 -0
  39. package/skills/observe/SKILL.md +13 -0
  40. package/skills/plan/SKILL.md +8 -0
  41. package/skills/resume/SKILL.md +9 -0
  42. package/skills/retrospect/SKILL.md +56 -0
  43. package/skills/user-install/SKILL.md +18 -0
  44. package/versions.json +3 -0
@@ -0,0 +1,245 @@
1
+ ---
2
+ name: help
3
+ description: help and documentation for babysitter command usage, processes, skills, agents, and methodologies. use this command to understand how to use babysitter effectively.
4
+ ---
5
+
6
+ # help
7
+
8
+ ## if no arguments provided:
9
+
10
+ show this message:
11
+
12
+ ```
13
+ Welcome to the Babysitter Help Center! Here you can find documentation and guidance on how to use Babysitter effectively.
14
+
15
+ Documentation: Explore our comprehensive documentation to understand Babysitter's features, processes, skills, agents, and methodologies. Read the Docs: https://github.com/a5c-ai/babysitter
16
+
17
+ Or ask specific questions about commands, processes, skills, agents, methodologies, domains, specialities to get targeted help.
18
+
19
+ Just type /babysitter:help followed by your question or the topic you want to learn more about.
20
+
21
+
22
+ PRIMARY COMMANDS
23
+ ================
24
+
25
+ /babysitter:call [input]
26
+ Start a babysitter-orchestrated run. Babysitter analyzes your request, interviews you
27
+ to gather requirements, selects or creates the best process definition (from 50+
28
+ domain-specific processes covering science, business, engineering, and more), then
29
+ executes it step by step with breakpoints where you can steer direction.
30
+
31
+ How it works: The babysitter skill reads your input, explores the process library to
32
+ find matching processes, interviews you to refine scope, creates an SDK run with
33
+ run:create, and orchestrates iterations with run:iterate -- dispatching tasks,
34
+ handling breakpoints, and posting results until the run completes or you pause it.
35
+
36
+ Example: /babysitter:call migrate our Express.js REST API to Fastify, keeping all
37
+ existing routes and middleware behavior identical, with integration tests proving
38
+ parity
39
+
40
+
41
+ /babysitter:resume [run id or name]
42
+ Resume a paused or interrupted babysitter run. If you don't specify a run, babysitter
43
+ discovers all runs under .a5c/runs/, shows their status (created, waiting, completed,
44
+ failed), and suggests which incomplete run to pick up based on its process, pending
45
+ effects, and last activity.
46
+
47
+ How it works: Reads run metadata and journal, rebuilds state cache if stale, identifies
48
+ pending effects (breakpoints awaiting approval, tasks needing results), and continues
49
+ orchestration from exactly where it left off -- no work is repeated thanks to the
50
+ replay engine.
51
+
52
+ Example: /babysitter:resume
53
+ (discovers runs and offers: "Run abc123 is waiting on a breakpoint in the 'review
54
+ test results' phase of your API migration -- resume this one?")
55
+
56
+
57
+ /babysitter:yolo [input]
58
+ Start a babysitter run in fully autonomous mode. Identical to /call but all breakpoints
59
+ are auto-approved and no user interaction is requested. The babysitter makes every
60
+ decision on its own until the run completes or hits a critical failure it can't recover
61
+ from. Best for well-understood tasks where you trust the process.
62
+
63
+ How it works: Same orchestration as /call, but the process context is configured to
64
+ skip breakpoint effects -- instead of pausing for human approval, each breakpoint
65
+ resolves immediately with an auto-approve result.
66
+
67
+ Example: /babysitter:yolo add comprehensive unit tests for all functions in
68
+ src/utils/ using vitest with >90% branch coverage
69
+
70
+
71
+ /babysitter:plan [input]
72
+ Generate a detailed execution plan without running anything. Babysitter goes through
73
+ the full interview and process selection flow, designs the process definition with
74
+ all tasks, breakpoints, and dependencies, but stops before creating the actual SDK run.
75
+ You get a complete plan you can review, modify, or execute later with /call.
76
+
77
+ How it works: Runs the babysitter skill's planning phase only -- analyzes input,
78
+ matches to domain processes, interviews for requirements, then outputs the process
79
+ definition file and a human-readable execution plan showing each phase, task, and
80
+ decision point.
81
+
82
+ Example: /babysitter:plan redesign our database schema to support multi-tenancy,
83
+ migrate existing data, and update all queries -- I want to review the plan before
84
+ we touch anything
85
+
86
+
87
+ /babysitter:forever [input]
88
+ Start a babysitter run that loops indefinitely with sleep intervals. Designed for
89
+ ongoing operational tasks: monitoring, periodic maintenance, continuous improvement,
90
+ or recurring workflows. The process uses an infinite loop with ctx.sleepUntil() to
91
+ pause between iterations.
92
+
93
+ How it works: Creates a process definition with a while(true) loop. Each cycle performs
94
+ the task (e.g., check metrics, process tickets, run audits), then calls ctx.sleepUntil()
95
+ to pause for a configured interval. The run stays in "waiting" state during sleep and
96
+ resumes automatically when the sleep expires on the next orchestration iteration.
97
+
98
+ Example: /babysitter:forever every 4 hours, check our GitHub issues labeled "bug",
99
+ attempt to reproduce and fix any that look straightforward, and submit PRs for the fixes
100
+
101
+
102
+ SECONDARY COMMANDS
103
+ ==================
104
+
105
+ /babysitter:doctor [issue]
106
+ Run a comprehensive 10-point health check on a babysitter run. Inspects journal
107
+ integrity (checksum verification, sequence gaps, timestamp ordering), state cache
108
+ consistency, stuck/errored effects, stale locks, session state, log files, disk usage,
109
+ process validation, and hook execution health. Produces a structured diagnostic report
110
+ with PASS/WARN/FAIL status per check and specific fix commands.
111
+
112
+ If no run ID is provided, automatically targets the most recent run. Can also diagnose
113
+ environment-wide issues like missing CLI, unregistered hooks, or plugin problems.
114
+
115
+ Example: /babysitter:doctor
116
+ (checks the latest run: "CRITICAL -- Check 5 Lock Status: FAIL -- stale lock detected,
117
+ process 12847 is no longer running. Fix: rm .a5c/runs/abc123/run.lock")
118
+
119
+
120
+ /babysitter:assimilate [target]
121
+ Convert an external methodology, AI coding harness, or specification into native
122
+ babysitter process definitions. Takes a GitHub repo URL, harness name, or spec file
123
+ and produces a complete process package with skills/ and agents/ directories.
124
+
125
+ Two workflows available:
126
+ - Methodology assimilation: clones the repo, learns its procedures and commands,
127
+ converts manual flows into babysitter processes with refactored skills and agents
128
+ - Harness integration: wires babysitter's SDK into a specific AI coding tool
129
+ (codex, opencode, gemini-cli, antigravity, etc.) so it can orchestrate runs
130
+
131
+ Example: /babysitter:assimilate https://github.com/some-org/their-deployment-playbook
132
+ (clones the repo, analyzes their deployment procedures, and generates babysitter
133
+ processes that replicate the same workflow with proper task definitions and breakpoints)
134
+
135
+
136
+ /babysitter:user-install
137
+ First-time onboarding for new babysitter users. Installs dependencies, runs an
138
+ interactive interview about your development specialties, preferred tools, coding
139
+ style, and how much autonomy you want babysitter to have. Builds a user profile
140
+ stored at ~/.a5c/user-profile.json that personalizes future runs.
141
+
142
+ Uses the cradle/user-install process which covers: dependency verification, user
143
+ interview (expertise areas, preferred languages, IDE, terminal setup), profile
144
+ generation, tool configuration, and optional global plugin installation.
145
+
146
+ Example: /babysitter:user-install
147
+ (walks you through: "What's your primary programming language? What frameworks do
148
+ you use most? Do you prefer babysitter to auto-approve routine tasks or always ask?")
149
+
150
+
151
+ /babysitter:project-install
152
+ Onboard a new or existing project for babysitter orchestration. Researches the
153
+ codebase (reads package.json, scans directory structure, identifies frameworks and
154
+ patterns), interviews you about project goals and workflows, generates a project
155
+ profile at .a5c/project-profile.json, and optionally sets up CI/CD integration.
156
+
157
+ Uses the cradle/project-install process which covers: codebase analysis, project
158
+ interview, profile creation, recommended plugin installation, hook configuration,
159
+ and optional CI pipeline setup.
160
+
161
+ Example: /babysitter:project-install
162
+ (scans your repo: "I see this is a Next.js 16 app with Tailwind, using vitest for
163
+ tests and PostgreSQL. What are your main development goals for this project?")
164
+
165
+
166
+ /babysitter:retrospect [run id or name]
167
+ Analyze a completed run to extract lessons and improve future runs. Reviews what
168
+ happened (journal events, task results, timing, errors), evaluates the process that
169
+ was followed, and suggests concrete improvements to process definitions, skills,
170
+ and agents. Interactive -- multiple breakpoints let you steer the analysis and
171
+ decide which improvements to implement.
172
+
173
+ Covers: run result analysis, process effectiveness review, improvement suggestions,
174
+ implementation of changes, and routing to /contrib if improvements belong in the
175
+ shared process library.
176
+
177
+ Example: /babysitter:retrospect
178
+ (analyzes the last run: "The API migration run completed but the 'verify parity'
179
+ phase took 8 iterations because test assertions were too brittle. Suggestion: add
180
+ a fuzzy comparison step before strict assertion. Implement this fix?")
181
+
182
+
183
+ /babysitter:plugins [action]
184
+ Manage babysitter plugins: list installed plugins, browse marketplaces, install,
185
+ update, configure, uninstall, or create new plugins. Plugins are version-managed
186
+ instruction packages (not executable code) that guide the agent through install,
187
+ configure, and uninstall steps via markdown files.
188
+
189
+ Without arguments: shows installed plugins (name, version, marketplace, dates) and
190
+ available marketplaces. With arguments: routes to the specific action.
191
+
192
+ Key actions:
193
+ - install <name> --global|--project: fetch install.md from marketplace and execute
194
+ - configure <name> --global|--project: fetch configure.md and walk through options
195
+ - update <name> --global|--project: resolve migration chain via BFS and apply steps
196
+ - uninstall <name> --global|--project: fetch uninstall.md and execute removal
197
+ - create: scaffold a new plugin package with the meta/plugin-creation process
198
+
199
+ Example: /babysitter:plugins install sound-hooks --project
200
+ (fetches sound-hooks from marketplace, reads install.md, walks you through player
201
+ detection, sound selection, hook configuration, and registers in plugin-registry.json)
202
+
203
+
204
+ /babysitter:contrib [feedback]
205
+ Submit feedback or contribute to the babysitter project. Routes to the appropriate
206
+ workflow based on what you want to do:
207
+
208
+ Issue-based (opens GitHub issue in a5c-ai/babysitter):
209
+ - Bug report: describe a bug in the SDK, CLI, or process library
210
+ - Feature request: propose a new feature or enhancement
211
+ - Documentation question: flag undocumented behavior or missing docs
212
+
213
+ PR-based (forks repo, creates branch, submits PR):
214
+ - Bugfix: you already have a fix ready
215
+ - Feature implementation: you've built a new feature
216
+ - Library contribution: new or improved process/skill/agent for the library
217
+ - Harness integration: CI/CD or IDE integration
218
+
219
+ Without arguments: shows all contribution types and helps you pick the right one.
220
+ Breakpoints are placed before all GitHub actions (fork, star, PR, issue) so you
221
+ can review before anything is submitted.
222
+
223
+ Example: /babysitter:contrib bug report: plugin:update-registry fails when the
224
+ marketplace hasn't been cloned yet, even though the registry update doesn't need
225
+ marketplace access
226
+
227
+
228
+ /babysitter:observe
229
+ Launch the babysitter observer dashboard -- a real-time web UI that monitors active
230
+ and past runs. Displays task progress, journal events, orchestration state, and
231
+ effect status in your browser. Useful when running /yolo or /forever to watch
232
+ progress without interrupting the run.
233
+
234
+ How it works: Runs npx @yoavmayer/babysitter-observer-dashboard@latest which watches
235
+ the .a5c/runs/ directory (or a parent directory containing multiple projects) and
236
+ serves a live dashboard. The process is blocking -- it runs until you stop it.
237
+
238
+ Example: /babysitter:observe
239
+ (opens browser showing all runs with live-updating task
240
+ status, journal event stream, and effect resolution timeline)
241
+ ```
242
+
243
+ ## if arguments provided:
244
+
245
+ if the argument is "command [command name]", "process [process name]", "skill [skill name]", "agent [agent name]", or "methodology [methodology name]", then show the detailed documentation for that specific command, process, skill, agent, or methodology after reading the relevant files.
@@ -0,0 +1,13 @@
1
+ ---
2
+ name: observe
3
+ description: Launch the babysitter observer dashboard. Installs and runs the real-time observer UI that watches babysitter runs, displaying task progress, journal events, and orchestration state in your browser.
4
+ ---
5
+
6
+ # observe
7
+
8
+ Run the babysitter observer dashboard:
9
+
10
+ 1. Determine the watch directory — this is usually the project's container directory (the parent of the project dir), or the current working directory if not specified.
11
+ 2. Launch the dashboard: `npx -y @a5c-ai/babysitter-observer-dashboard@latest --watch-dir <dir>`
12
+ 3. This is a blocking process — it will keep running until stopped.
13
+ 4. Open the browser at the URL printed by the dashboard.
@@ -0,0 +1,8 @@
1
+ ---
2
+ name: plan
3
+ description: Plan a babysitter run. use this command to plan a complex workflow, without actually running it.
4
+ ---
5
+
6
+ # plan
7
+
8
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). focus on creating the best process possible, but without creating and running the actual run.
@@ -0,0 +1,9 @@
1
+ ---
2
+ name: resume
3
+ description: Resume orchestrating of a babysitter run. use this command to resume babysitting a complex workflow.
4
+ ---
5
+
6
+ # resume
7
+
8
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). to resume a run.
9
+ if no run was given, discover the runs and suggest which incomplete run to resume based on the run's status, inputs, process , etc.
@@ -0,0 +1,56 @@
1
+ ---
2
+ name: retrospect
3
+ description: Analysis for a run and its results, process, suggestions for process improvements, process optimizations, fixes, etc. for the next runs.
4
+ ---
5
+
6
+ # retrospect
7
+
8
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
9
+
10
+ create and run a retrospect process:
11
+
12
+ ### Run Selection
13
+
14
+ - `--all` or "all runs": list all completed/failed runs and analyze collectively
15
+ - Multiple run IDs: analyze each specified run
16
+ - Single run ID or no ID: existing behavior (latest run)
17
+ - In interactive mode with no run specified: ask user whether to analyze latest, select specific runs, or all runs
18
+
19
+ ### Cross-Run Analysis (multi-run mode)
20
+
21
+ When analyzing multiple runs, the retrospect process should additionally cover:
22
+ - Common failure patterns across runs
23
+ - Velocity trends (tasks/time across runs)
24
+ - Process evolution (how processes changed)
25
+ - Repeated breakpoint patterns
26
+ - Aggregate quality metrics
27
+
28
+ implementations notes (for the process):
29
+ - The process should analyze the run, the process that was followed, and provide suggestions for improvements, optimizations, and fixes.
30
+ - The process should such have many breakpoints where the user can steer the process, provide feedback, and make decisions about how to proceed with the retrospect.
31
+ - The process should be designed to be flexible and adaptable to different types of runs, projects, and goals, and should be able to provide insights and suggestions that are relevant and actionable for the user. (modification to the process, skills, etc.)
32
+ - The process should be designed to be iterative, allowing the user to go through multiple rounds of analysis and improvement, and should be able to track the changes and improvements made over time.
33
+ - The process should cover:
34
+ - Analysis of the run and its results, including what went well, what didn't go well, and what could be improved.
35
+ - Analysis of the process that was followed, including what steps were taken, what tools were used, and how effective they were.
36
+ - Suggestions for improvements, optimizations, and fixes for both the run and the process.
37
+ - Implementing the improvements, optimizations, and fixes, and tracking the changes made over time.
38
+ ### Cleanup Suggestion
39
+
40
+ After retrospect analysis, suggest running `/babysitter:cleanup` to clean up old run data and reclaim disk space.
41
+
42
+ - Ending by explicitly prompting the user to contribute back -- even just reporting an issue is valuable, they don't need to implement the fix themselves. After analysis, display a clear call-to-action:
43
+
44
+ "You've identified [specific insight/improvement]. This could help other babysitter users too. Run `/babysitter:contrib` to share it upstream -- you can either report it as an issue or submit a PR with the fix."
45
+
46
+ Route to the specific contrib workflow based on what the user wants to do:
47
+
48
+ **Just reporting (no code changes needed):**
49
+ - Found a bug or weakness in a process -> `/babysitter:contrib bug report: [description of what went wrong]`
50
+ - Found missing or confusing documentation -> `/babysitter:contrib documentation question: [what was unclear]`
51
+ - Have an idea for improvement but don't want to implement it -> `/babysitter:contrib feature request: [description]`
52
+
53
+ **Contributing code changes:**
54
+ - Process/skill/agent improvements -> `/babysitter:contrib library contribution: [description]`
55
+ - Bug fixes in SDK or CLI -> `/babysitter:contrib bugfix: [description]`
56
+ - Plugin instruction improvements -> `/babysitter:contrib library contribution: improved [plugin-name] [install|configure|uninstall] instructions`
@@ -0,0 +1,18 @@
1
+ ---
2
+ name: user-install
3
+ description: Set up babysitter for yourself. Guides you through onboarding — installs dependencies, interviews you about your specialties and preferences, builds your user profile, and configures the best tools for your workflow.
4
+ ---
5
+
6
+ # user-install
7
+
8
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
9
+
10
+ Before using the process library, resolve the active library root through the SDK CLI. If no binding exists yet, initialize the shared global SDK binding with:
11
+
12
+ ```bash
13
+ babysitter process-library:active --json
14
+ ```
15
+
16
+ Then use the `cradle/user-install` process from the active process library.
17
+
18
+ When the run completes, end with a friendly message that includes a polite and humorous ask to star the repo on GitHub: https://github.com/a5c-ai/babysitter
package/versions.json ADDED
@@ -0,0 +1,3 @@
1
+ {
2
+ "sdkVersion": "0.0.184-staging.0825aadb"
3
+ }