@bendyline/gilde 0.1.39 → 0.1.41

package/data/craftbook-templates/it/item-intake/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "item-intake",
   "role": "general",
+  "category": "personal",
   "name": "Catalog an Item",
   "description": "Take new arrivals from shoebox to catalog: identify each item from its photo notes, record it with condition and an honest value basis, and flag what needs a better photo or an expert eye — uncertain identification stays uncertain in the record instead of becoming confident fiction. Locks the record fields and the honesty rule FIRST, then catalogs each item, then reports confidence and follow-ups. Use for cataloging new items, collection intake, 'catalog these arrivals', and adding finds to the collection.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "juice-pass",
   "role": "general",
+  "category": "code-build",
   "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/kn/knowledge-base-article/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "knowledge-base-article",
   "role": "general",
+  "category": "writing",
   "name": "Knowledge Base Article",
   "description": "Write a support knowledge-base article that lets a user solve their problem without contacting support: it first scopes the exact user problem, the search terms they would use, prerequisites, and the success outcome, then writes a task-oriented article with a clear title, a short overview, numbered steps with expected results, screenshots/placeholders where needed, and a troubleshooting section, then a review pass verifies accuracy and self-service completeness. Covers help center article, support documentation, how-to article, KB article, self-service docs, and product help. Scoping the precise problem and search terms before writing is the point: a small model that pins the one job-to-be-done writes a findable, followable article instead of a vague overview that leaves the user still stuck.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "kpi-scorecard",
   "role": "general",
+  "category": "business",
   "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-copy/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "landing-copy",
   "role": "general",
+  "category": "marketing",
   "name": "Landing Page Copy",
   "description": "Write conversion-focused copy for a single landing page: it first locks the offer, the one primary audience, the single desired action, and the core promise, then drafts a full message hierarchy — hero headline and subhead, value props, social proof, objection handling, and one repeated CTA — then edits ruthlessly for clarity, specificity, and persuasive flow. Covers landing page copy, sales copy, conversion copywriting, hero copy, CTA copy, and value proposition writing. Offer-first ordering matters: a small model that nails the single offer and one CTA before writing avoids the diluted page that lists ten features, hedges the promise, and offers three competing actions.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "landing-page",
   "role": "project-starter",
+  "category": "code-build",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "lead-enrichment",
   "role": "general",
+  "category": "marketing",
   "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/library-package/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "library-package",
   "role": "project-starter",
+  "category": "code-build",
   "name": "Reusable Library Package",
   "description": "Build a reusable library/SDK with a clean public API surface, sensible defaults, and published documentation. Designs the public API FIRST — exported functions/classes, signatures, types, error contract, and what stays internal — because a library's API is a long-lived promise, then implements it, then writes user-facing docs with installation, quickstart, and a worked example per public function. Covers public-vs-private surface, function signatures, JSDoc/typedoc, README, semantic versioning posture, and usage examples.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "literature-review",
   "role": "general",
+  "category": "research",
   "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/li/live-browser-qa/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "live-browser-qa",
   "role": "maintenance-review",
+  "category": "code-quality",
   "name": "Live Browser QA Pass",
   "description": "Run a hands-on quality-assurance pass on a running web app or page by actually exercising it in a browser, then emit a defect report with reproduction steps and severity. First derives a test plan and acceptance criteria from the app's intended behavior (happy paths, edge cases, error states, responsive/console health), then drives the UI step-by-step clicking and typing through each flow while watching the console and network for errors, then writes a bug report where every defect has numbered repro steps, expected vs actual, and severity. Use this for QA, manual testing, smoke testing, exploratory testing, click-testing a build, or verifying a feature works in the real browser before shipping — it finds broken flows, console errors, and visual breakage that unit tests miss.",
   "tags": [
@@ -18,6 +19,10 @@
   },
   "logo": "logo.webp",
   "license": "MIT",
-  "yankedVersions": [],
+  "yankedVersions": [
+    "1.0.0",
+    "1.0.1",
+    "1.0.2"
+  ],
   "workflow": "build-loop"
 }

package/data/craftbook-templates/lo/localize-content/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "localize-content",
   "role": "general",
+  "category": "writing",
   "name": "Localize Content",
   "description": "Localize and translate content into a target language and locale with cultural adaptation, not just word-for-word translation: it first scopes the target locale, glossary of do-not-translate and must-translate-consistently terms, formatting conventions (dates, currency, units), and tone register, then translates preserving meaning and structure, then a native-level review pass checks fluency, terminology consistency, and cultural fit. Covers translation, localization, i18n content, multilingual copy, translate to Spanish/French/German, and locale adaptation. Scoping the glossary and conventions before translating is the point: a small model that locks terminology and date/currency rules avoids inconsistent term translations and locale-wrong formatting that mark content as machine-translated.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "logo-set",
   "role": "general",
+  "category": "design",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "market-scan",
   "role": "general",
+  "category": "research",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "meeting-minutes",
   "role": "general",
+  "category": "business",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "meeting-notes-to-actions",
   "role": "general",
+  "category": "business",
   "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-prep-brief/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "meeting-prep-brief",
   "role": "general",
+  "category": "business",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "meeting-summary-audio",
   "role": "general",
+  "category": "business",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "memory-prompt-session",
   "role": "general",
+  "category": "writing",
   "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/me/message-queue-consumer/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "message-queue-consumer",
   "role": "project-starter",
+  "category": "code-data",
   "name": "Message Queue Consumer / Worker",
   "description": "Build a queue consumer/worker that pulls messages off a queue, processes them reliably, and handles failures with retries and a dead-letter path — at-least-once delivery done right. Scopes the messaging contract FIRST — the message schema, ack/nack semantics, idempotency key, retry/backoff policy, dead-letter rules, and concurrency — then implements the consumer loop with ack-after-success and DLQ routing, then tests success, retry, poison-message, and duplicate-delivery handling. Covers queue consumers, at-least-once vs at-most-once, ack/nack, idempotent processing, retry with backoff, dead-letter queues, and poison-message isolation.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "micro-game-jam",
   "role": "project-starter",
+  "category": "code-build",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "mock-interview",
   "role": "general",
+  "category": "business",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "mod-scaffold",
   "role": "project-starter",
+  "category": "code-build",
   "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/monitor-and-alert/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "monitor-and-alert",
   "role": "general",
+  "category": "code-ops",
   "name": "Watch a Page or API and Alert",
   "description": "Build a watcher that polls a web page or API endpoint on a schedule, detects a meaningful change or threshold breach, and fires an alert (and only alerts on real changes, not noise). Scopes the watched target, the exact change/threshold condition, and the dedup/cooldown policy FIRST, then builds the poll-diff-notify loop with persisted state, then tests it against simulated change and no-change inputs so it neither misses a real change nor spams on every poll. Condition-and-cooldown-before-build is the wisdom that separates a useful monitor from an alert-fatigue generator.",
   "tags": [

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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "month-close",
   "role": "general",
+  "category": "business",
   "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

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "monthly-recording-review",
   "role": "maintenance-review",
+  "category": "personal",
   "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/mo/moodboard/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "moodboard",
   "role": "general",
+  "category": "design",
   "name": "Visual Moodboard",
   "description": "Compose a visual moodboard that captures a direction — palette, textures, type vibe, imagery, and reference tiles — from a written brief, so a team can align on a look before any production work begins. Lock the brief and the explicit dimensions of the mood (e.g. 'warm/editorial/handmade' vs 'cool/technical/precise') FIRST, then assemble a coherent grid of generated or sourced tiles plus a swatch strip and keyword callouts. Covers moodboards, style boards, visual direction, design inspiration, brand mood, and look-and-feel exploration.",
   "tags": [

package/data/craftbook-templates/mo/morning-brief/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "morning-brief",
   "role": "general",
+  "category": "research",
   "name": "Morning Topic Brief",
   "description": "Be informed without the doomscroll: this morning's items per watched topic, each with its source named, rumor separated from reporting, and yesterday's noise skipped — five minutes that replace an hour of feeds. Locks the brief rules FIRST, then gathers from the feeds, then writes the dated brief into the archive next to the previous ones. Use for morning briefs, daily topic digests, 'what happened overnight', news catch-ups on watched topics, and staying informed without the scroll.",
   "tags": [

package/data/craftbook-templates/mo/morning-report/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "morning-report",
   "role": "general",
+  "category": "personal",
   "name": "Morning House Report",
   "description": "The house says good morning properly: every zone's state read through the device tools, anything unusual surfaced first with one suggested action apiece, and the boring rest compressed to a line or two — glanceable before the first coffee. Locks the report criteria FIRST (every zone covered, anomalies before normals, a suggested action per oddity, short enough to read standing up), then polls the house, then writes the report — so the one morning the garage door stayed open all night is the morning it gets noticed. Use for morning house checks, daily home status, 'anything wrong with the house', overnight anomaly sweeps, and a glanceable device roundup.",
   "tags": [

package/data/craftbook-templates/mu/music-metadata-tag/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "music-metadata-tag",
   "role": "general",
+  "category": "media",
   "name": "Music Library Metadata Tagging",
   "description": "Tag and organize a folder of audio files with consistent, correct metadata — title, artist, album, track number, year, genre — so the library is clean, sortable, and player-friendly. Locks the tag schema and naming/foldering convention FIRST, applies tags and a consistent file/folder layout across the whole library, then verifies every file is fully and consistently tagged. Defining the schema and the source of truth before touching files is what prevents a half-tagged, inconsistently-named mess.",
   "tags": [

package/data/craftbook-templates/na/narrated-slideshow/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "narrated-slideshow",
   "role": "general",
+  "category": "media",
   "name": "Animated Content Slideshow",
   "description": "Turn written content into a real MP4 video and animated GIF with DocBlocks. Locks the story and one message per scene, writes one H1 per scene in slideshow.md, then performs one multi-target conversion, previews the frames, and saves both rendered files in the artifacts drawer — no hand-built HTML player.",
   "tags": [

package/data/craftbook-templates/ne/newsletter-issue/manifest.json

@@ -3,6 +3,7 @@
   "kind": "craftbook-template",
   "id": "newsletter-issue",
   "role": "general",
+  "category": "marketing",
   "name": "Newsletter Issue",
   "description": "Produce a single polished, email-client-safe newsletter issue — intro, a few curated stories with links, a featured section, and a CTA — that renders correctly across email clients. Outlines the issue's theme and section lineup FIRST, writes scannable, personable copy with working links, then builds the email-safe HTML using inline styles and table layout so it survives Gmail/Outlook. Use for recurring email newsletters, product updates, and curated digests sent to subscribers.",
   "tags": [

package/data/craftbook-templates/ni/nightly-fix-sweep/art.json

@@ -0,0 +1,12 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "build-repair",
+  "accents": [
+    "deep indigo",
+    "brass"
+  ],
+  "sourceSummary": "Overnight triage of open code findings into clustered, reviewable change proposals; the tree itself is never touched.",
+  "styleReference": "bug-fix-tdd"
+}

package/data/craftbook-templates/ni/nightly-fix-sweep/manifest.json

@@ -0,0 +1,23 @@
+{
+  "schemaVersion": 1,
+  "kind": "craftbook-template",
+  "id": "nightly-fix-sweep",
+  "role": "maintenance-review",
+  "category": "code-quality",
+  "name": "Nightly Fix Sweep",
+  "description": "Turn a night's open code findings into reviewable change proposals: triage the leads, cluster what belongs together, and draft one focused proposal per cluster for the user to read and apply in the morning. The project's files are never touched.",
+  "tags": [
+    "bug-fix",
+    "night-shift",
+    "boekwachter",
+    "proposals",
+    "quality",
+    "batch"
+  ],
+  "maintainer": {
+    "name": "Gezel"
+  },
+  "license": "MIT",
+  "yankedVersions": [],
+  "logo": "logo.webp"
+}

package/data/craftbook-templates/ni/nightly-fix-sweep/versions/1.0.0/craftbook.json

@@ -0,0 +1,145 @@
+{
+  "schemaVersion": 1,
+  "id": "nightly-fix-sweep",
+  "name": "Nightly Fix Sweep",
+  "description": "Turn a batch of open code findings into reviewable change proposals. The host triages the leads against the current code — a lead that no longer matches the file, or that needs a judgement only the owner can make, is legitimately left out — then clusters what belongs together as ONE change (a fix that spans a file and its caller is one cluster, not two) and fans out one drafting shard per cluster. Each shard makes the smallest correct change for its leads and explains it under Problem, Change, Risk, and How to verify. Built for unattended night runs: proposals are what the user reviews and applies in the morning, and the project's files are never touched by the sweep itself.",
+  "version": "1.0.0",
+  "releasedAt": "2026-08-24T00:00:00.000Z",
+  "minGezelVersion": "1.26236",
+  "entryStepId": "triage",
+  "triggers": [
+    "sweep the open findings",
+    "nightly fixes",
+    "draft fixes for the open issues",
+    "fix the boekwachter findings"
+  ],
+  "runModes": {
+    "nightShift": "recommended"
+  },
+  "diffpackCapable": true,
+  "capabilityFloor": "small",
+  "paramSchema": {
+    "type": "object",
+    "properties": {
+      "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}}"
+      },
+      "leads": {
+        "type": "string",
+        "title": "Leads",
+        "description": "Comma-separated finding refs to sweep (e.g. BW-3,BW-8). Leave empty when the task description carries the leads.",
+        "default": ""
+      }
+    }
+  },
+  "steps": [
+    {
+      "id": "triage",
+      "name": "Triage the leads into clusters",
+      "suggestedRole": "developer",
+      "capabilityFloor": "medium",
+      "prompt": "You have been handed open findings to sweep: {{leads}}. The task description may carry more detail per lead.\n\nRead the affected files and judge each lead against the CURRENT code: real, already fixed, stale, or a judgement only the owner can make. Leaving a lead out is legitimate — say why rather than forcing a change to satisfy a stale review.\n\nCluster what belongs together as ONE change: a fix that spans a file and its caller is one cluster, not two — splitting it would hand the user two half-changes neither of which stands alone. At most 8 clusters; prefer fewer, focused ones.\n\nWrite ONE `write_task_note` starting with the line `## Triage`: per lead, whether you will fix it and which cluster it belongs to, with reasons for anything left out.\n\nThen write the cluster list to the artifact `{{workPath}}/clusters.json` with ONE `write_artifact` call: a JSON array where each entry is an object with exactly these string fields — `slug` (short kebab-case name for the cluster, e.g. \"auth-null-guard\"), `issueRefs` (the refs in that cluster, comma-separated), and `focus` (one sentence on what that cluster should change). If nothing is worth fixing, write an empty array `[]` and say why in your note.",
+      "advanceWhen": {
+        "file": "{{workPath}}/clusters.json",
+        "artifact": true,
+        "minBytes": 2,
+        "sniff": "json-valid"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "{{workPath}}/clusters.json",
+            "sniff": "json-valid",
+            "artifact": true
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkTaskNoteContains",
+            "scope": "standard",
+            "inputs": {
+              "taskRef": "{{task.ref}}",
+              "pattern": "##\\s*Triage"
+            }
+          }
+        ],
+        "onReject": "triage",
+        "maxAttempts": 3
+      },
+      "next": "fanout"
+    },
+    {
+      "id": "fanout",
+      "name": "Draft the proposals",
+      "spawnFanout": true,
+      "prompt": "Your clusters are being drafted, one proposal per cluster. Wait for the shards to finish, then call `advance_task_step`.",
+      "next": "collect"
+    },
+    {
+      "id": "collect",
+      "name": "Hand over",
+      "terminal": true,
+      "prompt": "The sweep is done. Write one short `write_task_note` naming the proposals your crew drafted (by cluster) and any leads deliberately left alone with their reasons, then call `advance_task_step`. Never claim anything was fixed or applied — these are proposals for the user to review."
+    }
+  ],
+  "spawn": {
+    "overFile": "{{workPath}}/clusters.json",
+    "overArtifact": true,
+    "entryStepId": "draft",
+    "steps": [
+      {
+        "id": "draft",
+        "name": "Draft the change",
+        "suggestedRole": "developer",
+        "capabilityFloor": "small",
+        "prompt": "Your cluster is {{issueRefs}} ({{slug}}). What it should change: {{focus}}\n\nRead the affected files first, then make the smallest correct change for those leads and nothing else. Use `read_file`, `write_file`, and `replace_in_file` exactly as you always do. Keep it focused — a change a reviewer can read in a minute gets applied; a sprawling one gets dismissed. If a lead turns out to be wrong once you are in the code, leave it alone and say so.\n\nThen write your explanation to the artifact `{{diffpack.dir}}/notes.md` in ONE `write_artifact` call, with exactly these four headings:\n\n## Problem\n## Change\n## Risk\n## How to verify\n\nUnder Change, describe what you altered and why, naming the refs. Under Risk, be honest about what you could not verify without running the code. Then call `advance_task_step`.",
+        "advanceWhen": {
+          "file": "{{diffpack.dir}}/notes.md",
+          "artifact": true,
+          "minBytes": 200
+        },
+        "gate": {
+          "at": "completion",
+          "checks": [
+            {
+              "kind": "contains",
+              "file": "{{diffpack.dir}}/notes.md",
+              "pattern": "##\\s+Problem",
+              "label": "Problem section",
+              "artifact": true
+            },
+            {
+              "kind": "contains",
+              "file": "{{diffpack.dir}}/notes.md",
+              "pattern": "##\\s+Change",
+              "label": "Change section",
+              "artifact": true
+            },
+            {
+              "kind": "contains",
+              "file": "{{diffpack.dir}}/notes.md",
+              "pattern": "##\\s+Risk",
+              "label": "Risk section",
+              "artifact": true
+            },
+            {
+              "kind": "contains",
+              "file": "{{diffpack.dir}}/notes.md",
+              "pattern": "##\\s+How to verify",
+              "label": "How to verify section",
+              "artifact": true
+            }
+          ],
+          "onReject": "draft",
+          "maxAttempts": 3
+        },
+        "terminal": true
+      }
+    ]
+  }
+}

package/data/craftbook-templates/ni/nightly-fix-sweep/versions/1.0.0/test.json

@@ -0,0 +1,121 @@
+{
+  "schemaVersion": 1,
+  "title": "Nightly sweep drafts sealed proposals without touching the tree",
+  "objective": "The host triages two seeded findings into clusters and fans out drafting shards; each shard's edits land in a change proposal that seals on completion, the four-heading notes contract holds, and the workspace files stay byte-identical.",
+  "tags": [
+    "code",
+    "night-shift",
+    "proposals",
+    "fanout",
+    "tactical-fleet"
+  ],
+  "prompt": "Run the Nightly Fix Sweep for the two open findings described in the task. LEAD-1: src/greet.js builds the greeting with a stray double space when no title is given. LEAD-2: src/farewell.js says 'Godbye' instead of 'Goodbye'. Draft the fixes as proposals.",
+  "setup": {
+    "projectName": "Sweep Fixture",
+    "about": "A tiny greeting library with two known low-risk defects, used to exercise the nightly proposal sweep.",
+    "managedWorkspaceWritePolicy": "deny",
+    "files": [
+      {
+        "path": "src/greet.js",
+        "content": "export function greet(name, title) {\n  const prefix = title ? `${title} ` : ' ';\n  return `Hello, ${prefix}${name}!`;\n}\n"
+      },
+      {
+        "path": "src/farewell.js",
+        "content": "export function farewell(name) {\n  return `Godbye, ${name}.`;\n}\n"
+      },
+      {
+        "path": "source/findings.md",
+        "content": "# Open findings\n\n- LEAD-1 (minor, src/greet.js): greeting has a leading double space when no title is passed - `greet('Ada')` returns `Hello,  Ada!`. The no-title prefix should be empty.\n- LEAD-2 (minor, src/farewell.js): the farewell text misspells Goodbye as 'Godbye'.\n"
+      }
+    ],
+    "craftbookParams": {
+      "workPath": "tasks/eval",
+      "leads": "LEAD-1,LEAD-2"
+    }
+  },
+  "success": {
+    "summary": "Clusters were published, shards drafted, at least one proposal sealed with the four-heading notes, and the workspace was never modified.",
+    "deliverables": [
+      {
+        "path": "tasks/eval/clusters.json",
+        "kind": "json",
+        "artifact": true,
+        "minBytes": 2,
+        "checks": [
+          {
+            "kind": "recordSchema",
+            "file": "tasks/eval/clusters.json",
+            "artifact": true,
+            "minRows": 1,
+            "fields": [
+              {
+                "name": "slug",
+                "rule": "nonempty"
+              },
+              {
+                "name": "issueRefs",
+                "rule": "nonempty"
+              },
+              {
+                "name": "focus",
+                "rule": "nonempty"
+              }
+            ]
+          }
+        ]
+      }
+    ],
+    "taskNotes": {
+      "minBytes": 120,
+      "requireCraftbookTask": true,
+      "checks": [
+        {
+          "kind": "contains",
+          "file": "task-notes.md",
+          "pattern": "##\\s*Triage",
+          "label": "triage note present"
+        }
+      ]
+    },
+    "taskGraph": {
+      "requireCraftbookTask": true,
+      "requireTerminalStep": true
+    },
+    "history": [
+      {
+        "kind": "project.diffpack.sealed",
+        "minEntries": 1
+      }
+    ],
+    "unchangedFixtures": [
+      "src/greet.js",
+      "src/farewell.js",
+      "source/findings.md"
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "tasks/eval/clusters.json",
+      "kind": "json"
+    },
+    "axes": [
+      {
+        "name": "Triage judgement",
+        "description": "Leads were judged against the current code and clustered sensibly; anything left out has an honest reason."
+      },
+      {
+        "name": "Proposal focus",
+        "description": "Each drafted proposal is the smallest correct change for its cluster, explained under Problem, Change, Risk, and How to verify."
+      },
+      {
+        "name": "Honesty about mode",
+        "description": "Notes never claim anything was fixed or applied; risk sections admit what could not be verified without running the code."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "proposal discipline",
+    "cluster judgement",
+    "untouched workspace"
+  ]
+}