codebyplan 1.13.51 → 1.13.52

package/dist/cli.js

@@ -39,7 +39,7 @@ var VERSION, PACKAGE_NAME;
 var init_version = __esm({
   "src/lib/version.ts"() {
     "use strict";
-    VERSION = "1.13.51";
+    VERSION = "1.13.52";
     PACKAGE_NAME = "codebyplan";
   }
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codebyplan",
-  "version": "1.13.51",
+  "version": "1.13.52",
   "description": "CLI for CodeByPlan — AI-powered development planning and tracking",
   "type": "module",
   "bin": {

package/templates/skills/cbp-build-cc-skill/SKILL.md

@@ -157,5 +157,6 @@ Checks: name matches directory, frontmatter parses, no invalid fields, arg-hint
 - Rendered `SKILL.md` content enters the conversation once when invoked and stays until compaction — write standing instructions, not one-time steps
 - Preloaded subagent skills cannot have `disable-model-invocation: true`
 - `context: fork` is only meaningful when the skill body contains an actionable task; otherwise the subagent receives guidelines with no prompt
+- `context: fork` ALSO disqualifies fan-out / spawn-then-route / inline-by-design / consumed-inline skills — they run in the main context for a reason; see [reference/fork-eligibility.md](reference/fork-eligibility.md) for the eligibility test + the CBP classification of which skills may fork and which must stay inline
 - Descriptions front-load key use case: `description` + `when_to_use` cap at 1,536 chars in the skill listing
 - `paths:` scoping applies when Claude reads files matching the globs, not on every tool use

package/templates/skills/cbp-build-cc-skill/reference/fork-eligibility.md

@@ -0,0 +1,78 @@
+# `context: fork` Eligibility — when to fork a skill, and when not to
+
+`context: fork` runs the **entire SKILL.md body in a forked subagent** — it inherits the
+parent conversation and, per the runtime, **runs in the background by default**. It is
+isolation for a *whole skill*, not a way to delegate one sub-step. A forked body therefore
+cannot drive the main pipeline: it can't `AskUserQuestion`, can't auto-trigger another
+skill, and can't run an inline-fallback that the orchestrator depends on.
+
+So forking only helps a narrow shape of skill. The canonical eligible example is
+[examples/fork-skill.md](../examples/fork-skill.md): a single self-contained analytical task
+that reads, reasons, and returns a summary — nothing else.
+
+## Eligibility test
+
+A skill is **fork-eligible** only when ALL hold:
+
+1. Its whole body is **one** self-contained analytical/generative task (read → reason → return).
+2. It is **non-interactive** — no `AskUserQuestion`, no user decision gates.
+3. It does **not route** — no auto-trigger of another skill, no close-out directive that must
+   fire in the main context.
+4. It does **not fan out** — it does not spawn multiple subagents and coordinate them.
+5. It has **no inline-fallback** contract the orchestrator relies on.
+
+Fail any one → the skill stays **inline** (main context). Inline skills still get clean
+context isolation the right way: by delegating their heavy step to a dedicated **agent**
+(e.g. `cbp-task-check`, `cbp-improve-round`, `cbp-round-executor`). The agent is the
+isolation boundary; the skill stays in the main thread to orchestrate, route, and interact.
+
+## When NOT to use `context: fork` (the disqualifying patterns)
+
+| Pattern | Why it can't fork | Example skills |
+|---------|-------------------|----------------|
+| **fan-out** | spawns multiple agents in parallel and coordinates them | `cbp-round-execute`, `cbp-checkpoint-check`, `cbp-map-architecture`, `cbp-refresh-arch-map` |
+| **spawn-then-route** | spawns one agent, then `AskUserQuestion` / auto-triggers the next skill / runs inline-fallback | `cbp-task-check`, `cbp-standalone-task-check`, `cbp-round-start`, `cbp-round-end`, `cbp-checkpoint-plan` |
+| **inline-by-design** | interactive Q&A or stepwise writes that must stay in the main context | `cbp-task-create`, `cbp-task-complete`, `cbp-round-update`, `cbp-merge-main` |
+| **consumed-inline** | invoked *by* an agent (e.g. round-executor) and applies fixes synchronously into that context | `cbp-frontend-design`, `cbp-frontend-ui`, `cbp-frontend-ux` |
+| **doc-ref-only** | mentions subagents/fork only as documentation; runs inline authoring | the `cbp-build-cc-*` authoring skills, `cbp-supabase-migrate` |
+
+## CHK-220 audit — classification matrix
+
+Every skill whose `SKILL.md` touches the subagent/fork boundary — by spawning a subagent, by
+being invoked inline by an agent, or by documenting the feature — was classified against the
+eligibility test. **Result: 0 of 25 are fork-eligible** — none were migrated, because every
+one either already isolates heavy work in a dedicated agent (the correct boundary) or depends
+on inline orchestration/interaction that a background fork would break.
+
+| Skill | Pattern | Fork-eligible |
+|-------|---------|:---:|
+| cbp-round-execute | fan-out | no |
+| cbp-checkpoint-check | fan-out | no |
+| cbp-map-architecture | fan-out | no |
+| cbp-refresh-arch-map | fan-out | no |
+| cbp-round-start | spawn-then-route | no |
+| cbp-round-end | spawn-then-route | no |
+| cbp-task-check | spawn-then-route | no |
+| cbp-standalone-task-check | spawn-then-route | no |
+| cbp-checkpoint-plan | spawn-then-route | no |
+| cbp-round-update | inline-by-design | no |
+| cbp-task-create | inline-by-design | no |
+| cbp-standalone-task-create | inline-by-design | no |
+| cbp-task-complete | inline-by-design | no |
+| cbp-standalone-task-complete | inline-by-design | no |
+| cbp-merge-main | inline-by-design | no |
+| cbp-task-testing | inline-by-design | no |
+| cbp-standalone-task-testing | inline-by-design | no |
+| cbp-frontend-design | consumed-inline | no |
+| cbp-frontend-ui | consumed-inline | no |
+| cbp-frontend-ux | consumed-inline | no |
+| cbp-supabase-migrate | doc-ref-only | no |
+| cbp-build-cc-skill | doc-ref-only | no |
+| cbp-build-cc-agent | doc-ref-only | no |
+| cbp-build-cc-settings | doc-ref-only | no |
+| cbp-build-cc-mode | doc-ref-only | no |
+
+If a **new** skill is authored that passes the eligibility test above, fork it: add
+`context: fork` + `agent: <Explore|Plan|general-purpose|custom>` (use `--fork` in
+`/cbp-build-cc-skill`). Do not retrofit fork onto any skill in the table — their inline
+shape is load-bearing.

package/templates/skills/cbp-build-cc-skill/reference/frontmatter-fields.md

@@ -20,6 +20,10 @@ Source: official Claude Code skills spec. All fields are optional; `description`
 | `paths` | Globs that auto-load the skill when matching files are in play |
 | `shell` | `bash` (default) or `powershell` for `!`-commands |
 
+> `context: fork` / `agent` are right for only a narrow shape of skill — a single
+> non-interactive analytical body. See [fork-eligibility.md](fork-eligibility.md) for the
+> eligibility test and the CBP classification of which skills may fork (and which must stay inline).
+
 ## Character budget
 
 Combined `description` + `when_to_use` truncates at **1,536 characters** in the skill listing. Front-load the key use case.