@bendyline/gilde 0.1.27 → 0.1.28

package/data/craftbook-templates/co/codebase-ux-review/versions/1.0.1/test.json

@@ -0,0 +1,119 @@
+{
+  "schemaVersion": 1,
+  "title": "Codebase UX Review journey eval",
+  "objective": "Measure whether the review traces a seeded user journey and reports high-impact state, recovery, and destructive-action problems with source evidence.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "Use the Codebase UX Review craftbook for a weekly product-experience pass. The app is not running, so trace the seeded source honestly and write ux-review.md. Do not edit the UI.",
+  "setup": {
+    "projectName": "UX Maintenance Eval",
+    "about": "A returns dashboard with deliberate loading, empty, error, recovery, and destructive-action friction.",
+    "missionObjectives": "Leave a journey-centered UX report and clearly label static inference versus runtime evidence.",
+    "files": [
+      {
+        "path": "src/ReturnsPage.tsx",
+        "content": "export function ReturnsPage({ api }) {\n  const [query, setQuery] = useState('');\n  const [items, setItems] = useState([]);\n  async function search(e) {\n    e.preventDefault();\n    setQuery('');\n    try { setItems(await api.search(query)); }\n    catch (_err) { alert('Something went wrong'); }\n  }\n  return <main>\n    <h1>Returns</h1>\n    <form onSubmit={search}><input value={query} onChange={e => setQuery(e.target.value)} /><button>Go</button></form>\n    <button aria-label=\"action\" onClick={() => api.deleteAll()}>🗑</button>\n    <ul>{items.map(item => <li key={item.id}>{item.name}</li>)}</ul>\n  </main>;\n}\n"
+      },
+      {
+        "path": "src/nav.ts",
+        "content": "export const nav = [{ label: 'Desk', href: '/' }, { label: 'Things', href: '/returns' }, { label: 'More', href: '/settings' }];\n"
+      },
+      {
+        "path": "docs/product.md",
+        "content": "# Primary journey\n\nAn operations lead searches by order number, reviews matches, and deletes only a selected invalid return after confirmation. Search errors should preserve the query and explain how to retry.\n"
+      }
+    ],
+    "worker": {
+      "name": "Rae",
+      "role": "Reviewer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "ux-review.md covers the primary journey, static-evidence limits, missing states, recovery loss, and unsafe delete-all control.",
+    "deliverables": [
+      {
+        "path": "ux-review.md",
+        "kind": "markdown-report",
+        "minBytes": 1500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "src/ReturnsPage\\.tsx|docs/product\\.md",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "journey|search by order",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "loading|pending",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "empty state|no results",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "preserv(e|ing).*query|setQuery|retry",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "deleteAll|confirmation|destructive",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "static|not verified|not runnable",
+            "flags": "i",
+            "label": "honest evidence"
+          },
+          {
+            "kind": "contains",
+            "file": "ux-review.md",
+            "pattern": "Morning action|priority|severity",
+            "flags": "i"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "ux-review.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "journey coverage",
+        "description": "The review follows the primary task through success and failure states."
+      },
+      {
+        "name": "evidence honesty",
+        "description": "Static inference is clearly separated from exercised runtime behavior."
+      },
+      {
+        "name": "prioritization",
+        "description": "Findings are ranked by user harm and frequency with concrete remedies."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "journey-centered review",
+    "state and recovery UX",
+    "runtime-vs-static honesty"
+  ]
+}

package/data/craftbook-templates/co/cohort-analysis/versions/1.0.1/craftbook.json

@@ -0,0 +1,141 @@
+{
+  "id": "cohort-analysis",
+  "name": "Cohort / Retention Analysis",
+  "description": "Analyze retention or behavior by cohort to reveal whether the product is getting stickier over time. Defines the cohort key, the activity event, and the retention window FIRST (so 'retained' has one unambiguous meaning), then builds the cohort/retention table and computes retention curves and trends as a data-analyst, then writes a readout on what the cohorts reveal. Use this for retention analysis, cohort tables, churn/stickiness analysis, a retention curve, or 'are newer users retaining better than older ones'.\n\nA gallery craftbook generated from an archetype spec. It runs\n`phase → (per-phase gate) → … → evaluate → (loop) → finish`. Each build\nphase that produces a checkable artifact is followed by a **runtime\ngate-checkpoint** — the runtime verifies the artifact and routes with no\nmodel turn, looping back to redo the phase on a miss. The final `evaluate`\nstep holds a static deliverable gate plus a reviewer QA pass. What it adds\nover the generic `build-loop`: a specialist role per phase, a\ndomain-correct ordering, and a concrete per-phase quality bar.\n\nDeliverables marked \"artifact\" land in the project's artifacts drawer (`write_artifact` / `read_artifact`), not the shipped workspace — review output is not product source.\n\nPhases:\n\n1. Scope the cohorts (data-analyst) — lock the cohort key, activity event, and retention window → gated on artifact `notes/scope.md` (markdown-notes)\n2. Build the cohort table (data-analyst) — compute the retention matrix and curves → gated on `data/cohorts.json` (json)\n3. Write the readout (copywriter) — explain what the cohorts reveal about retention → gated on artifact `readout.md` (markdown-report)\n\nData output discipline:\n\n- `data/cohorts.json` must be valid JSON only: no Markdown fences, comments, formulas, or ratio strings.\n- Use stable keys such as `signup_week`, `total_users`, and `retention`.\n- Store retention rates as numeric decimals rounded consistently, for example `0.67`, not `\"2/3\"` or `\"66.7%\"`.\n- Distinguish observed zero retention from incomplete future periods: use `0` when the period is observed and no cohort users were active, and `null` when the period is outside the observed window.\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "cohort analysis",
+    "retention curve",
+    "are newer users retaining better",
+    "churn analysis",
+    "retention table"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Scope the cohorts",
+      "description": "lock the cohort key, activity event, and retention window",
+      "prompt": "Define retention unambiguously before computing anything. Step 1: choose the cohort key — usually signup/first-activity period (weekly or monthly), and state the period. Step 2: define the ACTIVITY that counts as 'retained' (logged in, made a purchase, used core feature) and the unit (a user, an account). Step 3: define the retention window and periods (W0..W8, or M0..M6) and whether it's classic (active in period N) or rolling/unbounded. Step 4: state filters (exclude test accounts, a minimum-tenure cutoff so incomplete recent cohorts are flagged). Step 5: write an acceptance-criteria checklist ('cohort key and activity are precisely defined', 'retention table has cohorts as rows and periods as columns', 'period 0 is 100% by construction', 'incomplete recent cohorts are flagged', 'a trend across cohorts is reported'). Call write_task_note and write the definitions + checklist to notes/scope.md.\n\nThe deliverable `notes/scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "data-analyst",
+      "advanceWhen": {
+        "file": "notes/scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "analyze"
+    },
+    {
+      "id": "analyze",
+      "name": "Build the cohort table",
+      "description": "compute the retention matrix and curves",
+      "prompt": "Compute the cohort retention matrix from the defined rules. Step 1: assign each user/account to its cohort by the cohort key. Step 2: for each cohort and each retention period, compute the share of the cohort that performed the activity in that period; period 0 is 100% by construction. Step 3: build the triangular retention matrix (cohorts x periods), the cohort sizes, and the average retention curve across cohorts. Step 4: compute the trend — are later cohorts retaining better at the same period age than earlier ones? Step 5: flag cohorts too recent to have full data. Emit data/cohorts.json (matrix, sizes, average curve, trend) and call write_task_note with the headline retention numbers and the trend.",
+      "suggestedRole": "data-analyst",
+      "advanceWhen": {
+        "file": "data/cohorts.json",
+        "minBytes": 1,
+        "sniff": "json-valid"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "data/cohorts.json",
+            "bytes": 2
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkJsonValid",
+            "scope": "standard",
+            "inputs": {
+              "file": "data/cohorts.json"
+            }
+          }
+        ],
+        "onReject": "analyze",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the readout",
+      "description": "explain what the cohorts reveal about retention",
+      "prompt": "Write the retention readout from the computed matrix — no invented figures. Step 1: lead with the headline: the typical W1/M1 retention and where the curve flattens (the 'sticky' floor). Step 2: present the retention table (cohorts as rows, periods as columns) and read it for the reader. Step 3: state the cross-cohort trend in plain language ('M1 retention improved from 22% to 31% over the last 6 cohorts'). Step 4: call out the best and worst cohorts and any inflection. Step 5: caveat the incomplete recent cohorts and suggest one next action. Write the readout to readout.md and call write_task_note with the path. On a loop-back, fix only the named gaps.\n\nThe deliverable `readout.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "readout.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "readout.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "Read readout.md and cross-check against notes/scope.md and data/cohorts.json. Verify: the cohort key and activity are precisely defined and used; the retention table has cohorts as rows and periods as columns with period 0 = 100%; incomplete recent cohorts are flagged; and a cross-cohort trend is reported with numbers. Re-check the headline W1/M1 retention and the trend against the cohort data. Confirm no cohort's retention exceeds 100% or rises impossibly. Write PASS/FAIL per criterion; any FAIL loops back to write.\n\nThe deliverable lives in the project's artifacts drawer — open `readout.md` with `read_artifact`, not `read_file`.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"write\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "readout.md",
+          "artifact": true
+        }
+      ],
+      "next": "write"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.0.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}

package/data/craftbook-templates/co/cohort-analysis/versions/1.0.1/test.json

@@ -0,0 +1,226 @@
+{
+  "schemaVersion": 1,
+  "title": "Retention cohort readout from event table",
+  "objective": "Measure whether the cohort-analysis craftbook defines retention, emits a cohort matrix, and explains trend/incomplete cohorts.",
+  "tags": [
+    "data"
+  ],
+  "prompt": "In the `Cohort Analysis Eval` project, read `data/events.csv`, define weekly signup cohorts and week-retained activity, write `data/cohorts.json`, and write `readout.md` with a retention table, W1/W2 trend, best/worst cohorts, incomplete cohort caveat, and one next action. Use unique users per signup_week as cohort size. Period WN means active exactly N weeks after signup; missing activity in an observed week counts as 0, but future unobserved periods are null. Treat 2026-W23 as the latest observed activity week; therefore 2026-W22 W2 would fall in 2026-W24 and must be marked null/incomplete, not estimated. `data/cohorts.json` must be valid JSON only, with no Markdown, comments, formulas, or ratio strings, using this shape: `{ \"cohorts\": [{ \"signup_week\": \"2026-W20\", \"total_users\": 3, \"retention\": { \"W0\": 1, \"W1\": 0.67, \"W2\": 0.33 } }] }`. Use numeric decimal rates rounded to two decimals, or null for incomplete periods.",
+  "setup": {
+    "projectName": "Cohort Analysis Eval",
+    "about": "Self-contained eval project for cohort-analysis. User activity events are in workspace/data/events.csv.",
+    "missionObjectives": "Compute and explain cohort retention with precise definitions, JSON matrix, trend, caveats, and next action.",
+    "files": [
+      {
+        "path": "data/events.csv",
+        "content": "user_id,signup_week,activity_week,event\nu1,2026-W20,2026-W20,core_use\nu1,2026-W20,2026-W21,core_use\nu1,2026-W20,2026-W22,core_use\nu2,2026-W20,2026-W20,core_use\nu2,2026-W20,2026-W21,core_use\nu3,2026-W20,2026-W20,core_use\nu4,2026-W21,2026-W21,core_use\nu4,2026-W21,2026-W22,core_use\nu5,2026-W21,2026-W21,core_use\nu5,2026-W21,2026-W22,core_use\nu6,2026-W21,2026-W21,core_use\nu7,2026-W22,2026-W22,core_use\nu7,2026-W22,2026-W23,core_use\nu8,2026-W22,2026-W22,core_use\nu9,2026-W22,2026-W22,core_use\nu9,2026-W22,2026-W23,core_use\n"
+      }
+    ],
+    "worker": {
+      "name": "Joris",
+      "role": "Data Analyst"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "workspace/readout.md and data/cohorts.json define retention, show cohort rows/periods, report trend, flag incomplete cohorts, and recommend an action.",
+    "deliverables": [
+      {
+        "path": "readout.md",
+        "kind": "markdown-report",
+        "minBytes": 1500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "cohort|retention|W0|W1|W2",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "2026-W20|2026-W21|2026-W22",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "100%|67%|66%|33%|0%|trend",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "incomplete|recent cohort|caveat|next action",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "2026-W22[\\s\\S]{0,250}(incomplete|null|not yet observed|2026-W24)",
+            "flags": "i",
+            "label": "mark W22 W2 as incomplete instead of estimating it"
+          },
+          {
+            "kind": "contains",
+            "file": "readout.md",
+            "pattern": "2026-W21[^\\n]*(?:0%|0\\.00)",
+            "flags": "i",
+            "label": "readout must show 2026-W21 W2 as observed zero retention"
+          },
+          {
+            "kind": "notContains",
+            "file": "readout.md",
+            "pattern": "37\\.5%|\\b4\\s+users\\b|total users\\s*\\|\\s*4|2026-W21[^\\n]*(?:N/A|null|incomplete)|W2 for 2026-W21[^\\n]*(?:N/A|null|incomplete)",
+            "flags": "i",
+            "label": "do not invent a fourth 2026-W22 user, estimate W2, or mark observed W21 W2 as incomplete"
+          }
+        ]
+      },
+      {
+        "path": "data/cohorts.json",
+        "kind": "json",
+        "minBytes": 250,
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "data/cohorts.json",
+            "sniff": "json-valid"
+          },
+          {
+            "kind": "contains",
+            "file": "data/cohorts.json",
+            "pattern": "2026-W20|2026-W21|2026-W22|W0|W1",
+            "flags": "i"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[0].signup_week",
+            "value": "2026-W20",
+            "label": "first cohort must be 2026-W20"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[0].total_users",
+            "value": 3,
+            "label": "2026-W20 has exactly 3 unique signup users"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[0].retention.W2",
+            "value": 0.33,
+            "label": "2026-W20 W2 retention is 1/3 rounded to 0.33"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[0].retention.W1",
+            "value": 0.67,
+            "label": "2026-W20 W1 retention is 2/3 rounded to 0.67"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[1].signup_week",
+            "value": "2026-W21",
+            "label": "second cohort must be 2026-W21"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[1].total_users",
+            "value": 3,
+            "label": "2026-W21 has exactly 3 unique signup users"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[1].retention.W1",
+            "value": 0.67,
+            "label": "2026-W21 W1 retention is 2/3 because u4 and u5 were active in W22"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[1].retention.W2",
+            "value": 0,
+            "label": "2026-W21 W2 retention is 0/3 because no W21 users were active in W23"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[2].signup_week",
+            "value": "2026-W22",
+            "label": "third cohort must be 2026-W22"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[2].total_users",
+            "value": 3,
+            "label": "2026-W22 has exactly 3 unique signup users"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[2].retention.W1",
+            "value": 0.67,
+            "label": "2026-W22 W1 retention is 2/3 rounded to 0.67"
+          },
+          {
+            "kind": "jsonPathEquals",
+            "file": "data/cohorts.json",
+            "path": "cohorts[2].retention.W2",
+            "value": null,
+            "label": "2026-W22 W2 retention is incomplete/null because W24 is outside the observed window"
+          },
+          {
+            "kind": "notContains",
+            "file": "data/cohorts.json",
+            "pattern": "37\\.5|0\\.375|\"total_users\"\\s*:\\s*4",
+            "flags": "i",
+            "label": "do not invent a fourth 2026-W22 user or estimate W2"
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "readout.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "accuracy",
+        "description": "Computed figures are correct against the seeded records."
+      },
+      {
+        "name": "grounding",
+        "description": "Every claim traces to the seeded data — nothing invented."
+      },
+      {
+        "name": "structure",
+        "description": "Tables and sections make the analysis checkable at a glance."
+      },
+      {
+        "name": "actionability",
+        "description": "Recommendations follow from the findings and are concretely doable."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "definition before math",
+    "JSON retention matrix",
+    "trend readout"
+  ]
+}

package/data/craftbook-templates/co/company-research-brief/versions/1.0.1/craftbook.json

@@ -0,0 +1,139 @@
+{
+  "id": "company-research-brief",
+  "name": "Company Research Brief",
+  "description": "A sharp, dated, sourced brief on a company before an interview or application — what they do and how they make money, recent signals, team and role context, culture as evidenced, likely interview themes, and five specific questions to ask THEM. Skimmable in ten minutes; every claim dated or marked UNKNOWN rather than guessed. Use before any serious interview or when deciding whether to apply.\n\nA gallery craftbook generated from an archetype spec. It runs\n`phase → (per-phase gate) → … → evaluate → (loop) → finish`. Each build\nphase that produces a checkable artifact is followed by a **runtime\ngate-checkpoint** — the runtime verifies the artifact and routes with no\nmodel turn, looping back to redo the phase on a miss. The final `evaluate`\nstep holds a static deliverable gate plus a reviewer QA pass. What it adds\nover the generic `build-loop`: a specialist role per phase, a\ndomain-correct ordering, and a concrete per-phase quality bar.\n\nDeliverables marked \"artifact\" land in the project's artifacts drawer (`write_artifact` / `read_artifact`), not the shipped workspace — review output is not product source.\n\nPhases:\n\n1. Lock the brief template (planner) — sections, sourcing rules, and what a ten-minute skim must deliver → gated on artifact `notes/brief-scope.md` (markdown-notes)\n2. Gather the facts (researcher) — dated, sourced notes keyed to the template sections → gated on artifact `notes/research-notes.md` (markdown-notes)\n3. Write the brief (copywriter) — the ten-minute brief, led by what matters for the interview → gated on artifact `reports/company-brief.md` (markdown-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "scope",
+  "triggers": [
+    "research this company",
+    "company brief before my interview",
+    "prep me on this company",
+    "what should I know about this company"
+  ],
+  "steps": [
+    {
+      "id": "scope",
+      "name": "Lock the brief template",
+      "description": "sections, sourcing rules, and what a ten-minute skim must deliver",
+      "prompt": "Lock the shape before researching. Step 1: confirm the target company, role, and interview round from the project record or the user (briefly). Step 2: lock the brief's section template: what they do + business model; recent news and signals (each dated); team and role context; culture as evidenced by concrete facts (not the careers-page adjectives); likely interview themes for this role; five sharp questions to ask THEM. Step 3: set the sourcing rules — every claim carries a date or a source, anything unverifiable is marked UNKNOWN, nothing is guessed. Step 4: set the size budget: skimmable in ten minutes. Step 5: write an acceptance-criteria checklist ('every section present', 'claims dated/sourced or UNKNOWN', 'questions specific to this company — would not fit a competitor', 'ten-minute skim'). Write the template + checklist via write_task_note AND to notes/brief-scope.md.\n\nThe deliverable `notes/brief-scope.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "planner",
+      "advanceWhen": {
+        "file": "notes/brief-scope.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/brief-scope.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/brief-scope.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "scope",
+        "maxAttempts": 3
+      },
+      "next": "research"
+    },
+    {
+      "id": "research",
+      "name": "Gather the facts",
+      "description": "dated, sourced notes keyed to the template sections",
+      "prompt": "Gather facts for every template section. Step 1: use the web research capabilities on your current roster when available; otherwise work from materials in the project and say so at the top of the notes. Step 2: collect facts into structured notes keyed by template section, each with its date and source. Step 3: hunt specifically for recent signals — funding, launches, leadership changes, layoffs, public filings, engineering-blog themes — and for evidence of how the team actually works. Step 4: mark anything you could not verify as UNKNOWN rather than filling the hole with a plausible guess. Step 5: note two or three observations that could become sharp questions to ask them. Write the notes via write_task_note AND to notes/research-notes.md.\n\nThe deliverable `notes/research-notes.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "researcher",
+      "advanceWhen": {
+        "file": "notes/research-notes.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/research-notes.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/research-notes.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "research",
+        "maxAttempts": 3
+      },
+      "next": "write"
+    },
+    {
+      "id": "write",
+      "name": "Write the brief",
+      "description": "the ten-minute brief, led by what matters for the interview",
+      "prompt": "Assemble reports/company-brief.md to the locked template. Step 1: lead with the two or three things that matter most for THIS interview — the reader may only get the first screen. Step 2: fill every template section from the research notes; every claim traces to a dated note, UNKNOWNs stay visibly UNKNOWN. Step 3: write the likely-interview-themes section as preparation the candidate can act on tonight. Step 4: close with the five questions to ask them — each specific enough that it would make no sense asked of a competitor. Step 5: trim to the ten-minute skim budget; cut color, keep signal. On a loop-back, fix ONLY the named issues.\n\nThe deliverable `reports/company-brief.md` lands in the project's artifacts drawer — write it with `write_artifact` and read it back with `read_artifact`; the shipped workspace stays untouched.",
+      "suggestedRole": "copywriter",
+      "advanceWhen": {
+        "file": "reports/company-brief.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "reports/company-brief.md",
+            "bytes": 1500,
+            "artifact": true
+          },
+          {
+            "kind": "contains",
+            "file": "reports/company-brief.md",
+            "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+            "flags": "i",
+            "label": "at least one markdown heading",
+            "artifact": true
+          }
+        ],
+        "onReject": "write",
+        "maxAttempts": 4
+      },
+      "next": "evaluate"
+    },
+    {
+      "id": "evaluate",
+      "name": "Evaluate",
+      "description": "Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.",
+      "prompt": "QA the brief. Step 1: check every template section is present and filled from the notes — no section silently dropped. Step 2: spot-check claims against the research notes for dating/sourcing; FAIL any undated claim that isn't marked UNKNOWN. Step 3: read the five questions as the interviewer would — FAIL any that could be asked of any company. Step 4: time the skim — if it reads past ten minutes, FAIL with what to cut. Write PASS/FAIL per criterion.\n\nThe deliverable lives in the project's artifacts drawer — open `reports/company-brief.md` with `read_artifact`, not `read_file`.\n\nThen route — this is the whole point of the loop:\n\n- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: \"evaluate\", next: \"finish\" })`.\n- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: \"evaluate\", next: \"write\" })` to loop back. The builder fixes exactly those gaps.\n\nNever route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.",
+      "suggestedRole": "reviewer",
+      "consumes": [
+        {
+          "file": "reports/company-brief.md",
+          "artifact": true
+        }
+      ],
+      "next": "write"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.0.1",
+  "releasedAt": "2026-08-14T00:00:00Z"
+}