@bendyline/gilde 0.1.3 → 0.1.5

package/data/craftbook-templates/de/deep-security-review/versions/1.1.0/craftbook.json

@@ -0,0 +1,201 @@
+{
+  "id": "deep-security-review",
+  "name": "Deep Security Review",
+  "description": "Run a slow, thorough, WHOLE-CODEBASE security audit that looks for SYSTEMIC weaknesses — a vulnerability class repeated across many routes, a missing control at an architectural layer, inconsistent authorization, ad-hoc secret handling, a trust-boundary violation — not just isolated issues in one file. First reconnoiters the whole system using gezel's static security index (dependency inventory, attack surface, source/sink findings, taint reachability), then builds a threat model to find the highest-blast-radius areas, then audits those areas holistically confirming real source-to-sink paths and consistency of controls across every entry point, then clusters findings into root-cause systemic themes, then writes a prioritized report with a machine-readable findings file. Use this for a deep or systemic security review, a codebase security audit, a nightly security sweep, or finding security issues across a whole project — it is intentionally broader and deeper than a PR-time diff review (see pr-security-review for that).\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\nPhases:\n\n1. Reconnoiter the whole system (reviewer) — build a whole-system security map from the static index → gated on `notes/security/surface-map.md` (markdown-notes)\n2. Threat-model the system (reviewer) — assets, actors, STRIDE per boundary, highest blast radius → gated on `notes/security/threat-model.md` (markdown-notes)\n3. Audit for systemic weaknesses (reviewer) — confirm real source→sink paths and control consistency across all entry points → gated on `notes/security/findings.md` (markdown-notes)\n4. Cluster findings into systemic themes (reviewer) — group findings by root cause; rank by blast radius → gated on `notes/security/themes.md` (markdown-notes)\n5. Write the security report (reviewer) — systemic report + machine-readable findings, all citing real files → gated on `security-review/REPORT.md` (security-report)\n\nThe gates never advance with an unmet criterion, and loop back to the\nowning phase to fix named gaps.\n",
+  "entryStepId": "recon",
+  "triggers": [
+    "deep security review",
+    "audit the codebase for vulnerabilities",
+    "systemic security review",
+    "find security issues across the whole codebase",
+    "whole-codebase security audit",
+    "nightly security audit"
+  ],
+  "toolsets": [
+    {
+      "toolsetId": "builtin.security-intel",
+      "autoAllow": true,
+      "reason": "static security analysis over the index — scan, findings, attack surface, dependencies, taint reachability"
+    },
+    {
+      "toolsetId": "builtin.code-intel",
+      "autoAllow": true,
+      "reason": "navigate and read the code to confirm each lead"
+    }
+  ],
+  "steps": [
+    {
+      "id": "recon",
+      "name": "Reconnoiter the whole system",
+      "description": "build a whole-system security map from the static index",
+      "prompt": "You are starting a deep, whole-codebase security review — take your time and look across the ENTIRE system, not one file. Step 1: Call `security_scan` to build the dependency inventory and run any installed OSS scanners (semgrep / osv-scanner / gitleaks). Step 2: Call `map_repo`, `map_attack_surface`, `security_overview`, and `list_dependencies` to assemble a whole-system picture: languages and top areas; entry points; route/handler files; auth & middleware boundaries; secret touchpoints (config/env/credential files); files that read untrusted input (taint sources); external integrations and data stores; and the dependency inventory with any advisories. Step 3: Identify the trust boundaries — where untrusted data crosses into the system and where privileged/state-changing operations live. Step 4: Record the CANDIDATE SYSTEMIC THEMES that `security_overview` surfaced (categories recurring across many files) as leads to investigate. Write a whole-system surface map — assets, entry points, trust boundaries, the auth model, data stores, external dependencies, and the candidate themes — to `notes/security/surface-map.md`. No findings yet; this phase orients the review across the whole codebase.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/surface-map.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/surface-map.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/surface-map.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "recon",
+        "maxAttempts": 3
+      },
+      "next": "threatmodel"
+    },
+    {
+      "id": "threatmodel",
+      "name": "Threat-model the system",
+      "description": "assets, actors, STRIDE per boundary, highest blast radius",
+      "prompt": "Using the surface map, build the system's threat model to decide WHERE systemic weaknesses would hurt most. Step 1: List the assets worth protecting (user data, secrets, money/state-changing operations, admin capability) and the actors/threats (unauthenticated user, authenticated user, insider, compromised dependency). Step 2: For each trust boundary, walk STRIDE (spoofing, tampering, repudiation, information-disclosure, denial-of-service, elevation-of-privilege) and note where a weakness would have the highest BLAST RADIUS across the system. Step 3: Prioritize — which boundaries or assets, if weak, would compromise many parts of the app at once? Those are where systemic issues hide and where the audit should spend its time. Write the threat model — assets, actors, trust zones, STRIDE-per-boundary, and the ranked high-blast-radius areas to focus on — to `notes/security/threat-model.md`.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/threat-model.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/threat-model.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/threat-model.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "threatmodel",
+        "maxAttempts": 3
+      },
+      "next": "audit"
+    },
+    {
+      "id": "audit",
+      "name": "Audit for systemic weaknesses",
+      "description": "confirm real source→sink paths and control consistency across all entry points",
+      "prompt": "Investigate the high-blast-radius areas for CONCRETE, SYSTEMIC weaknesses — not one-off style nits. Step 1: Use `scan_findings` (filter by severity/category) to pull the static leads, then VERIFY each in the code with `read_symbol` / `read_file` — a regex lead is not a finding until you confirm the vulnerable path. Step 2: For untrusted inputs, use `trace_taint` on the relevant files to see which sinks are reachable, then confirm the actual source→sink path by reading it; flag any path that reaches a dangerous sink without validation, escaping, or parameterization. Step 3: Assess the auth model HOLISTICALLY — is every route behind an auth boundary? Is authorization applied consistently across ALL entry points, or is the same check missing or re-implemented differently in several places (a systemic broken-access / IDOR pattern)? Step 4: Check secrets posture (hardcoded or logged secrets, ad-hoc env reads), crypto usage (weak algorithms, predictable randomness), and dependency risk (advisory-bearing packages from `list_dependencies`). Step 5: For every CONFIRMED finding capture file:line, the vulnerability class, an exploit sketch, severity and likelihood, and a concrete remediation. Prefer findings that RECUR across the codebase — a class of bug appearing in many places is the systemic signal. Stage the running findings list to `notes/security/findings.md`; also note the threat classes you checked and found clean.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/findings.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/findings.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/findings.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "audit",
+        "maxAttempts": 3
+      },
+      "next": "synthesize"
+    },
+    {
+      "id": "synthesize",
+      "name": "Cluster findings into systemic themes",
+      "description": "group findings by root cause; rank by blast radius",
+      "prompt": "Step back from the individual findings and cluster them into SYSTEMIC THEMES — the root-cause patterns that explain many findings at once (e.g. 'input validation is inconsistent across the API routes', 'secrets are loaded ad hoc in several modules with no central config', 'there is no shared authorization layer so each endpoint re-checks access differently'). Step 1: Group the findings by ROOT CAUSE, not by file. Step 2: For each theme, state the root cause (the architectural gap), the BLAST RADIUS (how much of the system it touches and how many findings it explains), and the systemic FIX (the single change that would prevent the whole class). Step 3: Rank the themes by blast radius × severity. Write the themes to `notes/security/themes.md`. A clean codebase with no material findings can say so plainly rather than inventing themes.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "notes/security/themes.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "notes/security/themes.md",
+            "bytes": 120
+          },
+          {
+            "kind": "sniff",
+            "file": "notes/security/themes.md",
+            "sniff": "nonempty"
+          }
+        ],
+        "onReject": "synthesize",
+        "maxAttempts": 3
+      },
+      "next": "report"
+    },
+    {
+      "id": "report",
+      "name": "Write the security report",
+      "description": "systemic report + machine-readable findings, all citing real files",
+      "prompt": "Write the final deliverable as TWO files in the `security-review/` folder. Step 1: Write `security-review/findings.json` — a JSON array where each finding is an object with: `file` (a REAL workspace path), `line` (a number), `severity` (one of critical, high, medium, low, info), `category`, `title`, `remediation` (a concrete fix), and `theme` (the systemic theme it belongs to). Every `file` MUST be a real path in this workspace and every finding MUST have a line, a severity, and a concrete remediation — no fabricated paths. Step 2: Write `security-review/REPORT.md` with these sections, using those exact headings: `## Verdict` — a one-line top verdict (e.g. Block / Remediate-then-ship / Acceptable) with the count of findings by severity; do NOT say 'safe to merge' while any critical/high finding is open. `## Systemic Themes` — each theme from synthesize with its root cause and blast radius (this is the heart of a deep review). `## Findings` — each finding as `### [SEVERITY] class — file:line` with the exploit sketch, impact, and remediation, ordered by severity then blast radius. `## Verified Safe` — the threat classes you checked and found clean, so coverage is auditable. `## Not Statically Verifiable` — anything needing a pentest or runtime check. On a loop-back, fix ONLY the gaps the evaluator named without dropping findings that already passed.",
+      "suggestedRole": "reviewer",
+      "advanceWhen": {
+        "file": "security-review/REPORT.md",
+        "minBytes": 1,
+        "sniff": "nonempty"
+      },
+      "gate": {
+        "at": "completion",
+        "checks": [
+          {
+            "kind": "minBytes",
+            "file": "security-review/REPORT.md",
+            "bytes": 1500
+          }
+        ],
+        "scripts": [
+          {
+            "name": "checkSecurityReport",
+            "scope": "standard",
+            "inputs": {
+              "file": "security-review/REPORT.md",
+              "findings": "security-review/findings.json"
+            }
+          }
+        ],
+        "onReject": "report",
+        "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": "Open `security-review/REPORT.md` and `security-review/findings.json` and grade the review against its acceptance criteria. Check EACH and write PASS/FAIL with a one-line reason: (1) every finding is pinned to a REAL file:line (no fabricated paths) with a severity and a concrete remediation; (2) the Systemic Themes section names the root-cause patterns with their blast radius — a deep review is about systemic issues, not a list of isolated nits; (3) untrusted-input findings trace a real source→sink path rather than restating a raw scanner hit; (4) the auth model was assessed HOLISTICALLY (consistency across all entry points), not file-by-file; (5) a Verified-safe section makes the review's coverage auditable; (6) the verdict matches the open severity (no 'safe' with an open critical/high); (7) no vague filler like 'consider validating inputs' — every finding is concrete. If any criterion fails, name the exact gap and loop back.\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: \"report\" })` 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",
+      "next": "report"
+    },
+    {
+      "id": "finish",
+      "name": "Finish",
+      "description": "All acceptance criteria met. Stamp a short summary and report DONE.",
+      "prompt": "The security review passed every acceptance criterion. Write a one-paragraph DONE summary to task notes via `write_task_note`: the top-line verdict, the count of findings by severity, the systemic themes, and the deliverable paths (`security-review/REPORT.md` + `security-review/findings.json`). Then report DONE.",
+      "suggestedRole": "developer",
+      "terminal": true
+    }
+  ],
+  "version": "1.1.0",
+  "releasedAt": "2026-07-28T00:00:00Z"
+}

package/data/craftbook-templates/de/deep-security-review/versions/1.1.0/test.json

@@ -0,0 +1,157 @@
+{
+  "schemaVersion": 1,
+  "title": "Deep Security Review systemic eval",
+  "objective": "Measure whether the review confirms seeded source-to-sink vulnerabilities, identifies systemic root causes, and emits valid machine-readable findings.",
+  "tags": [
+    "corpus"
+  ],
+  "prompt": "Use the Deep Security Review craftbook for a whole-codebase security sweep. The fixture is offline and self-contained. Write security-review/REPORT.md and security-review/findings.json; do not modify source.",
+  "setup": {
+    "projectName": "Security Maintenance Eval",
+    "about": "A tiny admin service with deliberate command injection, SQL injection, and inconsistent authorization.",
+    "missionObjectives": "Confirm real source-to-sink paths, cluster root causes, and leave report plus structured findings without inventing files or advisories.",
+    "files": [
+      {
+        "path": "src/admin.ts",
+        "content": "import { exec } from 'node:child_process';\nexport function register(app, db) {\n  app.get('/admin/export', (req, res) => {\n    exec('zip -r /tmp/' + req.query.name + '.zip data', (_e, out) => res.send(out));\n  });\n  app.get('/admin/users', async (req, res) => {\n    const rows = await db.query(`SELECT * FROM users WHERE team = '${req.query.team}'`);\n    res.json(rows);\n  });\n}\n"
+      },
+      {
+        "path": "src/profile.ts",
+        "content": "export function registerProfile(app, db, requireUser) {\n  app.get('/profile', requireUser, async (req, res) => {\n    const row = await db.query('SELECT * FROM users WHERE id = ?', [req.user.id]);\n    res.json(row);\n  });\n}\n"
+      },
+      {
+        "path": "docs/security.md",
+        "content": "# Security model\n\nAll /admin routes must require the requireAdmin middleware before business logic runs. SQL must use placeholders. Shell commands must not include request data.\n"
+      }
+    ],
+    "worker": {
+      "name": "Rae",
+      "role": "Reviewer"
+    }
+  },
+  "mocks": [],
+  "success": {
+    "summary": "The report and findings JSON confirm both injection paths and the missing admin boundary with systemic remediation.",
+    "deliverables": [
+      {
+        "path": "security-review/REPORT.md",
+        "kind": "security-report",
+        "minBytes": 1500,
+        "checks": [
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "src/admin\\.ts:[0-9]+",
+            "flags": "i",
+            "label": "real file and line"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "command injection|exec",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "SQL injection|parameter",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "authorization|requireAdmin|auth",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "Systemic Themes|root cause|blast radius",
+            "flags": "i"
+          },
+          {
+            "kind": "contains",
+            "file": "security-review/REPORT.md",
+            "pattern": "Verified Safe|Not Statically Verifiable",
+            "flags": "i"
+          }
+        ]
+      },
+      {
+        "path": "security-review/findings.json",
+        "kind": "json",
+        "minBytes": 300,
+        "checks": [
+          {
+            "kind": "sniff",
+            "file": "security-review/findings.json",
+            "sniff": "json-valid"
+          },
+          {
+            "kind": "recordSchema",
+            "file": "security-review/findings.json",
+            "format": "json",
+            "minRows": 3,
+            "fields": [
+              {
+                "name": "file",
+                "type": "nonempty",
+                "required": true
+              },
+              {
+                "name": "line",
+                "type": "integer",
+                "required": true
+              },
+              {
+                "name": "severity",
+                "type": "^(critical|high|medium|low|info)$",
+                "required": true
+              },
+              {
+                "name": "category",
+                "type": "nonempty",
+                "required": true
+              },
+              {
+                "name": "remediation",
+                "type": "nonempty",
+                "required": true
+              },
+              {
+                "name": "theme",
+                "type": "nonempty",
+                "required": true
+              }
+            ]
+          }
+        ]
+      }
+    ]
+  },
+  "rubric": {
+    "artifact": {
+      "path": "security-review/REPORT.md",
+      "kind": "markdown"
+    },
+    "axes": [
+      {
+        "name": "verification",
+        "description": "Raw leads are confirmed as real source-to-sink or authorization paths."
+      },
+      {
+        "name": "systemic analysis",
+        "description": "Findings are grouped by root cause and blast radius."
+      },
+      {
+        "name": "remediation",
+        "description": "The report and JSON contain concrete, severity-consistent fixes."
+      }
+    ]
+  },
+  "qualityFocus": [
+    "confirmed vulnerabilities",
+    "systemic themes",
+    "machine-readable findings"
+  ]
+}

package/data/craftbook-templates/de/dependency-audit/art.json

@@ -0,0 +1,12 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "inspect-review",
+  "accents": [
+    "muted terracotta",
+    "sage"
+  ],
+  "sourceSummary": "Audit a project's dependencies for security, staleness, license, and maintenance risk, then produce a prioritized remediation report.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/de/dependency-audit/manifest.json

@@ -18,6 +18,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/de/deploy-checklist/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "plan-coordinate",
+  "accents": [
+    "ochre",
+    "sage",
+    "muted indigo"
+  ],
+  "sourceSummary": "Author and then actually execute a pre-deploy verification checklist for shipping a release to production — the concrete gates that must be green before the deploy button is pressed: tests passing, build clean, migrations reviewed, config/secrets present, feature flags set, rollback path confirmed, and…",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/de/deploy-checklist/manifest.json

@@ -16,6 +16,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/de/design-review/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "design-media",
+  "accents": [
+    "muted terracotta",
+    "sage",
+    "muted indigo"
+  ],
+  "sourceSummary": "Critique a UI's user experience and visual design and produce a prioritized design-review report.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/de/design-review/manifest.json

@@ -15,6 +15,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/de/design-system-consultation/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "design-media",
+  "accents": [
+    "muted terracotta",
+    "sage",
+    "muted indigo"
+  ],
+  "sourceSummary": "Interview for product context and taste, then propose a full design system — type, color, layout, motion — and capture it as a DESIGN.md with live preview pages.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/de/design-system-consultation/manifest.json

@@ -10,6 +10,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": []
 }

package/data/craftbook-templates/di/diagram-from-text/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "design-media",
+  "accents": [
+    "muted terracotta",
+    "sage",
+    "muted indigo"
+  ],
+  "sourceSummary": "Render a clear technical diagram — flowchart, architecture, sequence, ER, or org chart — from a plain-language description, as code-defined (Mermaid/Graphviz/SVG) so it is editable and version-controllable rather than a flat picture.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/di/diagram-from-text/manifest.json

@@ -15,6 +15,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/di/digest-from-feeds/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "build-code",
+  "accents": [
+    "muted indigo",
+    "terracotta",
+    "sage"
+  ],
+  "sourceSummary": "Build a recurring digest from RSS/Atom feeds or news sources: fetch the latest items in the window, dedupe and cluster by topic, then write a scannable digest with one-line takes and source links.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/di/digest-from-feeds/manifest.json

@@ -15,6 +15,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/do/doc-intake-pipeline/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "operate-maintain",
+  "accents": [
+    "sage",
+    "ochre",
+    "muted terracotta"
+  ],
+  "sourceSummary": "Build a document-intake pipeline that classifies each incoming file (invoice, contract, resume, receipt, ID, support ticket, other) into a fixed type set, extracts a few key fields per type, and routes it to the right destination folder with a normalized filename.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/do/doc-intake-pipeline/manifest.json

@@ -15,6 +15,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/do/doc-rewrite/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "write-publish",
+  "accents": [
+    "muted terracotta",
+    "muted indigo",
+    "sage"
+  ],
+  "sourceSummary": "Rewrite confusing existing documentation into clear, scannable, task-oriented prose without losing any technical fact: it first audits the current doc to catalog every problem — buried steps, undefined jargon, missing prerequisites, broken structure — and locks a clarity checklist, then rewrites the doc to fix exactly…",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/do/doc-rewrite/manifest.json

@@ -15,6 +15,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/do/dockerize-app/art.json

@@ -0,0 +1,12 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "inspect-review",
+  "accents": [
+    "muted terracotta",
+    "sage"
+  ],
+  "sourceSummary": "Containerize an application with a production-grade Dockerfile — small, secure, reproducible, and buildable — plus the supporting files to run it.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/do/dockerize-app/manifest.json

@@ -15,6 +15,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/do/docs-site/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "build-code",
+  "accents": [
+    "muted indigo",
+    "terracotta",
+    "sage"
+  ],
+  "sourceSummary": "Build a single-page documentation site with a sidebar table of contents, anchored sections, code blocks, and in-page navigation — the kind of reference page a library or API ships.",
+  "styleReference": "accessibility-audit-1910"
+}

package/data/craftbook-templates/do/docs-site/manifest.json

@@ -15,6 +15,7 @@
   "maintainer": {
     "name": "Gezel"
   },
+  "logo": "logo.webp",
   "license": "MIT",
   "yankedVersions": [],
   "workflow": "build-loop"

package/data/craftbook-templates/do/documentation-drift-review/art.json

@@ -0,0 +1,13 @@
+{
+  "schemaVersion": 1,
+  "promptVersion": "workshop-mark-1910-v2",
+  "periodCue": "circa-1910-subtle",
+  "family": "write-publish",
+  "accents": [
+    "muted terracotta",
+    "muted indigo",
+    "sage"
+  ],
+  "sourceSummary": "Review project documentation against the code, configuration, commands, API surface, and shipped behavior to find stale or misleading guidance.",
+  "styleReference": "accessibility-audit-1910"
+}