@a5c-ai/babysitter-gemini 4.0.153

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.
@@ -0,0 +1,12 @@
1
+ ---
2
+ 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.
3
+ argument-hint: [--watch-dir <dir>]
4
+ allowed-tools: Read, Grep, Write, Task, Bash
5
+ ---
6
+
7
+ Run the babysitter observer dashboard:
8
+
9
+ 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.
10
+ 2. Launch the dashboard: `npx -y @a5c-ai/babysitter-observer-dashboard@latest --watch-dir <dir>`
11
+ 3. This is a blocking process — it will keep running until stopped.
12
+ 4. Open the browser at the URL printed by the dashboard.
@@ -0,0 +1,7 @@
1
+ ---
2
+ description: Plan a babysitter run. use this command to plan a complex workflow, without actually running it.
3
+ argument-hint: Specific instructions for the run.
4
+ allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
5
+ ---
6
+
7
+ 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,255 @@
1
+ ---
2
+ description: manage babysitter plugins. use this command to see the list of installed babysitter plugins, their status, and manage them (install, update, uninstall, list from marketplace, add marketplace, configure plugin, create new plugin, etc).
3
+ argument-hint: Specific instructions.
4
+ ---
5
+
6
+ This command installs and manages plugins for babysitter. A plugin is a version-managed package of contextual instructions (for install, uninstall, configure, and update/migrate between versions), not a conventional software plugin.
7
+
8
+ if the command is run without arguments, it lists all installed plugins with their name, version, marketplace, installation date, and last update date. as well as marketplaces added to the system. and instructions on how to install new plugins from marketplaces.
9
+ if there are no marketplaces added, add the default marketplace:
10
+ ```bash
11
+ babysitter plugin:add-marketplace --marketplace-url https://github.com/a5c-ai/babysitter --marketplace-path plugins/a5c/marketplace/marketplace.json --global --json
12
+ ```
13
+
14
+ Plugins can be installed at two scopes:
15
+ - **global** (`--global`): stored under `~/.a5c/`, available for all projects
16
+ - **project** (`--project`): stored under `<projectDir>/.a5c/`, project-specific
17
+
18
+ ## Marketplace Management
19
+
20
+ Marketplaces are git repositories containing a `marketplace.json` manifest and plugin package directories. The SDK clones them locally with `--depth 1`.
21
+
22
+ **Storage locations:**
23
+ - Global: `~/.a5c/marketplaces/<name>/`
24
+ - Project: `<projectDir>/.a5c/marketplaces/<name>/`
25
+
26
+ The marketplace name is derived from the git URL's last path segment (stripping `.git` suffix and trailing slashes).
27
+
28
+ ### Adding a marketplace
29
+
30
+ ```bash
31
+ babysitter plugin:add-marketplace --marketplace-url <url> [--marketplace-path <relative-path>] [--marketplace-branch <ref>] [--force] --global|--project [--json]
32
+ ```
33
+
34
+ Clones the marketplace repository to the local marketplaces directory. Use `--marketplace-path` to specify the relative path to `marketplace.json` within the repo (for monorepos or repos where the manifest is not at the root). Use `--marketplace-branch` to clone a specific branch, tag, or ref (defaults to the repo's default branch). Use `--force` to replace an existing marketplace clone (deletes and re-clones).
35
+
36
+ ### Updating a marketplace
37
+
38
+ ```bash
39
+ babysitter plugin:update-marketplace --marketplace-name <name> [--marketplace-branch <ref>] --global|--project [--json]
40
+ ```
41
+
42
+ Runs `git pull` on the local marketplace clone to fetch latest changes. Use `--marketplace-branch` to switch to a different branch before pulling (works even with shallow clones).
43
+
44
+ ### Listing plugins in a marketplace
45
+
46
+ ```bash
47
+ babysitter plugin:list-plugins --marketplace-name <name> --global|--project [--json]
48
+ ```
49
+
50
+ Reads the `marketplace.json` manifest and returns all available plugins sorted alphabetically by name. Each entry includes: name, description, latestVersion, versions array, packagePath, tags, and author.
51
+
52
+ ## Plugin Installation
53
+
54
+ **Note:** For `plugin:install`, `plugin:update`, `plugin:configure`, and `plugin:list-plugins`, the `--marketplace-name` flag is auto-detected when only one marketplace is cloned for the given scope. You can omit it if there's only one marketplace.
55
+
56
+ ### Flow
57
+
58
+ 1. Update the marketplace: `babysitter plugin:update-marketplace --marketplace-name <name> --global|--project`
59
+ 2. Check current state: `babysitter plugin:list-installed --global|--project` to see installed plugins and versions
60
+ 3. Install the plugin:
61
+
62
+ ```bash
63
+ babysitter plugin:install --plugin-name <name> [--marketplace-name <mp>] --global|--project [--json]
64
+ ```
65
+
66
+ This command resolves the plugin package path from the marketplace manifest, reads `install.md` from the plugin package directory, and returns the installation instructions. If an `install-process.js` file exists, the instructions may reference it as an automated install process.
67
+
68
+ 4. The agent performs the installation steps as defined in `install.md`
69
+ 5. The agent updates the registry:
70
+
71
+ ```bash
72
+ babysitter plugin:update-registry --plugin-name <name> --plugin-version <ver> --marketplace-name <mp> --global|--project [--json]
73
+ ```
74
+
75
+ ## Plugin Update (with migrations)
76
+
77
+ ```bash
78
+ babysitter plugin:update --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
79
+ ```
80
+
81
+ This command:
82
+ 1. Reads the currently installed version from the registry
83
+ 2. Resolves the latest version from the marketplace manifest
84
+ 3. Looks in the plugin package's `migrations/` directory for migration files
85
+ 4. Uses BFS over the migration graph to find the shortest path from the installed version to the target version
86
+ 5. Returns the ordered migration instructions (content of each migration file in sequence)
87
+
88
+ **Migration filename format:** `<fromVersion>_to_<toVersion>.<ext>` where:
89
+ - Versions may contain alphanumerics, dots, dashes (e.g. `1.0.0`, `2.0.0-beta`)
90
+ - Extensions: `.md` for markdown instructions, `.js` for executable process files
91
+ - Examples: `1.0.0_to_1.1.0.md`, `2.0.0-beta_to_2.0.0.js`
92
+
93
+ After performing the migration steps, update the registry:
94
+
95
+ ```bash
96
+ babysitter plugin:update-registry --plugin-name <name> --plugin-version <new-ver> --marketplace-name <mp> --global|--project [--json]
97
+ ```
98
+
99
+ ## Plugin Uninstallation
100
+
101
+ ```bash
102
+ babysitter plugin:uninstall --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
103
+ ```
104
+
105
+ Reads `uninstall.md` from the plugin package directory and returns the uninstall instructions. After performing the uninstall steps, remove from registry:
106
+
107
+ ```bash
108
+ babysitter plugin:remove-from-registry --plugin-name <name> --global|--project [--json]
109
+ ```
110
+
111
+ ## Plugin Configuration
112
+
113
+ ```bash
114
+ babysitter plugin:configure --plugin-name <name> --marketplace-name <mp> --global|--project [--json]
115
+ ```
116
+
117
+ Reads `configure.md` from the plugin package directory and returns configuration instructions.
118
+
119
+ ## Registry Management
120
+
121
+ The plugin registry (`plugin-registry.json`) tracks installed plugins with schema version `2026.01.plugin-registry-v1`. Writes use atomic file operations (temp + rename) for crash safety.
122
+
123
+ **Storage locations:**
124
+ - Global: `~/.a5c/plugin-registry.json`
125
+ - Project: `<projectDir>/.a5c/plugin-registry.json`
126
+
127
+ ### List installed plugins
128
+
129
+ ```bash
130
+ babysitter plugin:list-installed --global|--project [--json]
131
+ ```
132
+
133
+ Returns all installed plugins sorted alphabetically. In `--json` mode, returns an array of registry entries. In human mode, displays a formatted table with name, version, marketplace, and timestamps.
134
+
135
+ ### Remove from registry
136
+
137
+ ```bash
138
+ babysitter plugin:remove-from-registry --plugin-name <name> --global|--project [--json]
139
+ ```
140
+
141
+ Removes a plugin entry from the registry. Returns error if the plugin is not present.
142
+
143
+ ## Plugin Creation
144
+
145
+ To create a new plugin package from scratch, use the `meta/plugin-creation` babysitter process. This process guides you through requirements analysis, structure design, instruction authoring, optional process file generation, validation, and marketplace integration.
146
+
147
+ ### Using the plugin creation process
148
+
149
+ Orchestrate a babysitter run with the plugin creation process:
150
+
151
+ ```bash
152
+ # Create inputs file
153
+ cat > /tmp/plugin-inputs.json << 'EOF'
154
+ {
155
+ "pluginName": "my-plugin",
156
+ "description": "What the plugin does — be specific about install/configure/uninstall behavior",
157
+ "scope": "project",
158
+ "outputDir": "./plugins",
159
+ "components": {
160
+ "installProcess": false,
161
+ "configureProcess": false,
162
+ "uninstallProcess": false,
163
+ "migrations": false,
164
+ "processFiles": false
165
+ },
166
+ "marketplace": {
167
+ "name": "my-marketplace",
168
+ "author": "my-org",
169
+ "tags": ["category1", "category2"]
170
+ }
171
+ }
172
+ EOF
173
+
174
+ # Create and run
175
+ babysitter run:create \
176
+ --process-id meta/plugin-creation \
177
+ --entry library/specializations/meta/plugin-creation.js#process \
178
+ --inputs /tmp/plugin-inputs.json \
179
+ --prompt "Create a new babysitter plugin package" \
180
+ --json
181
+ ```
182
+
183
+ ### What the process generates
184
+
185
+ The process creates a complete plugin package directory:
186
+
187
+ | File | Description |
188
+ |------|-------------|
189
+ | `install.md` | Agent-readable installation instructions with numbered steps |
190
+ | `uninstall.md` | Reversal instructions for clean removal |
191
+ | `configure.md` | Configuration options table and adjustment instructions |
192
+ | `install-process.js` | *(optional)* Automated babysitter process for complex install steps |
193
+ | `configure-process.js` | *(optional)* Automated configuration process |
194
+ | `process/main.js` | *(optional)* Main process the plugin contributes |
195
+ | `marketplace-entry.json` | Ready-to-use marketplace.json entry for publishing |
196
+
197
+ ### Process phases
198
+
199
+ 1. **Requirements Analysis** — Analyzes plugin purpose, prerequisites, config options, file structure
200
+ 2. **Structure Design** — Plans directory layout and file inventory (with review breakpoint)
201
+ 3. **Instruction Authoring** — Writes install.md, uninstall.md, configure.md
202
+ 4. **Process Files** — Creates optional babysitter process files (install-process.js, configure-process.js, process/main.js)
203
+ 5. **Validation** — Verifies package completeness, instruction quality, path correctness
204
+ 6. **Marketplace Integration** — Generates marketplace.json entry for publishing
205
+
206
+ ### Quick creation (without orchestration)
207
+
208
+ For simple plugins that only need instruction files, you can create the package manually following the structure below and the [Plugin Author Guide](docs/plugins/plugin-author-guide.md).
209
+
210
+ ## Plugin Package Structure
211
+
212
+ ```
213
+ my-plugin/
214
+ package.json # Optional (name field used as plugin ID, falls back to directory name)
215
+ install.md # Markdown instructions for installation
216
+ uninstall.md # Markdown instructions for removal
217
+ configure.md # Markdown instructions for configuration
218
+ install-process.js # Optional automated install process
219
+ uninstall-process.js # Optional automated uninstall process
220
+ configure-process.js # Optional automated configure process
221
+ migrations/ # Version migration files
222
+ 1.0.0_to_1.1.0.md
223
+ 1.1.0_to_2.0.0.js
224
+ process/ # Process definition files (collected recursively)
225
+ main.js
226
+ ```
227
+
228
+ ## All CLI Commands Summary
229
+
230
+ All commands accept `--json` for machine-readable output and `--global|--project`.
231
+
232
+ | Command | Required Flags | Description |
233
+ |---------|---------------|-------------|
234
+ | `plugin:add-marketplace` | `--marketplace-url`, `--global\|--project` [`--marketplace-path`, `--marketplace-branch`, `--force`] | Clone a marketplace repository |
235
+ | `plugin:update-marketplace` | `--marketplace-name`, `--global\|--project` [`--marketplace-branch`] | Pull latest marketplace changes (optionally switch branch) |
236
+ | `plugin:list-plugins` | `--marketplace-name`, `--global\|--project` | List available plugins in a marketplace |
237
+ | `plugin:install` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Get install instructions for a plugin |
238
+ | `plugin:uninstall` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Get uninstall instructions for a plugin |
239
+ | `plugin:update` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Resolve migration chain and get update instructions |
240
+ | `plugin:configure` | `--plugin-name`, `--marketplace-name`, `--global\|--project` | Get configuration instructions for a plugin |
241
+ | `plugin:list-installed` | `--global\|--project` | List all installed plugins |
242
+ | `plugin:update-registry` | `--plugin-name`, `--plugin-version`, `--marketplace-name`, `--global\|--project` | Register or update a plugin entry |
243
+ | `plugin:remove-from-registry` | `--plugin-name`, `--global\|--project` | Remove a plugin entry from the registry |
244
+
245
+ ## After Plugin Work: Contribute Back
246
+
247
+ After working with plugins, prompt the user to share improvements or report issues:
248
+
249
+ - **Improved a plugin's install/configure/uninstall instructions**: `/babysitter:contrib library contribution: improved [plugin-name] [install|configure|uninstall] instructions`
250
+ - **Created a new plugin**: `/babysitter:contrib library contribution: new plugin [plugin-name] -- [description]`
251
+ - **Found a bug in a plugin or the plugin system**: `/babysitter:contrib bug report: [description, e.g. "plugin:update-registry fails when marketplace hasn't been cloned"]`
252
+ - **Plugin install/configure instructions were confusing or wrong**: `/babysitter:contrib bug report: [plugin-name] install instructions [description of what was wrong]`
253
+ - **Have an idea for a new plugin**: `/babysitter:contrib feature request: plugin idea -- [description]`
254
+
255
+ Even reporting that a plugin's instructions were unclear helps improve it for the next user.
@@ -0,0 +1,17 @@
1
+ ---
2
+ description: Set up a project for babysitting. Guides you through onboarding a new or existing project — researches the codebase, interviews you about goals and workflows, builds the project profile, installs the best tools, and optionally configures CI/CD integration.
3
+ argument-hint: Specific instructions for the run.
4
+ allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
5
+ ---
6
+
7
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
8
+
9
+ 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:
10
+
11
+ ```bash
12
+ babysitter process-library:active --json
13
+ ```
14
+
15
+ Then use the `cradle/project-install` process from the active process library.
16
+
17
+ 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
@@ -0,0 +1,8 @@
1
+ ---
2
+ description: Resume orchestrating of a babysitter run. use this command to resume babysitting a complex workflow.
3
+ argument-hint: Specific run to resume
4
+ allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
5
+ ---
6
+
7
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). to resume a run.
8
+ 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,55 @@
1
+ ---
2
+ description: Analysis for a run and its results, process, suggestions for process improvements, process optimizations, fixes, etc. for the next runs.
3
+ argument-hint: "[run-id...] [--all] Specific run IDs, --all for all runs, or defaults to latest"
4
+ allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
5
+ ---
6
+
7
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
8
+
9
+ create and run a retrospect process:
10
+
11
+ ### Run Selection
12
+
13
+ - `--all` or "all runs": list all completed/failed runs and analyze collectively
14
+ - Multiple run IDs: analyze each specified run
15
+ - Single run ID or no ID: existing behavior (latest run)
16
+ - In interactive mode with no run specified: ask user whether to analyze latest, select specific runs, or all runs
17
+
18
+ ### Cross-Run Analysis (multi-run mode)
19
+
20
+ When analyzing multiple runs, the retrospect process should additionally cover:
21
+ - Common failure patterns across runs
22
+ - Velocity trends (tasks/time across runs)
23
+ - Process evolution (how processes changed)
24
+ - Repeated breakpoint patterns
25
+ - Aggregate quality metrics
26
+
27
+ implementations notes (for the process):
28
+ - The process should analyze the run, the process that was followed, and provide suggestions for improvements, optimizations, and fixes.
29
+ - 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.
30
+ - 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.)
31
+ - 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.
32
+ - The process should cover:
33
+ - Analysis of the run and its results, including what went well, what didn't go well, and what could be improved.
34
+ - Analysis of the process that was followed, including what steps were taken, what tools were used, and how effective they were.
35
+ - Suggestions for improvements, optimizations, and fixes for both the run and the process.
36
+ - Implementing the improvements, optimizations, and fixes, and tracking the changes made over time.
37
+ ### Cleanup Suggestion
38
+
39
+ After retrospect analysis, suggest running `/babysitter:cleanup` to clean up old run data and reclaim disk space.
40
+
41
+ - 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:
42
+
43
+ "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."
44
+
45
+ Route to the specific contrib workflow based on what the user wants to do:
46
+
47
+ **Just reporting (no code changes needed):**
48
+ - Found a bug or weakness in a process -> `/babysitter:contrib bug report: [description of what went wrong]`
49
+ - Found missing or confusing documentation -> `/babysitter:contrib documentation question: [what was unclear]`
50
+ - Have an idea for improvement but don't want to implement it -> `/babysitter:contrib feature request: [description]`
51
+
52
+ **Contributing code changes:**
53
+ - Process/skill/agent improvements -> `/babysitter:contrib library contribution: [description]`
54
+ - Bug fixes in SDK or CLI -> `/babysitter:contrib bugfix: [description]`
55
+ - Plugin instruction improvements -> `/babysitter:contrib library contribution: improved [plugin-name] [install|configure|uninstall] instructions`
@@ -0,0 +1,17 @@
1
+ ---
2
+ 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.
3
+ argument-hint: Specific instructions for the run.
4
+ allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
5
+ ---
6
+
7
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md).
8
+
9
+ 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:
10
+
11
+ ```bash
12
+ babysitter process-library:active --json
13
+ ```
14
+
15
+ Then use the `cradle/user-install` process from the active process library.
16
+
17
+ 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
@@ -0,0 +1,7 @@
1
+ ---
2
+ description: Orchestrate a babysitter run. use this command to start babysitting a complex workflow in a non-interactive mode, without any user interaction or breakpoints in the run.
3
+ argument-hint: Specific instructions for the run.
4
+ allowed-tools: Read, Grep, Write, Task, Bash, Edit, Grep, Glob, WebFetch, WebSearch, Search, AskUserQuestion, TodoWrite, TodoRead, Skill, BashOutput, KillShell, MultiEdit, LS
5
+ ---
6
+
7
+ Invoke the babysitter:babysit skill (using the Skill tool) and follow its instructions (SKILL.md). but without any user interaction or breakpoints in the run.
@@ -0,0 +1,18 @@
1
+ {
2
+ "name": "babysitter",
3
+ "version": "4.0.153",
4
+ "description": "Orchestrate complex, multi-step workflows with event-sourced state management, hook-based extensibility, and human-in-the-loop approval — powered by the Babysitter SDK",
5
+ "contextFileName": "GEMINI.md",
6
+ "settings": [
7
+ {
8
+ "name": "babysitterRunsDir",
9
+ "description": "Directory for babysitter run storage (defaults to .a5c/runs)",
10
+ "envVar": "BABYSITTER_RUNS_DIR"
11
+ },
12
+ {
13
+ "name": "babysitterStateDir",
14
+ "description": "State directory for harness adapters (defaults to .a5c)",
15
+ "envVar": "BABYSITTER_STATE_DIR"
16
+ }
17
+ ]
18
+ }
@@ -0,0 +1,101 @@
1
+ #!/bin/bash
2
+ # Babysitter AfterAgent Hook for Gemini CLI
3
+ #
4
+ # This is the CORE orchestration loop driver for Gemini CLI.
5
+ # Fires after every agent turn. Checks if a babysitter run is bound to this
6
+ # session; if so, blocks the session exit to continue iterating until the run
7
+ # completes or the completion proof is detected.
8
+ #
9
+ # Protocol:
10
+ # Input: JSON via stdin (contains session_id, prompt_response, etc.)
11
+ # Output: JSON via stdout
12
+ # - {} or {"decision":"allow"} -> allow session to exit normally
13
+ # - {"decision":"block","reason":"...","systemMessage":"..."} -> continue loop
14
+ # Stderr: debug/log output only
15
+ # Exit 0: success (stdout parsed as JSON)
16
+ # Exit 2: block immediately (stderr used as rejection reason)
17
+ #
18
+ # Completion detection:
19
+ # The agent must output <promise>COMPLETION_PROOF</promise> in its response.
20
+ # The SDK verifies the proof matches the run's completionProof field.
21
+
22
+ set -uo pipefail
23
+
24
+ EXTENSION_PATH="${GEMINI_EXTENSION_PATH:-$(cd "$(dirname "$0")/.." && pwd)}"
25
+
26
+ LOG_DIR="${BABYSITTER_LOG_DIR:-${EXTENSION_PATH}/.a5c/logs}"
27
+ LOG_FILE="$LOG_DIR/babysitter-after-agent-hook.log"
28
+ mkdir -p "$LOG_DIR" 2>/dev/null
29
+
30
+ # Structured logging helper — writes to both local log and via CLI
31
+ blog() {
32
+ local msg="$1"
33
+ local ts
34
+ ts="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
35
+ echo "[INFO] $ts $msg" >> "$LOG_FILE" 2>/dev/null
36
+ if command -v babysitter &>/dev/null; then
37
+ babysitter log --type hook --label "hook:after-agent" --message "$msg" --source shell-hook 2>/dev/null || true
38
+ fi
39
+ }
40
+
41
+ blog "AfterAgent hook invoked"
42
+
43
+ # ---------------------------------------------------------------------------
44
+ # Resolve babysitter CLI
45
+ # ---------------------------------------------------------------------------
46
+
47
+ if ! command -v babysitter &>/dev/null; then
48
+ # Try user-local prefix (set by session-start hook)
49
+ if [ -x "$HOME/.local/bin/babysitter" ]; then
50
+ export PATH="$HOME/.local/bin:$PATH"
51
+ else
52
+ SDK_VERSION=$(node -e "try{console.log(JSON.parse(require('fs').readFileSync('${EXTENSION_PATH}/versions.json','utf8')).sdkVersion||'latest')}catch{console.log('latest')}" 2>/dev/null || echo "latest")
53
+ if [ -n "$SDK_VERSION" ]; then
54
+ babysitter() { npx -y "@a5c-ai/babysitter-sdk@${SDK_VERSION}" "$@"; }
55
+ export -f babysitter
56
+ else
57
+ # No CLI available at all — allow exit silently
58
+ echo '{}'
59
+ exit 0
60
+ fi
61
+ fi
62
+ fi
63
+
64
+ blog "babysitter CLI resolved"
65
+
66
+ # ---------------------------------------------------------------------------
67
+ # Capture stdin (prevents keeping event loop alive)
68
+ # ---------------------------------------------------------------------------
69
+
70
+ INPUT_FILE=$(mktemp 2>/dev/null || echo "/tmp/bsitter-after-agent-$$.json")
71
+ cat > "$INPUT_FILE"
72
+
73
+ INPUT_SIZE=$(wc -c < "$INPUT_FILE" 2>/dev/null || echo "?")
74
+ blog "Hook input received ($INPUT_SIZE bytes)"
75
+
76
+ # ---------------------------------------------------------------------------
77
+ # Delegate to SDK CLI (hook:run --hook-type stop --harness gemini-cli)
78
+ # The gemini-cli adapter reads AfterAgent input format and outputs the
79
+ # appropriate block/approve decision.
80
+ # ---------------------------------------------------------------------------
81
+
82
+ RESULT=$(babysitter hook:run \
83
+ --hook-type stop \
84
+ --harness gemini-cli \
85
+ --plugin-root "$EXTENSION_PATH" \
86
+ --state-dir ".a5c/state" \
87
+ --json < "$INPUT_FILE" 2>>"$LOG_DIR/babysitter-after-agent-hook-stderr.log")
88
+ EXIT_CODE=$?
89
+
90
+ blog "CLI exit code=$EXIT_CODE result_len=$(echo -n "$RESULT" | wc -c)"
91
+
92
+ rm -f "$INPUT_FILE" 2>/dev/null
93
+
94
+ # Output result (must be valid JSON on stdout only)
95
+ if [ -n "$RESULT" ]; then
96
+ printf '%s\n' "$RESULT"
97
+ else
98
+ printf '{}\n'
99
+ fi
100
+
101
+ exit $EXIT_CODE
@@ -0,0 +1,32 @@
1
+ {
2
+ "description": "Babysitter plugin hooks for Gemini CLI — session initialization and AfterAgent continuation loop",
3
+ "hooks": {
4
+ "SessionStart": [
5
+ {
6
+ "hooks": [
7
+ {
8
+ "name": "babysitter-session-start",
9
+ "type": "command",
10
+ "command": "bash \"${extensionPath}/hooks/session-start.sh\"",
11
+ "timeout": 30000,
12
+ "description": "Initializes a Babysitter session state file so the AfterAgent hook can track orchestration progress"
13
+ }
14
+ ]
15
+ }
16
+ ],
17
+ "AfterAgent": [
18
+ {
19
+ "matcher": "*",
20
+ "hooks": [
21
+ {
22
+ "name": "babysitter-after-agent",
23
+ "type": "command",
24
+ "command": "bash \"${extensionPath}/hooks/after-agent.sh\"",
25
+ "timeout": 30000,
26
+ "description": "Babysitter orchestration loop driver — blocks session exit to continue iterating until the run is complete"
27
+ }
28
+ ]
29
+ }
30
+ ]
31
+ }
32
+ }