@bendyline/gilde 0.1.95 → 0.2.0

package/data/craftbook-templates/ju/juice-pass/manifest.json

@@ -4,6 +4,10 @@
   "id": "juice-pass",
   "role": "general",
   "category": "code-build",
+  "interests": [
+    "software",
+    "play"
+  ],
   "name": "Juice Pass",
   "description": "Make the game feel alive without breaking it: feedback on every player action — hit-flash, screenshake, sound hooks, particles, score pops — added with restraint and verified playable after every change. Locks the juice checklist FIRST — every player action gets visible feedback, effects stay tasteful, nothing regresses — then edits the game in place, re-checking that it still runs and still ends. Use for 'the game feels dead', game feel passes, adding screenshake and particles, polishing an arcade game, and making hits feel like hits.",
   "tags": [

package/data/craftbook-templates/kp/kpi-scorecard/manifest.json

@@ -4,6 +4,10 @@
   "id": "kpi-scorecard",
   "role": "general",
   "category": "business",
+  "interests": [
+    "data",
+    "work"
+  ],
   "name": "KPI Scorecard Page",
   "description": "Build a single-page KPI scorecard that rolls a dataset up into the handful of numbers a team tracks, each shown with its current value, target, and period-over-period change. Defines the KPIs and their exact formulas and targets FIRST (so a number is never ambiguous), then computes the rollups, then builds a clean self-contained HTML scorecard with KPI tiles, deltas, and a tiny trend sparkline each. Use this for a KPI dashboard, a metrics scorecard, an executive summary page, a North Star metrics view, or rolling raw data into headline numbers.",
   "tags": [

package/data/craftbook-templates/la/landing-page/manifest.json

@@ -4,6 +4,10 @@
   "id": "landing-page",
   "role": "project-starter",
   "category": "code-build",
+  "interests": [
+    "software",
+    "business"
+  ],
   "name": "Landing Page",
   "description": "Build a single high-conversion landing page for one offer — a product, signup, waitlist, or download — with a focused hero, benefits, social proof, and one primary call to action above and below the fold. Locks the offer, audience, and single CTA first, then a conversion-oriented visual design, then the persuasive copy, then builds responsive HTML with real CSS. The scope-then-design-then-copy ordering keeps the page ruthlessly focused on one conversion goal instead of becoming a sprawling site.",
   "tags": [

package/data/craftbook-templates/le/lead-enrichment/manifest.json

@@ -4,6 +4,10 @@
   "id": "lead-enrichment",
   "role": "general",
   "category": "marketing",
+  "interests": [
+    "business",
+    "data"
+  ],
   "name": "Enrich a Leads List",
   "description": "Take a raw leads or contacts list and enrich each row with derived and looked-up attributes — company domain, industry, size band, role seniority, normalized location, and a quality/score flag — into a clean CRM-ready file. Scopes the enrichment fields, their sources, and the dedup/normalization rules FIRST, then enriches each lead row-by-row, then verifies coverage, that nothing was fabricated when a source had no data, and that duplicates are merged. Defining 'what each field means and where it comes from' before enriching is what stops a small model from inventing plausible-but-false company data.",
   "tags": [

package/data/craftbook-templates/li/literature-review/manifest.json

@@ -4,6 +4,10 @@
   "id": "literature-review",
   "role": "general",
   "category": "research",
+  "interests": [
+    "learning",
+    "work"
+  ],
   "name": "Literature Review",
   "description": "Survey the existing literature on a topic and synthesize it into a structured review: a planner sets the scope, inclusion criteria, and the themes to organize around, then a researcher gathers and characterizes each source (method, finding, quality), then a copywriter synthesizes them thematically rather than source-by-source, surfacing consensus, disagreement, and gaps. The ordering matters because a review written without inclusion criteria becomes an arbitrary pile, and one written source-by-source reads like a list of summaries instead of a synthesis; locking themes and a source matrix first forces the comparative analysis that makes a real lit review. Use this for academic-style literature surveys, state-of-the-art reviews, 'what does the research say' questions, and synthesizing a body of papers or articles.",
   "tags": [

package/data/craftbook-templates/lo/logo-set/manifest.json

@@ -4,6 +4,10 @@
   "id": "logo-set",
   "role": "general",
   "category": "design",
+  "interests": [
+    "content",
+    "business"
+  ],
   "name": "Logo & Variant Set",
   "description": "Generate a coherent logo and the full set of variants a real brand needs — primary mark, horizontal lockup, stacked lockup, icon-only/favicon, plus light-on-dark and monochrome versions — from a written brief. Lock the brief (concept, geometry, palette, typography, do/don'ts) BEFORE generating pixels so every variant shares one visual DNA instead of looking like five unrelated logos; then assemble them into a delivered folder with a contact sheet. Covers logo design, brand mark, wordmark, logo variations, and brand-asset packs.",
   "tags": [

package/data/craftbook-templates/ma/market-scan/manifest.json

@@ -4,6 +4,10 @@
   "id": "market-scan",
   "role": "general",
   "category": "research",
+  "interests": [
+    "work",
+    "business"
+  ],
   "name": "Market & Landscape Scan",
   "description": "Survey a market or landscape and write a scan that sizes it, maps the players, and surfaces trends: a planner scopes the market boundary and the lenses (size, segments, players, trends, drivers, risks), a researcher gathers sized figures and landscape facts with sources, and a copywriter writes a structured landscape report. The ordering matters because a scan without a defined boundary mixes adjacent markets and inflates numbers, and one without locked lenses skips the dimensions a decision-maker needs; fixing boundary and lenses first keeps the scan focused and comparable. Use this for market landscape scans, industry overviews, TAM/segmentation reads, trend analyses, and 'give me the lay of the land in X' requests.",
   "tags": [

package/data/craftbook-templates/me/meeting-minutes/manifest.json

@@ -4,6 +4,9 @@
   "id": "meeting-minutes",
   "role": "general",
   "category": "business",
+  "interests": [
+    "work"
+  ],
   "name": "Meeting Minutes & Actions",
   "description": "Turn a meeting transcript, recording notes, or rough scratch into clean, distributable meeting minutes — attendees, agenda topics discussed, decisions made, and (most importantly) action items with owners and due dates. Scopes the minutes structure and what counts as a decision vs an action FIRST, then writes accurate, neutral minutes where every decision is recorded and every action has an owner and a date — the action table is the part people actually use. Use for board/team meeting minutes, project status meetings, and decision logs.",
   "tags": [

package/data/craftbook-templates/me/meeting-notes-to-actions/manifest.json

@@ -4,6 +4,9 @@
   "id": "meeting-notes-to-actions",
   "role": "general",
   "category": "business",
+  "interests": [
+    "work"
+  ],
   "name": "Meeting Notes to Action Items",
   "description": "Convert raw meeting notes or a transcript into a clean, assigned action-item list with owners, due dates, and the decisions that drove them. Extracts the actions and decisions FIRST (every commitment, ask, and decision lifted verbatim-ish into a structured list with source quotes), then a planner assigns owners and due dates and prioritizes — separating extraction from assignment so nothing said in the meeting is lost before triage. The extract-then-assign ordering is what stops a small model from silently dropping commitments or inventing owners. Use for meeting follow-ups, action-item extraction, turning transcripts into to-dos, decision logs, and post-meeting recaps.",
   "tags": [

package/data/craftbook-templates/me/meeting-notes-to-actions/versions/1.1.2/craftbook.json

@@ -0,0 +1,255 @@
+{
+  "id": "meeting-notes-to-actions",
+  "name": "Meeting Notes to Action Items",
+  "description": "Convert raw meeting notes or a transcript into a clean, assigned action-item list with owners, due dates, and the decisions that drove them. Extracts the actions and decisions FIRST (every commitment, ask, and decision lifted verbatim-ish into a structured list with source quotes), then a planner assigns owners and due dates and prioritizes — separating extraction from assignment so nothing said in the meeting is lost before triage. The extract-then-assign ordering is what stops a small model from silently dropping commitments or inventing owners. Use for meeting follow-ups, action-item extraction, turning transcripts into to-dos, decision logs, and post-meeting recaps.\n\nIt works on the meeting notes or transcript you choose when you launch it: a file in this project, or one you pick from your computer.\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. Extract actions & decisions (developer) — lift every commitment, ask, and decision with source quotes → gated on artifact `{{workPath}}/extract.md` (markdown-notes)\n2. Assign & prioritize (planner) — set owners, due dates, and priority into the final list → gated on `actions.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "extract",
+  "triggers": [
+    "meeting notes to action items",
+    "extract action items",
+    "meeting follow-up",
+    "turn transcript into tasks",
+    "post-meeting recap"
+  ],
+  "samples": [
+    {
+      "id": "team-sync",
+      "title": "a team meeting's notes",
+      "param": "source",
+      "files": [
+        "samples/team-sync/notes.md"
+      ]
+    }
+  ],
+  "paramSchema": {
+    "type": "object",
+    "required": [
+      "source"
+    ],
+    "properties": {
+      "source": {
+        "type": "string",
+        "title": "Meeting notes or transcript",
+        "description": "The raw notes or transcript to pull actions from. A file in this project, or one you pick from your computer.",
+        "input": {
+          "kind": "file",
+          "accept": [
+            ".md",
+            ".markdown",
+            ".txt",
+            ".html",
+            ".htm",
+            ".docx",
+            ".pdf",
+            ".vtt",
+            ".srt"
+          ]
+        }
+      },
+      "workPath": {
+        "type": "string",
+        "title": "Working folder",
+        "description": "Per-task working folder in the artifacts drawer. Defaults to this task's own folder so runs never collide; override with a stable name when you deliberately want runs to share files.",
+        "default": "{{task.dir}}"
+      }
+    }
+  },
+  "steps": [
+    {
+      "id": "extract",
+      "name": "Extract actions & decisions",
+      "description": "lift every commitment, ask, and decision with source quotes",
+      "prompt": "Read the meeting notes or transcript (the `source` input) end to end and extract — do not yet assign or prioritize. (1) Pull EVERY action item: anything phrased as a commitment, follow-up, ask, or 'someone should…'. For each, capture the action verbatim-ish, any owner/date mentioned, and the source quote it came from. (2) Pull every DECISION (a choice the group landed on) and every OPEN QUESTION left unresolved, each with its source quote. (3) Lock the output schema for the next phase: action | owner | due | priority | source-quote. Be exhaustive — recall matters more than precision here; a borderline item is kept, not dropped. Write an acceptance-criteria checklist ('every commitment in the notes is captured', 'each action cites a source quote', 'decisions and open questions separated from actions', 'no owner/date invented beyond what the notes state') plus the raw extracted lists to {{workPath}}/extract.md via write_task_note AND the produces path.\n\nThe deliverable `{{workPath}}/extract.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": "developer",
+      "toolPolicy": {
+        "disallowBuiltinToolsets": [
+          "ai-apps",
+          "archives",
+          "audio",
+          "browser-automation",
+          "code-execution",
+          "craftbooks",
+          "data-tables",
+          "entity-intel",
+          "git",
+          "image-intel",
+          "images",
+          "role-delegation",
+          "role-delegation-escalation",
+          "security-intel",
+          "team-management",
+          "videos",
+          "web",
+          "workspace-fs-write"
+        ],
+        "outputMedium": "artifact",
+        "additionalOutputMedia": [
+          "task-note"
+        ]
+      },
+      "advanceWhen": {
+        "file": "{{workPath}}/extract.md",
+        "minBytes": 1,
+        "sniff": "nonempty",
+        "artifact": true
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "{{workPath}}/extract.md",
+            "bytes": 120,
+            "artifact": true
+          },
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/extract.md",
+            "sniff": "nonempty",
+            "artifact": true
+          }
+        ],
+        "onReject": "extract",
+        "maxAttempts": 3
+      },
+      "next": "assign"
+    },
+    {
+      "id": "assign",
+      "name": "Assign & prioritize",
+      "description": "set owners, due dates, and priority into the final list",
+      "prompt": "First open `{{workPath}}/extract.md` with `read_artifact`: it is the earlier work this step builds on. Turn the extracted items into actions.md, the deliverable. (1) Render a table: Action | Owner | Due | Priority | Source. (2) Assign the owner stated in the notes; where the notes name no owner, write 'UNASSIGNED — [proposed: name]' rather than guessing silently. (3) Set due dates from the notes; where none exists, leave 'TBD' (do not fabricate dates). (4) Assign priority (P1/P2/P3) using a stated, simple rule (P1 = explicit deadline or blocker, else P2, nice-to-haves P3) and note the rule at the top. (5) Below the table add a Decisions section and an Open questions section from the extraction. Every extracted action must appear — none dropped in triage. On a loop-back fix only the flagged rows. Write the path and a count (actions, unassigned, decisions) to notes via write_task_note.",
+      "suggestedRole": "planner",
+      "toolPolicy": {
+        "disallowBuiltinToolsets": [
+          "ai-apps",
+          "archives",
+          "audio",
+          "browser-automation",
+          "code-execution",
+          "craftbooks",
+          "data-tables",
+          "entity-intel",
+          "git",
+          "image-intel",
+          "images",
+          "role-delegation",
+          "role-delegation-escalation",
+          "security-intel",
+          "team-management",
+          "videos",
+          "web"
+        ],
+        "outputMedium": "workspace",
+        "additionalOutputMedia": [
+          "task-note"
+        ]
+      },
+      "consumes": [
+        {
+          "file": "{{workPath}}/extract.md",
+          "artifact": true
+        }
+      ],
+      "advanceWhen": {
+        "file": "actions.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "actions.md",
+            "bytes": 500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkContains",
+            "scope": "standard",
+            "inputs": {
+              "file": "actions.md",
+              "pattern": "(?:^|\\n)#{1,3}\\s+\\S",
+              "flags": "i"
+            }
+          }
+        ],
+        "onReject": "assign",
+        "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 actions.md against the locked criteria. (1) Cross-check every action in {{workPath}}/extract.md against the final table — all present? FAIL on any dropped commitment. (2) Confirm each row has a source reference and that no owner or due date was invented beyond what the notes state (unstated owners marked UNASSIGNED, unstated dates TBD). (3) Confirm Decisions and Open-questions sections exist and match the extraction. (4) Confirm the priority rule is stated and applied consistently on 2-3 rows. (5) Re-scan the original notes for any commitment the extraction missed. Write PASS/FAIL per criterion with the specific items.\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: \"assign\" })` 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",
+      "toolPolicy": {
+        "disallowBuiltinToolsets": [
+          "ai-apps",
+          "archives",
+          "audio",
+          "browser-automation",
+          "code-execution",
+          "craftbooks",
+          "data-tables",
+          "entity-intel",
+          "git",
+          "image-intel",
+          "images",
+          "role-delegation",
+          "role-delegation-escalation",
+          "security-intel",
+          "team-management",
+          "videos",
+          "web",
+          "workspace-fs-write"
+        ],
+        "outputMedium": "task-note"
+      },
+      "consumes": [
+        {
+          "file": "actions.md"
+        }
+      ],
+      "next": "assign"
+    },
+    {
+      "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",
+      "toolPolicy": {
+        "disallowBuiltinToolsets": [
+          "ai-apps",
+          "archives",
+          "artifacts",
+          "audio",
+          "browser-automation",
+          "code-execution",
+          "craftbooks",
+          "data-tables",
+          "entity-intel",
+          "git",
+          "image-intel",
+          "images",
+          "role-delegation",
+          "role-delegation-escalation",
+          "security-intel",
+          "team-management",
+          "videos",
+          "web",
+          "workspace-fs-write"
+        ],
+        "outputMedium": "task-note"
+      },
+      "terminal": true
+    }
+  ],
+  "version": "1.1.2",
+  "releasedAt": "2026-10-12T00:00:00Z",
+  "minGezelVersion": "1.26285"
+}

package/data/craftbook-templates/me/meeting-notes-to-actions/versions/1.1.2/samples/team-sync/notes.md

@@ -0,0 +1,47 @@
+# Weekly sync: Fernhill Studio app team
+
+Date: Tuesday 14 October 2025
+Present: Priya Raman (lead), Tomasz Wilk, Ama Mensah, Jonas Becker, Lea Fontaine
+Notes: Ama
+
+## Release 2.4
+
+- The 2.4 build is feature-complete. Tomasz says the photo picker crash is
+  fixed but wants one more day of testing on older Android phones.
+- Decision: we ship 2.4 to the app stores on Thursday 23 October, not this week.
+- Tomasz will finish the Android regression pass by Friday 17 October.
+- Lea will write the release notes once the build is final.
+- The store screenshots still show the old home screen. Someone needs to
+  update them before the release; nobody picked it up.
+
+## Onboarding redesign
+
+- Jonas showed the new three-screen welcome flow. Everyone liked the shorter
+  sign-up, but the skip button is still hard to see.
+- Jonas will make the skip button more visible and share a new mockup by
+  Monday 20 October.
+- Decision: we drop the welcome video from onboarding. It was slow to load
+  and most people skipped it anyway.
+- Ama will ask support which questions new users ask most in their first week.
+- Open question: do we keep email sign-up at all, or only offer Apple and
+  Google sign-in? Priya wants numbers before anyone decides.
+
+## Support and feedback
+
+- Support tickets are up 18% since 2.3, mostly about the sync delay.
+- Priya will draft a short status-page note about the sync delay this week.
+- Ama to collect the ten most common ticket phrases for the FAQ.
+- We should look at running the sync job every five minutes instead of every
+  fifteen. Tomasz thinks the server can take it; not decided who checks.
+
+## Hiring
+
+- Decision: we open the junior designer role in November, not October.
+- Priya will send the job description to Lea for a read-through by
+  31 October.
+- Open question: is there budget for a contractor to cover December?
+
+## Next sync
+
+Tuesday 21 October, same time. Jonas runs it and will send the agenda the day
+before.

package/data/craftbook-templates/me/meeting-notes-to-actions/versions/1.1.2/test.json

@@ -0,0 +1,78 @@
+{
+  "schemaVersion": 1,
+  "mode": "workflow",
+  "title": "Meeting Notes to Action Items workflow processability",
+  "objective": "Prove that a medium local model can parse and execute the Meeting Notes to Action Items craftbook, satisfy its declared runtime gates, and reach a terminal step using only local fixtures.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "Use the `meeting-notes-to-actions` (Meeting Notes to Action Items) craftbook for this self-contained local evaluation. Open `source/craftbook-eval-brief.md` first, then follow the craftbook's actual steps and gates through its terminal step. Complete this request: Convert raw meeting notes or a transcript into a clean, assigned action-item list with owners, due dates, and the decisions that drove them. Extracts the actions and decisions FIRST (every commitment, ask, and decision lifted verbatim-ish into a structured list with source quotes), then a planner assigns owners and due dates and prioritizes — separating extraction from assignment so nothing said in the meeting is lost before triage. The extract-then-assign ordering is what stops a small model from silently dropping commitments or inventing owners. Use for meeting follow-ups, action-item extraction, turning transcripts into to-dos, decision logs, and post-meeting recaps.\n\nIt works on the meeting notes or transcript you choose when you launch it: a file in this project, or one you pick from your computer.\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. Extract actions & decisions (developer) — lift every commitment, ask, and decision with source quotes → gated on artifact `{{workPath}}/extract.md` (markdown-notes)\n2. Assign & prioritize (planner) — set owners, due dates, and priority into the final list → gated on `actions.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n Produce `extract.md` in this task's artifact working folder, `actions.md`. Use only seeded project files and installed local simulators. Do not call a real external service, fetch live data, or claim an external side effect occurred; an explicit dry-run record is the correct result when a dependency is unavailable.",
+  "setup": {
+    "projectName": "Meeting Notes to Action Items Workflow Eval",
+    "about": "A hermetic workflow evaluation for the Meeting Notes to Action Items craftbook. No live dependency or external network is authorized.",
+    "missionObjectives": "Run the Meeting Notes to Action Items craftbook end to end, use the local evaluation brief and fixtures as truth, produce its declared outputs, and reach a terminal step without fabricating external effects.",
+    "managedWorkspaceWritePolicy": "allow",
+    "files": [
+      {
+        "path": "source/craftbook-eval-brief.md",
+        "content": "# Meeting Notes to Action Items — local evaluation brief\n\nThis is a hermetic processability evaluation of the `meeting-notes-to-actions` craftbook.\nDo not contact real services, use real credentials, or fetch live data. Treat\nthe project fixtures and installed local simulators as authoritative. If a\ndependency is intentionally unavailable, document an honest dry run instead\nof claiming a real side effect.\n\n## Request\n\nConvert raw meeting notes or a transcript into a clean, assigned action-item list with owners, due dates, and the decisions that drove them. Extracts the actions and decisions FIRST (every commitment, ask, and decision lifted verbatim-ish into a structured list with source quotes), then a planner assigns owners and due dates and prioritizes — separating extraction from assignment so nothing said in the meeting is lost before triage. The extract-then-assign ordering is what stops a small model from silently dropping commitments or inventing owners. Use for meeting follow-ups, action-item extraction, turning transcripts into to-dos, decision logs, and post-meeting recaps.\n\nIt works on the meeting notes or transcript you choose when you launch it: a file in this project, or one you pick from your computer.\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. Extract actions & decisions (developer) — lift every commitment, ask, and decision with source quotes → gated on artifact `{{workPath}}/extract.md` (markdown-notes)\n2. Assign & prioritize (planner) — set owners, due dates, and priority into the final list → gated on `actions.md` (markdown-doc)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n\n\n## Required workflow\n\n1. Extract actions & decisions\n2. Assign & prioritize\n3. Evaluate\n4. Finish (terminal)\n\n## Declared outputs\n\n- `extract.md` in this task's artifact working folder\n- `actions.md`\n"
+      },
+      {
+        "path": "source/brief.md",
+        "content": "# Meeting Notes to Action Items Eval Brief\n\nClient: Boreal Desk, a home-office accessories company.\nAudience: operations leads who need an artifact they can use this week.\n\nFixed source facts for grounding:\n- The returns desk pilot covered 18 SKUs.\n- Median first response improved from 18 hours to 6 hours.\n- Preventable refund leakage fell from 14.2% to 8.9%.\n- The top unresolved complaint is status silence after photo submission.\n- Required next actions are automated status emails, barcode-exception training, and a weekly Finance exception export.\n\nUse these facts when the task asks for prose, analysis, copy, UI content, or test data. Do not use live web services, real credentials, or current outside data.\n\nCraftbook under test: meeting-notes-to-actions - Meeting Notes to Action Items.\n"
+      }
+    ],
+    "craftbookParams": {
+      "source": "source/brief.md"
+    },
+    "worker": {
+      "name": "Craftbook Runner",
+      "role": "Workflow Operator",
+      "about": "Execute the assigned craftbook exactly. Read local fixtures, satisfy each runtime gate, record honest dry-run evidence for unavailable dependencies, and continue until a terminal step is active or the task is complete."
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "The attributed meeting-notes-to-actions task satisfied its own gates, produced its declared outputs, and reached a terminal step without using external services.",
+    "deliverables": [
+      {
+        "path": "{{task.dir}}/extract.md",
+        "kind": "markdown-report",
+        "artifact": true,
+        "minBytes": 120
+      },
+      {
+        "path": "actions.md",
+        "kind": "markdown-report",
+        "minBytes": 500
+      }
+    ],
+    "taskGraph": {
+      "requireCraftbookTask": true,
+      "requireTerminalStep": true
+    }
+  },
+  "rubric": {
+    "artifact": {
+      "path": "{{task.dir}}/extract.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "workflow fidelity",
+        "description": "The result reflects the named craftbook sequence and its declared acceptance gates rather than a freehand substitute."
+      },
+      {
+        "name": "usefulness",
+        "description": "The deliverable is coherent, actionable, and suitable for the craftbook purpose stated in the local brief."
+      }
+    ],
+    "contextNote": "Advisory only. Deterministic pass/fail comes from the craftbook runtime gates, deliverable existence, attribution, and terminal progress."
+  },
+  "qualityFocus": [
+    "real meeting-notes-to-actions craftbook task attribution",
+    "declared runtime gate satisfaction",
+    "terminal workflow progress",
+    "offline fixture and simulator discipline"
+  ]
+}

package/data/craftbook-templates/me/meeting-prep-brief/manifest.json

@@ -4,6 +4,9 @@
   "id": "meeting-prep-brief",
   "role": "general",
   "category": "business",
+  "interests": [
+    "work"
+  ],
   "name": "Meeting Prep Brief",
   "description": "Walk into the meeting already warm: who's in the room, what was promised last time, what you want out of this one, and the two questions worth asking — one page, read in the elevator. Locks the target meeting and the one-page criteria FIRST, then compiles from the calendar and the prior notes, so every claim in the brief traces to something real instead of memory. Use for meeting prep, 'prep me for the meeting', pre-meeting briefs, vendor and client syncs, and walking in warm.",
   "tags": [

package/data/craftbook-templates/me/meeting-summary-audio/manifest.json

@@ -4,6 +4,9 @@
   "id": "meeting-summary-audio",
   "role": "general",
   "category": "business",
+  "interests": [
+    "work"
+  ],
   "name": "Meeting Recording to Minutes & Actions",
   "description": "Turn a meeting recording into structured minutes plus a clear action-item list — who agreed to do what by when — derived from the audio. Transcribes the recording FIRST (with speaker labels so attribution is possible), then summarizes into decisions, discussion, and assigned action items with owners and due dates. The transcribe-then-summarize ordering is essential: you cannot reliably attribute decisions and owners without first knowing who said what, and minutes without owners are useless.",
   "tags": [

package/data/craftbook-templates/me/memory-prompt-session/manifest.json

@@ -4,6 +4,9 @@
   "id": "memory-prompt-session",
   "role": "general",
   "category": "writing",
+  "interests": [
+    "home"
+  ],
   "name": "Memory Session",
   "description": "Run one guided memory session and bank it properly: pick the theme the timeline is hungriest for, follow the thread of feeling through the recorded conversation, and file the session with the follow-up questions that keep the next one alive. Locks the theme and question set FIRST, then captures the session in the teller's own words, then files it in the store with the threads to pull next time. Use for memory sessions, filing an interview with a parent or grandparent, memoir capture, and 'what should I ask next time'.",
   "tags": [

package/data/craftbook-templates/mi/micro-game-jam/manifest.json

@@ -4,6 +4,10 @@
   "id": "micro-game-jam",
   "role": "project-starter",
   "category": "code-build",
+  "interests": [
+    "software",
+    "play"
+  ],
   "name": "Micro Game Jam",
   "description": "Build a tiny, complete, themed micro-game from a one-word or one-line prompt — a 60-second arcade or one-mechanic toy that fully fits in a single HTML file with a clear goal and a win/lose. Interprets the theme into one tight mechanic and a scope you can actually finish first, then builds the whole game in one pass. The jam discipline is ruthless scope: pick ONE mechanic that expresses the theme, lock a tiny acceptance bar, and ship it playable rather than sprawling — the ordering that gets a small model to a finished game instead of an unfinished engine.",
   "tags": [

package/data/craftbook-templates/mo/mock-interview/manifest.json

@@ -4,6 +4,9 @@
   "id": "mock-interview",
   "role": "general",
   "category": "business",
+  "interests": [
+    "learning"
+  ],
   "name": "Mock Interview",
   "description": "A realistic practice interview run live with the candidate — planned questions calibrated to the target role and round, a real-time interview with pressure follow-ups, and a kind, specific debrief: strengths in the candidate's own words, fixes with sketched stronger answers, one drill, and an honest readiness read. The debrief is the deliverable. Use before any real interview round.",
   "tags": [

package/data/craftbook-templates/mo/mod-scaffold/manifest.json

@@ -4,6 +4,10 @@
   "id": "mod-scaffold",
   "role": "project-starter",
   "category": "code-build",
+  "interests": [
+    "software",
+    "play"
+  ],
   "name": "Scaffold a Mod",
   "description": "Start the mod right: a correctly-shaped Minecraft datapack — pack.mcmeta carrying the right format number for the target game version, namespaced folders laid out properly, and one working example of the mod's core idea — plus install steps a twelve-year-old can follow. Locks the idea and the version's structure rules FIRST, then scaffolds the tree, then writes the README. Use for starting a datapack, scaffolding a mod, 'my kid wants a mod that…', datapack setup, and first-mod projects.",
   "tags": [

package/data/craftbook-templates/mo/month-close/manifest.json

@@ -4,6 +4,9 @@
   "id": "month-close",
   "role": "general",
   "category": "business",
+  "interests": [
+    "home"
+  ],
   "name": "Close the Month",
   "description": "Close out a month of household spending against the project's ledger: sweep the month's entries for category strays and surprises, compute the in/out/net totals and category breakdown, compare against the prior month, and write a short honest month summary with one concrete action for next month. Locks the target month and the reconciliation checks FIRST, then reconciles the entries, then writes the summary — so the close is a repeatable ritual with the same shape every month, not an ad-hoc glance at the numbers. Use for monthly budget close, month-end money review, 'how did we do this month', and household spending retrospectives.",
   "tags": [

package/data/craftbook-templates/mo/monthly-recording-review/manifest.json

@@ -4,6 +4,9 @@
   "id": "monthly-recording-review",
   "role": "maintenance-review",
   "category": "personal",
+  "interests": [
+    "learning"
+  ],
   "name": "Monthly Recording Review",
   "description": "Sit with the month's recordings the way a teacher would: compare each against last month's marks, hear the progress your own ears stopped noticing, and pick next month's one focus — proof over impression, once a month. Locks the review criteria FIRST (every recording assessed, deltas versus last month, exactly one focus), then assesses each recording with evidence, then writes the month's review. Use for monthly practice reviews, listening back to recordings, progress checks, and 'how did this month go'.",
   "tags": [

package/data/craftbook-templates/oc/ocr-extract/manifest.json

@@ -4,6 +4,10 @@
   "id": "ocr-extract",
   "role": "general",
   "category": "media",
+  "interests": [
+    "work",
+    "home"
+  ],
   "name": "OCR a Folder of Scans",
   "description": "Extract the text from a folder of scanned documents or photographed pages into clean, structured text — preserving reading order, paragraph breaks, and per-file provenance — then verify the extraction against the source images. Scope FIRST the languages, output structure (one file per scan vs a combined doc), and how to handle tables/columns/low-confidence regions, because OCR quality is dominated by handling layout and flagging uncertainty; then run extraction and verify a sample reads correctly. Covers OCR, text extraction, scanned documents, digitizing paper, receipt/invoice text, and image-to-text.",
   "tags": [

package/data/craftbook-templates/of/offer-compare/manifest.json

@@ -4,6 +4,9 @@
   "id": "offer-compare",
   "role": "general",
   "category": "business",
+  "interests": [
+    "learning"
+  ],
   "name": "Offer Comparison",
   "description": "Turn competing job offers into one honest decision sheet — every offer normalized into the same fact grid (comp, equity with vesting caveats, benefits, level, location, growth, deadlines), unknowns marked UNKNOWN instead of guessed, computed year-1 and 4-year views under stated assumptions, a weighted read against the candidate's OWN priorities, and a recommendation that separates arithmetic from judgment. Use when any second offer (or a strong counter) lands.",
   "tags": [

package/data/craftbook-templates/on/one-pager/manifest.json

@@ -4,6 +4,10 @@
   "id": "one-pager",
   "role": "general",
   "category": "marketing",
+  "interests": [
+    "work",
+    "business"
+  ],
   "name": "One-Pager Brief",
   "description": "Create a single-page brief or summary that fits one printed page and lands one message fast — a product one-pager, executive summary, project brief, or leave-behind. Scopes the single audience + the one thing they must remember FIRST, then designs a tight one-page layout (headline, scannable sections, a sidebar of facts), then writes punchy copy that fits the page — ruthless about cutting anything that pushes past one page. Use when the answer must be skimmable in 60 seconds on a single sheet.",
   "tags": [