@bendyline/gilde 0.1.8 → 0.1.10

package/data/craftbook-templates/of/office-hours/manifest.json

@@ -6,8 +6,7 @@
   "description": "YC-style office-hours diagnostic. Surfaces forcing questions, challenges premises, lands on a sharper problem statement before any code is written.",
   "tags": [
     "plan",
-    "scoping",
-    "gstack"
+    "scoping"
   ],
   "maintainer": {
     "name": "Gezel"

package/data/craftbook-templates/of/office-hours/versions/1.0.0/craftbook.json

@@ -1,7 +1,7 @@
 {
   "id": "office-hours",
   "name": "Office Hours",
-  "description": "An office-hours-style scoping procedure. The user shows up with an idea\nor a problem; the procedure forces them through *listen → challenge →\nreframe → lock scope* before any solutioning happens.\n\nThis is the gstack `/office-hours` skill ported as a craftbook. It's\ndeliberately a pure-prose procedure — no scripts, no hooks. The model\nfollows the step prose, elicits answers via `ask_user_question` (or\nprose, see below), and writes the locked scope to a task note that\ndownstream craftbooks (`/plan-eng-review`, `/review`, `/ship`) read.\n\nThe principle is the YC office-hours pattern: most ideas die not because\nthey're bad but because the problem statement was too loose to bite\ninto. A 20-minute conversation that lands on the *right* problem is\nworth more than a week building the wrong product.\n\nThe recipe never assumes the user is right. If their framing is shaky,\nthe **Challenge** step names that explicitly. The **Reframe** step\nforces a single pick — office hours doesn't end with three startups.\n\n## Tool surface assumptions\n\nEach step prefers `ask_user_question` for structured prompts and\n`write_task_note` for the lock-scope artifact, but each prompt also\nships a **prose / `writeFile` fallback** so the craftbook completes on\nany gezel whose role-tool-filter omits the question/notes tools.\nThat mismatch — Office Hours being assigned to a gezel without the\nquestion tool — was the 2026-06 failure mode: an 8B Gemma running\nunder the developer-style role surface had no `ask_user_question`,\nspun up workarounds (memory searches, repeated `invoke_craftbook`\ncalls, throwaway tasks), and got aborted by the\nsame-arguments-5-times detector before producing anything useful.\nThe explicit *\"if it's in your function schema, otherwise prose\"*\nbranches keep small/medium models on the rails when the surface\nisn't what the prompt assumes.\n\nThe kickoff step also **explicitly overrides** the common gezel\ninstruction to \"search memory before asking the user.\" Pre-loading\ncontext is the right default for follow-up turns and for non-listening\ntasks; for office-hours kickoff it defeats the procedure (the whole\npoint is to hear the user's framing FRESH). The override is named in\nthe prompt so the model doesn't have to resolve the conflict by\nguessing.\n\n## Notes for small / medium models (≤12B)\n\n- Steps are kept under ~200 words and frontload the action (\"**One\n  job this step:** …\") so a small context window doesn't lose focus\n  on long preambles.\n- The \"do NOT\" list is explicit and specific (don't search memory,\n  don't list tasks, don't `invoke_craftbook`) because small models\n  tend to wander to those tools when their headline tool is missing.\n- Examples are concrete (Pac-Man-style: \"A personal chief-of-staff\n  (productivity tool); A solution to nobody-reads-RSS (consumer\n  media); A publishing tool for journalists (B2B SaaS)\") rather than\n  abstract — small models reason better from a worked example than\n  from a rule.\n- Each step is self-contained: re-reading the previous step's notes\n  is allowed but not required to complete this one. The lock-scope\n  step is the only one that depends on prior-step output; the rest\n  read what's directly above in the chat.\n",
+  "description": "An office-hours-style scoping procedure. The user shows up with an idea\nor a problem; the procedure forces them through *listen → challenge →\nreframe → lock scope* before any solutioning happens.\n\nThis is deliberately a pure-prose procedure — no scripts, no hooks. The model\nfollows the step prose, elicits answers via `ask_user_question` (or\nprose, see below), and writes the locked scope to a task note that\ndownstream craftbooks (`/plan-eng-review`, `/review`, `/ship`) read.\n\nThe principle is the YC office-hours pattern: most ideas die not because\nthey're bad but because the problem statement was too loose to bite\ninto. A 20-minute conversation that lands on the *right* problem is\nworth more than a week building the wrong product.\n\nThe recipe never assumes the user is right. If their framing is shaky,\nthe **Challenge** step names that explicitly. The **Reframe** step\nforces a single pick — office hours doesn't end with three startups.\n\n## Tool surface assumptions\n\nEach step prefers `ask_user_question` for structured prompts and\n`write_task_note` for the lock-scope artifact, but each prompt also\nships a **prose / `writeFile` fallback** so the craftbook completes on\nany gezel whose role-tool-filter omits the question/notes tools.\nThat mismatch — Office Hours being assigned to a gezel without the\nquestion tool — was the 2026-06 failure mode: an 8B Gemma running\nunder the developer-style role surface had no `ask_user_question`,\nspun up workarounds (memory searches, repeated `invoke_craftbook`\ncalls, throwaway tasks), and got aborted by the\nsame-arguments-5-times detector before producing anything useful.\nThe explicit *\"if it's in your function schema, otherwise prose\"*\nbranches keep small/medium models on the rails when the surface\nisn't what the prompt assumes.\n\nThe kickoff step also **explicitly overrides** the common gezel\ninstruction to \"search memory before asking the user.\" Pre-loading\ncontext is the right default for follow-up turns and for non-listening\ntasks; for office-hours kickoff it defeats the procedure (the whole\npoint is to hear the user's framing FRESH). The override is named in\nthe prompt so the model doesn't have to resolve the conflict by\nguessing.\n\n## Notes for small / medium models (≤12B)\n\n- Steps are kept under ~200 words and frontload the action (\"**One\n  job this step:** …\") so a small context window doesn't lose focus\n  on long preambles.\n- The \"do NOT\" list is explicit and specific (don't search memory,\n  don't list tasks, don't `invoke_craftbook`) because small models\n  tend to wander to those tools when their headline tool is missing.\n- Examples are concrete (Pac-Man-style: \"A personal chief-of-staff\n  (productivity tool); A solution to nobody-reads-RSS (consumer\n  media); A publishing tool for journalists (B2B SaaS)\") rather than\n  abstract — small models reason better from a worked example than\n  from a rule.\n- Each step is self-contained: re-reading the previous step's notes\n  is allowed but not required to complete this one. The lock-scope\n  step is the only one that depends on prior-step output; the rest\n  read what's directly above in the chat.\n",
   "entryStepId": "kickoff",
   "triggers": [
     "office hours",

package/data/craftbook-templates/of/office-hours/versions/1.1.0/craftbook.json

@@ -1,7 +1,7 @@
 {
   "id": "office-hours",
   "name": "Office Hours",
-  "description": "An office-hours-style scoping procedure. The user shows up with an idea\nor a problem; the procedure forces them through *listen → challenge →\nreframe → lock scope* before any solutioning happens.\n\nThis is the gstack `/office-hours` skill ported as a craftbook. It's\ndeliberately a pure-prose procedure — no scripts, no hooks. The model\nfollows the step prose, elicits answers via `ask_user_question` (or\nprose, see below), and writes the locked scope to a task note that\ndownstream craftbooks (`/plan-eng-review`, `/review`, `/ship`) read.\n\nThe principle is the YC office-hours pattern: most ideas die not because\nthey're bad but because the problem statement was too loose to bite\ninto. A 20-minute conversation that lands on the *right* problem is\nworth more than a week building the wrong product.\n\nThe recipe never assumes the user is right. If their framing is shaky,\nthe **Challenge** step names that explicitly. The **Reframe** step\nforces a single pick — office hours doesn't end with three startups.\n\n## Tool surface assumptions\n\nEach step prefers `ask_user_question` for structured prompts and\n`write_task_note` for the lock-scope artifact, but each prompt also\nships a **prose / `write_file` fallback** so the craftbook completes on\nany gezel whose role-tool-filter omits the question/notes tools.\nThat mismatch — Office Hours being assigned to a gezel without the\nquestion tool — was the 2026-06 failure mode: an 8B Gemma running\nunder the developer-style role surface had no `ask_user_question`,\nspun up workarounds (memory searches, repeated `invoke_craftbook`\ncalls, throwaway tasks), and got aborted by the\nsame-arguments-5-times detector before producing anything useful.\nThe explicit *\"if it's in your function schema, otherwise prose\"*\nbranches keep small/medium models on the rails when the surface\nisn't what the prompt assumes.\n\nThe kickoff step also **explicitly overrides** the common gezel\ninstruction to \"search memory before asking the user.\" Pre-loading\ncontext is the right default for follow-up turns and for non-listening\ntasks; for office-hours kickoff it defeats the procedure (the whole\npoint is to hear the user's framing FRESH). The override is named in\nthe prompt so the model doesn't have to resolve the conflict by\nguessing.\n\n## Notes for small / medium models (≤12B)\n\n- Steps are kept under ~200 words and frontload the action (\"**One\n  job this step:** …\") so a small context window doesn't lose focus\n  on long preambles.\n- The \"do NOT\" list is explicit and specific (don't search memory,\n  don't list tasks, don't `invoke_craftbook`) because small models\n  tend to wander to those tools when their headline tool is missing.\n- Examples are concrete (Pac-Man-style: \"A personal chief-of-staff\n  (productivity tool); A solution to nobody-reads-RSS (consumer\n  media); A publishing tool for journalists (B2B SaaS)\") rather than\n  abstract — small models reason better from a worked example than\n  from a rule.\n- Each step is self-contained: re-reading the previous step's notes\n  is allowed but not required to complete this one. The lock-scope\n  step is the only one that depends on prior-step output; the rest\n  read what's directly above in the chat.\n",
+  "description": "An office-hours-style scoping procedure. The user shows up with an idea\nor a problem; the procedure forces them through *listen → challenge →\nreframe → lock scope* before any solutioning happens.\n\nThis is deliberately a pure-prose procedure — no scripts, no hooks. The model\nfollows the step prose, elicits answers via `ask_user_question` (or\nprose, see below), and writes the locked scope to a task note that\ndownstream craftbooks (`/plan-eng-review`, `/review`, `/ship`) read.\n\nThe principle is the YC office-hours pattern: most ideas die not because\nthey're bad but because the problem statement was too loose to bite\ninto. A 20-minute conversation that lands on the *right* problem is\nworth more than a week building the wrong product.\n\nThe recipe never assumes the user is right. If their framing is shaky,\nthe **Challenge** step names that explicitly. The **Reframe** step\nforces a single pick — office hours doesn't end with three startups.\n\n## Tool surface assumptions\n\nEach step prefers `ask_user_question` for structured prompts and\n`write_task_note` for the lock-scope artifact, but each prompt also\nships a **prose / `write_file` fallback** so the craftbook completes on\nany gezel whose role-tool-filter omits the question/notes tools.\nThat mismatch — Office Hours being assigned to a gezel without the\nquestion tool — was the 2026-06 failure mode: an 8B Gemma running\nunder the developer-style role surface had no `ask_user_question`,\nspun up workarounds (memory searches, repeated `invoke_craftbook`\ncalls, throwaway tasks), and got aborted by the\nsame-arguments-5-times detector before producing anything useful.\nThe explicit *\"if it's in your function schema, otherwise prose\"*\nbranches keep small/medium models on the rails when the surface\nisn't what the prompt assumes.\n\nThe kickoff step also **explicitly overrides** the common gezel\ninstruction to \"search memory before asking the user.\" Pre-loading\ncontext is the right default for follow-up turns and for non-listening\ntasks; for office-hours kickoff it defeats the procedure (the whole\npoint is to hear the user's framing FRESH). The override is named in\nthe prompt so the model doesn't have to resolve the conflict by\nguessing.\n\n## Notes for small / medium models (≤12B)\n\n- Steps are kept under ~200 words and frontload the action (\"**One\n  job this step:** …\") so a small context window doesn't lose focus\n  on long preambles.\n- The \"do NOT\" list is explicit and specific (don't search memory,\n  don't list tasks, don't `invoke_craftbook`) because small models\n  tend to wander to those tools when their headline tool is missing.\n- Examples are concrete (Pac-Man-style: \"A personal chief-of-staff\n  (productivity tool); A solution to nobody-reads-RSS (consumer\n  media); A publishing tool for journalists (B2B SaaS)\") rather than\n  abstract — small models reason better from a worked example than\n  from a rule.\n- Each step is self-contained: re-reading the previous step's notes\n  is allowed but not required to complete this one. The lock-scope\n  step is the only one that depends on prior-step output; the rest\n  read what's directly above in the chat.\n",
   "entryStepId": "kickoff",
   "triggers": [
     "office hours",

package/data/craftbook-templates/pu/pull-request-review/manifest.json

@@ -6,7 +6,6 @@
   "description": "Staff-engineer-style PR review. Loads PR context, walks a per-file diff, applies a safety/quality checklist, and posts a structured summary. Requires a GitHub-connected project on a feature branch.",
   "tags": [
     "review",
-    "gstack",
     "recommended"
   ],
   "maintainer": {

package/data/craftbook-templates/pu/pull-request-review/versions/1.0.0/craftbook.json

@@ -1,7 +1,7 @@
 {
   "id": "pull-request-review",
   "name": "Pull Request Review",
-  "description": "Staff-engineer-style code review. Five steps:\n\n1. **Load PR context** — figure out which PR, fetch metadata + diff\n2. **Scan diff** — pattern-based first-pass + judgment-based second-pass\n3. **Raise findings** or **Approve** — branches on whether issues were found\n4. **Summary** — stamp a final verdict to task notes\n\nPorted from gstack's `/review`. The bash-driven preamble (gstack-config,\ngstack-learnings-search, gstack-telemetry-log) is replaced by:\n\n- The `pr-context.ts` script loads PR metadata via `github_pr_view`/`github_pr_diff`\n- `diff-scan.ts` applies the safety/quality patterns from gstack's\n  `review/checklist.md` (SQL, secrets, `any`, console.log, etc.)\n- Memory (via `save_memory` / `search_memory`) replaces gstack's\n  `learnings.jsonl` — search prior reviews for \"have we seen this\n  pattern before?\"\n\nThe branches behavior: `diff-scan` stamps `clean: boolean` into the\nrun output; the **Scan diff** step routes to **Approve** when clean and\nto **Raise findings** otherwise.\n\nThis craftbook needs the github toolset configured (PAT) — without it,\nthe PR-fetch tools error and the craftbook surfaces an actionable\nmessage to the user.\n",
+  "description": "Staff-engineer-style code review. Five steps:\n\n1. **Load PR context** — figure out which PR, fetch metadata + diff\n2. **Scan diff** — pattern-based first-pass + judgment-based second-pass\n3. **Raise findings** or **Approve** — branches on whether issues were found\n4. **Summary** — stamp a final verdict to task notes\n\nThe upstream procedure's bash-driven preamble (config lookup, learnings\nsearch, telemetry logging) is replaced by:\n\n- The `pr-context.ts` script loads PR metadata via `github_pr_view`/`github_pr_diff`\n- `diff-scan.ts` applies the upstream safety/quality checklist patterns\n  (SQL, secrets, `any`, console.log, etc.)\n- Memory (via `save_memory` / `search_memory`) replaces the upstream\n  `learnings.jsonl` file — search prior reviews for \"have we seen this\n  pattern before?\"\n\nThe branches behavior: `diff-scan` stamps `clean: boolean` into the\nrun output; the **Scan diff** step routes to **Approve** when clean and\nto **Raise findings** otherwise.\n\nThis craftbook needs the github toolset configured (PAT) — without it,\nthe PR-fetch tools error and the craftbook surfaces an actionable\nmessage to the user.\n",
   "entryStepId": "load-pr",
   "triggers": [
     "review this pr",

package/data/craftbook-templates/pu/pull-request-review/versions/1.1.0/craftbook.json

@@ -1,7 +1,7 @@
 {
   "id": "pull-request-review",
   "name": "Pull Request Review",
-  "description": "Staff-engineer-style code review. Five steps:\n\n1. **Load PR context** — figure out which PR, fetch metadata + diff\n2. **Scan diff** — pattern-based first-pass + judgment-based second-pass\n3. **Raise findings** or **Approve** — branches on whether issues were found\n4. **Summary** — stamp a final verdict to task notes\n\nPorted from gstack's `/review`. The bash-driven preamble (gstack-config,\ngstack-learnings-search, gstack-telemetry-log) is replaced by:\n\n- The `pr-context.ts` script loads PR metadata via `github_pr_view`/`github_pr_diff`\n- `diff-scan.ts` applies the safety/quality patterns from gstack's\n  `review/checklist.md` (SQL, secrets, `any`, console.log, etc.)\n- Memory (via `save_memory` / `search_memory`) replaces gstack's\n  `learnings.jsonl` — search prior reviews for \"have we seen this\n  pattern before?\"\n\nThe branches behavior: `diff-scan` stamps `clean: boolean` into the\nrun output; the **Scan diff** step routes to **Approve** when clean and\nto **Raise findings** otherwise.\n\nThis craftbook needs the github toolset configured (PAT) — without it,\nthe PR-fetch tools error and the craftbook surfaces an actionable\nmessage to the user.\n",
+  "description": "Staff-engineer-style code review. Five steps:\n\n1. **Load PR context** — figure out which PR, fetch metadata + diff\n2. **Scan diff** — pattern-based first-pass + judgment-based second-pass\n3. **Raise findings** or **Approve** — branches on whether issues were found\n4. **Summary** — stamp a final verdict to task notes\n\nThe upstream procedure's bash-driven preamble (config lookup, learnings\nsearch, telemetry logging) is replaced by:\n\n- The `pr-context.ts` script loads PR metadata via `github_pr_view`/`github_pr_diff`\n- `diff-scan.ts` applies the upstream safety/quality checklist patterns\n  (SQL, secrets, `any`, console.log, etc.)\n- Memory (via `save_memory` / `search_memory`) replaces the upstream\n  `learnings.jsonl` file — search prior reviews for \"have we seen this\n  pattern before?\"\n\nThe branches behavior: `diff-scan` stamps `clean: boolean` into the\nrun output; the **Scan diff** step routes to **Approve** when clean and\nto **Raise findings** otherwise.\n\nThis craftbook needs the github toolset configured (PAT) — without it,\nthe PR-fetch tools error and the craftbook surfaces an actionable\nmessage to the user.\n",
   "entryStepId": "load-pr",
   "triggers": [
     "review this pr",

package/data/craftbook-templates/qa/qa/manifest.json

@@ -6,8 +6,7 @@
   "description": "Live UI QA pass with a real browser. Navigates the target, interacts with the golden-path flow, captures findings, fixes atomically, re-tests.",
   "tags": [
     "qa",
-    "playwright",
-    "gstack"
+    "playwright"
   ],
   "maintainer": {
     "name": "Gezel"

package/data/craftbook-templates/qa/qa/versions/1.0.0/craftbook.json

@@ -1,7 +1,7 @@
 {
   "id": "qa",
   "name": "QA",
-  "description": "Live UI QA pass using a real browser. Ported from gstack's `/qa` skill,\nwhich leans heavily on Playwright. Gezel runs Playwright via the\n`run_playwright_script` MCP tool, so the model writes the actual\ninteraction script — but the craftbook provides the structure.\n\nSix steps:\n\n1. **Smoke** — navigate, confirm the page loaded\n2. **Exercise the flow** — golden path: click CTA, fill form, submit, verify\n3. **Edges** — small set of edge cases (empty, oversized, double-submit, back)\n4. **Triage** — branched: stamp the finding when something broke\n5. **Summary** — branched: clean pass\n6. **Halt** — branched: smoke failed before testing started\n\nThe script `qa-trace.ts` is a thin wrapper around `run_playwright_script`\nthat returns a YAML accessibility snapshot — gives the model a structured\nview of what's on the page without having to parse a 200KB HTML blob.\n\nImportant: this craftbook **does not fix bugs**. When QA surfaces a\nfinding, the recipe halts. Fixing is a separate concern — the user\nroutes the finding to `/investigate` (root cause) and then to a regular\nedit task. Mixing QA + fix in one craftbook is how gstack's earlier\nversions ended up with 161KB SKILL.md files.\n",
+  "description": "Live UI QA pass using a real browser, driven heavily by Playwright.\nGezel runs Playwright via the\n`run_playwright_script` MCP tool, so the model writes the actual\ninteraction script — but the craftbook provides the structure.\n\nSix steps:\n\n1. **Smoke** — navigate, confirm the page loaded\n2. **Exercise the flow** — golden path: click CTA, fill form, submit, verify\n3. **Edges** — small set of edge cases (empty, oversized, double-submit, back)\n4. **Triage** — branched: stamp the finding when something broke\n5. **Summary** — branched: clean pass\n6. **Halt** — branched: smoke failed before testing started\n\nThe script `qa-trace.ts` is a thin wrapper around `run_playwright_script`\nthat returns a YAML accessibility snapshot — gives the model a structured\nview of what's on the page without having to parse a 200KB HTML blob.\n\nImportant: this craftbook **does not fix bugs**. When QA surfaces a\nfinding, the recipe halts. Fixing is a separate concern — the user\nroutes the finding to `/investigate` (root cause) and then to a regular\nedit task. Mixing QA and fixing in one craftbook is how a procedure balloons\ninto an unmaintainable monolith.\n",
   "entryStepId": "smoke",
   "triggers": [
     "qa this",

package/data/craftbook-templates/sh/ship/manifest.json

@@ -5,8 +5,7 @@
   "name": "Ship",
   "description": "End-to-end release procedure: run tests, run a review pass, commit/push, open the PR, wait for CI to come back green, hand off for merge. Requires a GitHub-connected project on a feature branch.",
   "tags": [
-    "release",
-    "gstack"
+    "release"
   ],
   "maintainer": {
     "name": "Gezel"

package/data/craftbook-templates/sh/ship/versions/1.0.0/craftbook.json

@@ -1,7 +1,7 @@
 {
   "id": "ship",
   "name": "Ship",
-  "description": "End-to-end release procedure ported from gstack's `/ship`. Six normal\nsteps + one halt step the branches divert to on failure:\n\n1. **Preflight** — snapshot branch + working-tree state, gate trunk pushes\n2. **Run tests** — project's primary test command\n3. **Self-review pass** — last walk through the diff\n4. **Open PR** — push + create\n5. **Wait for CI** — poll until green or failure\n6. **Summary** — final DONE\n7. **Halt** (branched target) — DONE_WITH_CONCERNS on any failure\n\nThe branches are the load-bearing piece. If tests fail, CI fails, or\nthe poll times out, the recipe routes to `halt` rather than blasting\nthrough. That's the safety property gstack's bash flow encoded in\nimperative if/else; the craftbook schema makes it explicit.\n\nScripts:\n- `run-tests.ts` — wraps `run_package_script` with the right test command\n- `open-pr.ts` — pushes the branch, calls `github_pr_create`\n- `wait-checks.ts` — polls `github_check_status` until settled\n\n## Applicability\n\nThe craftbook declares two manifest-level `requirements` so the launcher\nand command registry only offer it where it can actually run:\n\n- **github** — the project must be connected to a GitHub repo (the\n  `open-pr` and `wait-checks` scripts call `github_pr_create` /\n  `github_check_status` directly; without a connected repo they have\n  nowhere to push to).\n- **non-main-branch** — the project's checkout must be on a branch\n  other than `main` / `master`. The preflight step's `ask_user_question`\n  was a runtime guard against accidental trunk shipping; promoting it\n  to a hard `requirements` gate removes the temptation entirely. The\n  step-level prompt still re-checks in case the catalog's branch\n  snapshot is stale.\n\nRequires the github toolset configured. Both gates evaluate via\n`unmetCraftbookRequirements` in `@bendyline/gezel` and are surfaced\nthrough `/api/projects/:id/craftbooks` so the Commands panel hides the\ncraftbook in projects that don't qualify rather than letting the user\nlaunch it and watch step 4 fail.\n",
+  "description": "End-to-end release procedure. Six normal\nsteps + one halt step the branches divert to on failure:\n\n1. **Preflight** — snapshot branch + working-tree state, gate trunk pushes\n2. **Run tests** — project's primary test command\n3. **Self-review pass** — last walk through the diff\n4. **Open PR** — push + create\n5. **Wait for CI** — poll until green or failure\n6. **Summary** — final DONE\n7. **Halt** (branched target) — DONE_WITH_CONCERNS on any failure\n\nThe branches are the load-bearing piece. If tests fail, CI fails, or\nthe poll times out, the recipe routes to `halt` rather than blasting\nthrough. The upstream procedure encoded that safety property in\nimperative if/else; the craftbook schema makes it explicit.\n\nScripts:\n- `run-tests.ts` — wraps `run_package_script` with the right test command\n- `open-pr.ts` — pushes the branch, calls `github_pr_create`\n- `wait-checks.ts` — polls `github_check_status` until settled\n\n## Applicability\n\nThe craftbook declares two manifest-level `requirements` so the launcher\nand command registry only offer it where it can actually run:\n\n- **github** — the project must be connected to a GitHub repo (the\n  `open-pr` and `wait-checks` scripts call `github_pr_create` /\n  `github_check_status` directly; without a connected repo they have\n  nowhere to push to).\n- **non-main-branch** — the project's checkout must be on a branch\n  other than `main` / `master`. The preflight step's `ask_user_question`\n  was a runtime guard against accidental trunk shipping; promoting it\n  to a hard `requirements` gate removes the temptation entirely. The\n  step-level prompt still re-checks in case the catalog's branch\n  snapshot is stale.\n\nRequires the github toolset configured. Both gates evaluate via\n`unmetCraftbookRequirements` in `@bendyline/gezel` and are surfaced\nthrough `/api/projects/:id/craftbooks` so the Commands panel hides the\ncraftbook in projects that don't qualify rather than letting the user\nlaunch it and watch step 4 fail.\n",
   "entryStepId": "preflight",
   "triggers": [
     "ship this",

package/data/craftbook-templates/sh/ship/versions/1.1.0/craftbook.json

@@ -1,7 +1,7 @@
 {
   "id": "ship",
   "name": "Ship",
-  "description": "End-to-end release procedure ported from gstack's `/ship`. Six normal\nsteps + one halt step the branches divert to on failure:\n\n1. **Preflight** — snapshot branch + working-tree state, gate trunk pushes\n2. **Run tests** — project's primary test command\n3. **Self-review pass** — last walk through the diff\n4. **Open PR** — push + create\n5. **Wait for CI** — poll until green or failure\n6. **Summary** — final DONE\n7. **Halt** (branched target) — DONE_WITH_CONCERNS on any failure\n\nThe branches are the load-bearing piece. If tests fail, CI fails, or\nthe poll times out, the recipe routes to `halt` rather than blasting\nthrough. That's the safety property gstack's bash flow encoded in\nimperative if/else; the craftbook schema makes it explicit.\n\nScripts:\n- `run-tests.ts` — wraps `run_package_script` with the right test command\n- `open-pr.ts` — pushes the branch, calls `github_pr_create`\n- `wait-checks.ts` — polls `github_check_status` until settled\n\n## Applicability\n\nThe craftbook declares two manifest-level `requirements` so the launcher\nand command registry only offer it where it can actually run:\n\n- **github** — the project must be connected to a GitHub repo (the\n  `open-pr` and `wait-checks` scripts call `github_pr_create` /\n  `github_check_status` directly; without a connected repo they have\n  nowhere to push to).\n- **non-main-branch** — the project's checkout must be on a branch\n  other than `main` / `master`. The preflight step's `ask_user_question`\n  was a runtime guard against accidental trunk shipping; promoting it\n  to a hard `requirements` gate removes the temptation entirely. The\n  step-level prompt still re-checks in case the catalog's branch\n  snapshot is stale.\n\nRequires the github toolset configured. Both gates evaluate via\n`unmetCraftbookRequirements` in `@bendyline/gezel` and are surfaced\nthrough `/api/projects/:id/craftbooks` so the Commands panel hides the\ncraftbook in projects that don't qualify rather than letting the user\nlaunch it and watch step 4 fail.\n",
+  "description": "End-to-end release procedure. Six normal\nsteps + one halt step the branches divert to on failure:\n\n1. **Preflight** — snapshot branch + working-tree state, gate trunk pushes\n2. **Run tests** — project's primary test command\n3. **Self-review pass** — last walk through the diff\n4. **Open PR** — push + create\n5. **Wait for CI** — poll until green or failure\n6. **Summary** — final DONE\n7. **Halt** (branched target) — DONE_WITH_CONCERNS on any failure\n\nThe branches are the load-bearing piece. If tests fail, CI fails, or\nthe poll times out, the recipe routes to `halt` rather than blasting\nthrough. The upstream procedure encoded that safety property in\nimperative if/else; the craftbook schema makes it explicit.\n\nScripts:\n- `run-tests.ts` — wraps `run_package_script` with the right test command\n- `open-pr.ts` — pushes the branch, calls `github_pr_create`\n- `wait-checks.ts` — polls `github_check_status` until settled\n\n## Applicability\n\nThe craftbook declares two manifest-level `requirements` so the launcher\nand command registry only offer it where it can actually run:\n\n- **github** — the project must be connected to a GitHub repo (the\n  `open-pr` and `wait-checks` scripts call `github_pr_create` /\n  `github_check_status` directly; without a connected repo they have\n  nowhere to push to).\n- **non-main-branch** — the project's checkout must be on a branch\n  other than `main` / `master`. The preflight step's `ask_user_question`\n  was a runtime guard against accidental trunk shipping; promoting it\n  to a hard `requirements` gate removes the temptation entirely. The\n  step-level prompt still re-checks in case the catalog's branch\n  snapshot is stale.\n\nRequires the github toolset configured. Both gates evaluate via\n`unmetCraftbookRequirements` in `@bendyline/gezel` and are surfaced\nthrough `/api/projects/:id/craftbooks` so the Commands panel hides the\ncraftbook in projects that don't qualify rather than letting the user\nlaunch it and watch step 4 fail.\n",
   "entryStepId": "preflight",
   "triggers": [
     "ship this",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bendyline/gilde",
-  "version": "0.1.8",
+  "version": "0.1.10",
   "description": "The gilde catalog: model manifests, toolsets, craftbooks, roles, and project types for gezel.",
   "license": "MIT",
   "private": false,
@@ -24,7 +24,8 @@
     "./schemas/*": "./schemas/*"
   },
   "scripts": {
-    "check": "npm run format && npm run format:check && npm run validate && npm run check-index && npm run lint-models && npm run check-page-demos",
+    "fix": "npm run format && npm run build-index",
+    "check": "npm run format:check && npm run validate && npm run check-index && npm run lint-models && npm run check-page-demos",
     "validate": "npm --prefix tools ci --silent && node tools/validate.mjs",
     "build-index": "node tools/build-index.mjs",
     "check-index": "node tools/build-index.mjs --check",