@bendyline/gilde 0.1.39 → 0.1.41

package/data/craftbook-templates/sc/schema-migration/versions/2.0.0/test.json

@@ -0,0 +1,226 @@
+{
+  "schemaVersion": 1,
+  "title": "Expand/contract data migration with no record stranded",
+  "objective": "The craftbook drives an expand/contract migration of a JSON user store from a flat name field to a nested profile shape: a plan grounded in the real files, accessors changed at their real sites with the suite green between stages, the data transformed with every value surviving exactly, and the old shape fully retired - verified mechanically, including a pure-nested-record probe proving the dual-read did not linger.",
+  "tags": [
+    "code",
+    "schema-migration",
+    "expand-contract",
+    "tactical-fleet"
+  ],
+  "prompt": "Use the Schema / Type Migration craftbook for this: migrate our user records from the flat name field to the nested profile shape described in source/migration-brief.md. No record may be lost, the accessors in src/users.js must keep working at every stage, and when it is done nothing may read the flat field any more.",
+  "setup": {
+    "projectName": "Crew Roster",
+    "about": "A tiny user-roster module backed by a JSON data file. Tests run with `npm run test` (node --test).",
+    "files": [
+      {
+        "path": "package.json",
+        "content": "{\n  \"name\": \"crew-roster\",\n  \"private\": true,\n  \"version\": \"1.0.0\",\n  \"type\": \"module\",\n  \"scripts\": {\n    \"test\": \"node --test\"\n  }\n}\n"
+      },
+      {
+        "path": "data/users.json",
+        "content": "[\n  { \"id\": 1, \"name\": \"Ada Lovelace\", \"email\": \"ada@example.com\" },\n  { \"id\": 2, \"name\": \"Grace Hopper\", \"email\": \"grace@example.com\" },\n  { \"id\": 3, \"name\": \"Annie Easley\", \"email\": \"annie@example.com\" }\n]\n"
+      },
+      {
+        "path": "src/users.js",
+        "content": "import { readFileSync } from 'node:fs';\n\nconst DB_URL = new URL('../data/users.json', import.meta.url);\n\nexport function loadUsers() {\n  return JSON.parse(readFileSync(DB_URL, 'utf8'));\n}\n\nexport function fullName(user) {\n  return user.name;\n}\n\nexport function byFullName(users, wanted) {\n  return users.find((user) => user.name === wanted);\n}\n"
+      },
+      {
+        "path": "tests/users.test.mjs",
+        "content": "import assert from 'node:assert/strict';\nimport { test } from 'node:test';\nimport { byFullName, fullName, loadUsers } from '../src/users.js';\n\ntest('loads every user record', () => {\n  assert.equal(loadUsers().length, 3);\n});\n\ntest('fullName renders the display name', () => {\n  assert.deepEqual(loadUsers().map(fullName), [\n    'Ada Lovelace',\n    'Grace Hopper',\n    'Annie Easley',\n  ]);\n});\n\ntest('byFullName finds a user by display name', () => {\n  assert.equal(byFullName(loadUsers(), 'Grace Hopper').email, 'grace@example.com');\n});\n"
+      },
+      {
+        "path": "source/migration-brief.md",
+        "content": "# Migration brief: nested profile shape\n\nWe sort and filter by last name now, so the flat `name` field has to go.\n\nCurrent record shape in `data/users.json`:\n\n    { \"id\": 1, \"name\": \"Ada Lovelace\", \"email\": \"ada@example.com\" }\n\nTarget record shape:\n\n    { \"id\": 1, \"profile\": { \"first\": \"Ada\", \"last\": \"Lovelace\" }, \"email\": \"ada@example.com\" }\n\nRules:\n\n- Every existing record must survive the migration exactly - same people, same\n  emails, names split on the single space between first and last name.\n- The accessors in `src/users.js` must keep working for their callers at every\n  stage: `fullName` and `byFullName` keep returning the same display names as\n  today.\n- When the migration is done, nothing reads the flat `name` field any more.\n"
+      },
+      {
+        "path": "tests/verify-migration.mjs",
+        "content": "import assert from 'node:assert/strict';\nimport { execFileSync } from 'node:child_process';\nimport { readFileSync } from 'node:fs';\nimport { join } from 'node:path';\nimport { pathToFileURL } from 'node:url';\n\nconst root = process.cwd();\n\n// 1) The data moved to the target shape with no record stranded.\nconst records = JSON.parse(readFileSync(join(root, 'data/users.json'), 'utf8'));\nassert.ok(Array.isArray(records), 'data/users.json must stay a JSON array');\nassert.equal(records.length, 3, 'all three records must survive the migration');\nconst expected = new Map([\n  ['ada@example.com', ['Ada', 'Lovelace']],\n  ['grace@example.com', ['Grace', 'Hopper']],\n  ['annie@example.com', ['Annie', 'Easley']],\n]);\nfor (const record of records) {\n  assert.ok(record && typeof record === 'object', 'each record must stay an object');\n  assert.ok(!('name' in record), `record ${record.id} still carries the flat name field`);\n  const want = expected.get(record.email);\n  assert.ok(want, `record ${record.id} lost or changed its email`);\n  assert.equal(record.profile?.first, want[0], `record ${record.id} must keep its first name exactly`);\n  assert.equal(record.profile?.last, want[1], `record ${record.id} must keep its last name exactly`);\n}\nconsole.log('SCHEMAMIG_ORACLE data intact');\n\n// 2) The accessors read the new shape - a pure nested record, no flat fallback.\nconst users = await import(pathToFileURL(join(root, 'src/users.js')).href);\nassert.equal(\n  users.fullName({ profile: { first: 'Test', last: 'User' } }),\n  'Test User',\n  'fullName must read profile.first and profile.last',\n);\nassert.equal(\n  users.byFullName([{ profile: { first: 'Grace', last: 'Hopper' }, email: 'x' }], 'Grace Hopper')?.email,\n  'x',\n  'byFullName must match display names on the new shape',\n);\nconsole.log('SCHEMAMIG_ORACLE accessors migrated');\n\n// 3) Contract landed: no flat-shape read remains in the accessor module.\nconst accessorSource = readFileSync(join(root, 'src/users.js'), 'utf8');\nassert.ok(\n  !/\\.name\\b|\\[[\"']name[\"']\\]/.test(accessorSource),\n  'src/users.js still reads the flat name field',\n);\nconsole.log('SCHEMAMIG_ORACLE contract complete');\n\n// 4) The suite is green on the migrated tree, and the seeded test file survives.\nreadFileSync(join(root, 'tests/users.test.mjs'));\nfunction runSuite(cwd) {\n  try {\n    execFileSync(process.execPath, ['--test'], { cwd, stdio: 'pipe', timeout: 30000 });\n    return 0;\n  } catch (err) {\n    return typeof err.status === 'number' ? err.status : 1;\n  }\n}\nassert.equal(runSuite(root), 0, 'the suite must be green after the migration');\nconsole.log('SCHEMAMIG_ORACLE suite green');\nconsole.log('SCHEMAMIG_ORACLE done');\n",
+        "surface": "harness"
+      }
+    ],
+    "craftbookParams": {
+      "workPath": "tasks/eval",
+      "scope": "Migrate data/users.json and src/users.js from the flat name field to profile.first/profile.last per source/migration-brief.md, with no record loss and reads working at every stage."
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "Every record reaches the nested profile shape with its values intact, the accessors read the new shape with the dual-read retired, the flat field is gone from data and code, the suite is green, and every fleet artifact exists with honest receipts.",
+    "deliverables": [
+      {
+        "path": "tasks/eval/migration-plan.md",
+        "kind": "markdown-notes",
+        "artifact": true,
+        "minBytes": 700,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/migration-plan.md",
+            "pattern": "^##\\s+Current shape[\\s\\S]*^##\\s+Target shape[\\s\\S]*^##\\s+Stages[\\s\\S]*^##\\s+Data safety[\\s\\S]*^##\\s+Rollback per stage",
+            "flags": "im",
+            "label": "plan sections in order"
+          },
+          {
+            "kind": "contains",
+            "file": "tasks/eval/migration-plan.md",
+            "pattern": "data/users\\.json",
+            "label": "names the real data file"
+          },
+          {
+            "kind": "citationsResolve",
+            "file": "tasks/eval/migration-plan.md",
+            "minCitations": 2,
+            "artifact": true
+          }
+        ]
+      },
+      {
+        "path": "tasks/eval/change-notes.md",
+        "kind": "markdown-notes",
+        "artifact": true,
+        "minBytes": 700,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/change-notes.md",
+            "pattern": "^##\\s+Stages executed[\\s\\S]*^##\\s+Files touched[\\s\\S]*^##\\s+Data transformed[\\s\\S]*^##\\s+Deviations",
+            "flags": "im",
+            "label": "change-notes sections in order"
+          },
+          {
+            "kind": "citationsResolve",
+            "file": "tasks/eval/change-notes.md",
+            "minCitations": 2,
+            "artifact": true
+          }
+        ]
+      },
+      {
+        "path": "tasks/eval/verification.md",
+        "kind": "markdown-notes",
+        "artifact": true,
+        "minBytes": 500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/verification.md",
+            "pattern": "^##\\s+Old shape check[\\s\\S]*^##\\s+Data integrity[\\s\\S]*^##\\s+Suite[\\s\\S]*^##\\s+Result",
+            "flags": "im",
+            "label": "verification sections in order"
+          }
+        ]
+      },
+      {
+        "path": "tasks/eval/review.md",
+        "kind": "markdown-report",
+        "artifact": true,
+        "minBytes": 400,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "tasks/eval/review.md",
+            "pattern": "Verdict:\\s*(?:PASS|REVISE)",
+            "flags": "i",
+            "label": "explicit reviewer verdict"
+          }
+        ]
+      }
+    ],
+    "checks": [
+      {
+        "kind": "notContains",
+        "file": "data/users.json",
+        "pattern": "\"name\"\\s*:",
+        "label": "the flat name field is gone from the data"
+      },
+      {
+        "kind": "notContains",
+        "file": "src/users.js",
+        "pattern": "\\.name\\b|\\[[\"']name[\"']\\]",
+        "label": "no flat-shape read remains in the accessors"
+      },
+      {
+        "kind": "sourceParses",
+        "file": "src/users.js"
+      },
+      {
+        "kind": "sniff",
+        "file": "data/users.json",
+        "sniff": "json-valid"
+      },
+      {
+        "kind": "nodeRuns",
+        "file": "tests/users.test.mjs"
+      },
+      {
+        "kind": "nodeScriptPasses",
+        "script": "tests/verify-migration.mjs",
+        "timeoutMs": 60000,
+        "requiredOutput": [
+          {
+            "pattern": "SCHEMAMIG_ORACLE data intact",
+            "label": "every record migrated with values intact"
+          },
+          {
+            "pattern": "SCHEMAMIG_ORACLE accessors migrated",
+            "label": "accessors read the new shape"
+          },
+          {
+            "pattern": "SCHEMAMIG_ORACLE contract complete",
+            "label": "the dual-read retired with the old shape"
+          },
+          {
+            "pattern": "SCHEMAMIG_ORACLE suite green",
+            "label": "suite green on the migrated tree"
+          }
+        ]
+      }
+    ],
+    "taskNotes": {
+      "minBytes": 120,
+      "checks": [
+        {
+          "kind": "contains",
+          "file": "task-notes.md",
+          "pattern": "\\bDONE\\b[\\s\\S]*(npm\\s+run\\s+test|node\\s+--test)",
+          "flags": "i",
+          "label": "DONE note names the real test command"
+        }
+      ]
+    },
+    "taskGraph": {
+      "requireCraftbookTask": true,
+      "requireTerminalStep": true
+    },
+    "unchangedFixtures": [
+      "source/migration-brief.md",
+      "package.json"
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "tasks/eval/change-notes.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "Expand/contract discipline",
+        "description": "The stages genuinely followed expand, migrate, contract in order - readers accepted both shapes while the data moved, and the old shape was dropped only after the transform completed with a green suite."
+      },
+      {
+        "name": "Data preservation",
+        "description": "The transform is real and lossless: every record reached the target shape with names and emails surviving exactly, proven by counts and spot-checks rather than asserted."
+      },
+      {
+        "name": "Honest verification",
+        "description": "Verification searched for leftover old-shape reads, quoted what it found, ran the real suite, and labeled anything unrun as unverified instead of claiming it."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "expand/contract data safety",
+    "no record stranded",
+    "real-site accessor changes"
+  ]
+}

package/data/craftbook-templates/sc/scrape-to-structured/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "scrape-to-structured",
   "role": "general",
+  "category": "code-data",
   "name": "Scrape a Site to Structured Data",
   "description": "Turn one or more web pages into a clean, structured dataset (JSON or CSV) with a fixed schema — product listings, directory entries, articles, tables, or job posts. Scopes the exact fields and a sample-row target FIRST so extraction is verifiable, then crawls and parses each page into rows, then validates that every row matches the schema, types are coerced, required fields are non-empty, and there are no duplicates. The scope-before-scrape ordering is the point: a small model that locks the field list and one hand-written sample row extracts consistently instead of inventing keys per page.",
   "tags": [

package/data/craftbook-templates/sc/script-automation/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "script-automation",
   "role": "general",
+  "category": "code-build",
   "name": "One-Off Automation Script",
   "description": "Write a one-off automation script that reliably does a repetitive task — process files, call an API, transform data — with arguments, a dry-run, idempotency, and clear logging so it is safe to run. Scopes the task FIRST — inputs/outputs, side-effects, the dry-run, idempotency, and failure handling — then implements the runnable script with args and a dry-run mode, then a reviewer confirms it does the job, is safe to re-run, and fails loudly. Covers argument handling, dry-run/preview mode, idempotent side-effects, progress logging, error handling, and safe-to-rerun automation.",
   "tags": [

package/data/craftbook-templates/sd/sdk-wrapper/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "sdk-wrapper",
   "role": "project-starter",
+  "category": "code-data",
   "name": "Typed SDK Wrapper for an External API",
   "description": "Wrap a third-party HTTP API as a clean, typed client library — studying the real API surface first so the wrapper matches reality, not guesses. Studies the API FIRST — endpoints, auth, request/response shapes, rate limits, error formats, and pagination from the actual docs — then builds a typed client with sensible methods and error handling, then tests each method against a mocked API including auth and error paths. Covers reading API docs, typed request/response models, auth handling, retry/rate-limit awareness, pagination helpers, error mapping, and a mockable client.",
   "tags": [

package/data/craftbook-templates/se/seasonal-maintenance-sweep/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "seasonal-maintenance-sweep",
   "role": "maintenance-review",
+  "category": "personal",
   "name": "Seasonal Maintenance Sweep",
   "description": "Run a season's home-care sweep against the project's systems roster: work out what care is due or overdue from each system's interval, plan the walkthrough in a sensible order with supplies, then log the completed care and flag what needs a professional — leaving the roster's due-tracking reset and a short sweep report. Locks the season's scope and the due list FIRST, then plans, then logs — so seasonal care becomes a checklist ritual instead of a vague worry. Use for spring/fall home maintenance, seasonal checkups, 'what does the house need', and pre-winter prep.",
   "tags": [

package/data/craftbook-templates/se/security-architecture-review/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "security-architecture-review",
   "role": "maintenance-review",
+  "category": "code-review",
   "name": "Security Architecture Review",
   "description": "A structured security architecture review: walk the stack for secrets, dependencies, auth, and common vulnerability classes, then report findings ranked by severity and confidence.",
   "tags": [

package/data/craftbook-templates/se/seo-meta-pack/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "seo-meta-pack",
   "role": "general",
+  "category": "marketing",
   "name": "SEO Metadata Pack",
   "description": "Generate a complete on-page SEO metadata pack for a set of pages: it first scopes each page's primary keyword and search intent and the length/format rules (title tag, meta description, Open Graph, Twitter card, slug), then writes optimized, unique metadata for every page that respects pixel/character limits and front-loads the keyword, producing a structured JSON file ready to drop into a CMS or templating layer. Covers SEO metadata, meta tags, title tags, meta descriptions, Open Graph tags, social cards, and on-page SEO. Scoping the keyword and limits per page before writing is the point: a small model that fixes the rules first produces unique, limit-respecting tags across the whole set, instead of duplicate titles and descriptions that get truncated in the SERP.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "ship",
   "role": "general",
+  "category": "code-release",
   "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": [

package/data/craftbook-templates/so/social-digest/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "social-digest",
   "role": "maintenance-review",
+  "category": "marketing",
   "name": "Social Digest",
   "description": "The overnight read of your social feeds. Scans the synced Bluesky, X, and Instagram corpus records since the last look plus your own post index, then leaves a morning digest: what happened on each feed, notable mentions and replies with the people who wrote them, which posts moved on likes, reposts, and replies, and suggested next moves — each carrying a one-click action to draft the follow-up post or a reply task. Covers social media monitoring, engagement tracking, mention triage, and a nightly social summary grounded entirely in real synced records. No connected feed? It still runs, reports what the workspace knows, and names the gap instead of inventing activity.",
   "tags": [

package/data/craftbook-templates/so/social-thread/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "social-thread",
   "role": "general",
+  "category": "marketing",
   "name": "Social Media Thread",
   "description": "Write a multi-post social thread (X/Twitter, LinkedIn, Threads) that hooks, delivers, and converts: it first locks the single angle/big idea, the platform and its character limits, the target reader, and the CTA, then drafts the thread as numbered posts with a scroll-stopping hook, one idea per post, and a clear close. Covers Twitter thread, LinkedIn carousel copy, viral thread, social content, thought-leadership posts, and engagement hooks. Locking one angle and the hook before writing is the point: a small model that commits to a single big idea avoids the meandering thread that tries to say five things and stops no scroll.",
   "tags": [

package/data/craftbook-templates/so/source-quality-audit/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "source-quality-audit",
   "role": "maintenance-review",
+  "category": "research",
   "name": "Source Quality Audit",
   "description": "Once a month, make the reading list earn its place: score each source on what it actually delivered — accuracy, originality, noise — and keep, demote, or drop with evidence, so the brief stays sharp as the feeds drift. Locks the audit criteria FIRST, then builds the per-source scorecard from the month's briefs, then writes the verdict table with the changes to make. Use for source audits, pruning the feed list, 'the brief feels noisy', monthly reading-list reviews, and deciding which feeds to drop.",
   "tags": [

package/data/craftbook-templates/sp/spa-dashboard/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "spa-dashboard",
   "role": "project-starter",
+  "category": "code-build",
   "name": "Metrics / Admin Dashboard",
   "description": "Build a single-page metrics or admin dashboard with KPI summary cards, at least one chart, and a data table, rendered from sample or provided data. Locks the data model and which metrics matter first, then a scannable dashboard layout (grid of cards, chart placement, table), then builds the interactive HTML with a lightweight charting approach and a sortable/filterable table. Deciding the metrics and layout before coding prevents a small model from dumping raw data with no hierarchy; a dashboard's value is the at-a-glance summary up top.",
   "tags": [

package/data/craftbook-templates/sp/spec-authoring/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "spec-authoring",
   "role": "general",
+  "category": "code-docs",
   "name": "Spec Authoring",
   "description": "Turn a rough intent into a backlog-ready spec: interrogate scope and requirements against the real code, then file a well-formed, unambiguous issue.",
   "tags": [

package/data/craftbook-templates/sp/spec-doc/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "spec-doc",
   "role": "general",
+  "category": "code-docs",
   "name": "Technical Design Doc",
   "description": "Write a technical design document (RFC / engineering design doc) that gets a system change reviewed and approved — covering context and problem, goals and non-goals, the proposed design, alternatives considered, trade-offs, risks, and a rollout plan. Scopes the problem, goals, and explicit non-goals FIRST (non-goals prevent reviewer scope-creep), writes the detailed design with diagrams and alternatives, then has a reviewer check it for completeness and unjustified decisions. Use for RFCs, architecture proposals, and pre-implementation design reviews.",
   "tags": [

package/data/craftbook-templates/sp/spreadsheet-model/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "spreadsheet-model",
   "role": "general",
+  "category": "business",
   "name": "Spreadsheet / Financial Model",
   "description": "Build a working spreadsheet-style model (budget, forecast, unit economics, pricing, or scenario calculator) with clearly separated inputs, calculations, and outputs. Scopes the model's purpose, drivers, and assumptions FIRST so the formulas have a contract, then builds the model with live formulas and labeled assumption cells, then verifies the math by hand-checking key outputs and a sanity scenario. Use this for a financial model, budget calculator, ROI/forecast spreadsheet, unit-economics model, or any input-driven calculator.",
   "tags": [

package/data/craftbook-templates/sp/sprite-sheet/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "sprite-sheet",
   "role": "general",
+  "category": "media",
   "name": "Game Sprite Sheet",
   "description": "Produce a game-ready sprite sheet — a character or object with its animation frames (idle, walk, jump, attack) on a uniform grid — plus the frame metadata (JSON atlas) a game engine needs to slice it. Lock the style and the frame inventory FIRST (cell size, pivot, palette, which animations and how many frames each) because a sprite sheet is only usable if every cell is the same size and the pivot is consistent; then generate the frames and pack them into a sheet with a matching atlas. Covers sprite sheets, game art, animation frames, texture atlases, pixel-art characters, and 2D game assets.",
   "tags": [

package/data/craftbook-templates/sq/sql-analysis/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "sql-analysis",
   "role": "general",
+  "category": "code-data",
   "name": "Answer a Question with SQL",
   "description": "Answer a specific business question against a database or table set with a correct, readable SQL query and a short written answer. Scopes the question, the tables/columns, and the grain FIRST (so the query measures the right thing at the right level), then writes and runs the query as a data-analyst, then verifies the result with a sanity check and an explanation. Use this for SQL analysis, querying a database, writing a report query, computing a metric in SQL, or answering 'how many / what's the trend' from tables.",
   "tags": [

package/data/craftbook-templates/st/standup-summary/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "standup-summary",
   "role": "general",
+  "category": "business",
   "name": "Standup / Team Update Summary",
   "description": "Condense a pile of raw team updates (standup messages, async check-ins, channel dumps) into one clean summary grouped by person or workstream, surfacing blockers and decisions. Scopes the grouping axis and summary shape FIRST (by-person vs by-project, what counts as a blocker, the yesterday/today/blockers frame), then a copywriter compresses every raw update into that frame without dropping anyone. The scope-first step prevents a 4B model from rambling and guarantees blockers get their own callout section instead of being buried. Use for daily standup summaries, async update rollups, team check-in digests, and turning Slack threads into a readable recap.",
   "tags": [

package/data/craftbook-templates/st/state-machine/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "state-machine",
   "role": "project-starter",
+  "category": "code-data",
   "name": "Model a Flow as a State Machine",
   "description": "Model a stateful flow (checkout, order lifecycle, connection, wizard) as an explicit finite state machine with named states, guarded transitions, and rejected illegal moves — making impossible states impossible. Models the machine FIRST — the full state set, the events, the legal transition table, guards, and entry/exit effects — then implements a transition function that rejects illegal events, then tests every legal path and that illegal transitions are refused. Covers states/events/transitions, transition tables, guards, side-effects on entry, illegal-transition rejection, and exhaustive path testing.",
   "tags": [

package/data/craftbook-templates/st/status-report/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "status-report",
   "role": "general",
+  "category": "business",
   "name": "Recurring Status Report",
   "description": "Produce a recurring (weekly/biweekly) status report by gathering signals from the team's tools and writing a tight, skimmable update for stakeholders. Scopes the report template and the exact data sources FIRST (sections, audience, reporting window, RAG/health convention), then a developer gathers the raw signals from issue trackers, PRs, metrics, and notes into a facts file, then a copywriter writes the polished report strictly from those gathered facts. Scoping the template before gathering is what keeps every recurring issue consistent and prevents the model from padding with prose. Use for weekly status updates, sprint reports, project health reports, stakeholder updates, and exec summaries.",
   "tags": [

package/data/craftbook-templates/su/subscription-audit/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "subscription-audit",
   "role": "maintenance-review",
+  "category": "business",
   "name": "Audit Recurring Subscriptions",
   "description": "Audit a set of transactions or a vendor list to find every recurring subscription, normalize each to a monthly cost, surface duplicates, price hikes, and zombie/unused services, and produce a prioritized cancel/keep recommendation report. Locks the recurrence-detection rule, the normalization (to monthly), and the recommendation criteria FIRST, then detects and analyzes the recurring charges, then writes a clear report whose every recommendation is backed by the evidence in the data. Defining what counts as 'recurring' and how to rank cancel candidates before analyzing is what makes the audit actionable rather than a list of guesses.",
   "tags": [

package/data/craftbook-templates/su/subtitle-generator/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "subtitle-generator",
   "role": "general",
+  "category": "media",
   "name": "Subtitle & Caption Generator",
   "description": "Generate time-synced subtitles/captions for a video in a standard caption format (SRT or WebVTT), so the video is accessible and watchable without sound. Scopes the caption format and timing/reading-speed rules FIRST, transcribes the audio with precise word timings, then formats those into properly cued, line-length-limited caption cues. The transcribe-then-format split is deliberate: getting accurate text and timings is a different skill from chunking them into readable, on-screen-friendly cues that respect reading speed and never overlap.",
   "tags": [

package/data/craftbook-templates/su/summarize-long/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "summarize-long",
   "role": "general",
+  "category": "writing",
   "name": "Summarize a Long Document",
   "description": "Distill a long document into a faithful, well-structured summary at a chosen depth: it first scopes the audience, the target length and format (TL;DR line, executive summary, or bulleted key points), and what the reader must take away, then writes the summary capturing every major point and decision in proportion, with nothing invented and nothing critical dropped. Covers summarize, TL;DR, executive summary, condense a document, key takeaways, and abstract writing. Scoping audience and depth before summarizing is the point: a small model that knows who it is for and how long it should be avoids both the bloated near-copy and the lossy summary that omits the document's actual conclusion.",
   "tags": [

package/data/craftbook-templates/su/survey-analysis/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "survey-analysis",
   "role": "general",
+  "category": "research",
   "name": "Survey Analysis",
   "description": "Analyze survey responses into a clear summary of what respondents actually said, across both quantitative (rating/multiple-choice) and open-text questions. Scopes the questions, response types, and segments FIRST, then analyzes — tallying closed questions and theming open-text comments as a data-analyst, then writes a findings summary with the headline results, segment differences, and representative quotes. Use this for analyzing survey results, summarizing a questionnaire, NPS/feedback analysis, theming open-ended responses, or a survey readout.",
   "tags": [

package/data/craftbook-templates/sv/svg-animation/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "svg-animation",
   "role": "project-starter",
+  "category": "code-build",
   "name": "Animated SVG / CSS Hero",
   "description": "Build a single-file animated SVG or CSS hero section — a looping illustrated scene, an animated logo, or a motion banner driven by CSS keyframes or SMIL with no JavaScript animation library. Storyboards the motion (what moves, the timing, easing, and loop) first, then implements clean, performant, GPU-friendly animation. Motion looks amateur when timing and easing are unconsidered, so the motion-design phase locks the keyframe storyboard and respects prefers-reduced-motion before any markup, the ordering that yields a polished, smooth hero instead of janky tweens.",
   "tags": [

package/data/craftbook-templates/ta/tailor-resume/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "tailor-resume",
   "role": "general",
+  "category": "business",
   "name": "Tailor Résumé to a Posting",
   "description": "Adapt an EXISTING résumé to a specific job posting — a fit map of must-hit requirements first, then a tailored variant that re-orders and re-words real experience without inventing any. Distinct from building a résumé from scratch (see Résumé / CV): this book starts from a base résumé plus a posting and produces the targeted variant along with honest gap notes for the cover letter and interview. Use per serious application in a job search.",
   "tags": [

package/data/craftbook-templates/te/technical-documentation/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "technical-documentation",
   "role": "general",
+  "category": "code-docs",
   "name": "Technical Documentation",
   "description": "Generate a coherent documentation set from a codebase, organized by the Diataxis model (tutorials, how-to guides, reference, explanation), with cross-links and a coverage pass.",
   "tags": [

package/data/craftbook-templates/te/test-coverage-review/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "test-coverage-review",
   "role": "maintenance-review",
+  "category": "code-quality",
   "name": "Test Coverage Review",
   "description": "Review a codebase or module's test suite for real coverage and quality, then produce a gap report and a prioritized backlog of tests to add. First scopes the units under review and locks a coverage standard distinguishing line coverage from behavioral coverage (critical paths, branches, edge cases, error handling, and regression protection), then audits the existing tests for what they actually assert and which behaviors and branches are untested or weakly tested, then writes a report ranking the highest-value missing or low-quality tests with a concrete description of each. Use this for a test coverage review, finding test gaps, auditing test quality, deciding what to test next, or assessing whether a module is well-tested — it distinguishes meaningful behavioral coverage from a green coverage number and returns a prioritized testing backlog rather than 'add more tests'.",
   "tags": [