bigpowers 2.4.0 → 2.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (91) hide show
  1. package/.pi/package.json +2 -2
  2. package/.pi/prompts/align-grid.md +102 -0
  3. package/.pi/prompts/compose-workflow.md +1 -1
  4. package/.pi/prompts/diagnose-root.md +1 -1
  5. package/.pi/prompts/evolve-skill.md +1 -1
  6. package/.pi/prompts/grill-with-docs.md +1 -1
  7. package/.pi/prompts/research-first.md +1 -1
  8. package/.pi/prompts/reset-baseline.md +1 -1
  9. package/.pi/prompts/run-evals.md +1 -1
  10. package/.pi/prompts/scope-work.md +1 -1
  11. package/.pi/prompts/search-skills.md +1 -1
  12. package/.pi/prompts/setup-environment.md +1 -1
  13. package/.pi/prompts/simulate-agents.md +1 -1
  14. package/.pi/prompts/slice-tasks.md +1 -1
  15. package/.pi/prompts/stocktake-skills.md +1 -1
  16. package/.pi/prompts/verify-work.md +1 -1
  17. package/.pi/skills/align-grid/SKILL.md +104 -0
  18. package/.pi/skills/assess-impact/SKILL.md +2 -1
  19. package/.pi/skills/audit-code/SKILL.md +1 -0
  20. package/.pi/skills/build-epic/SKILL.md +1 -0
  21. package/.pi/skills/change-request/SKILL.md +1 -0
  22. package/.pi/skills/commit-message/SKILL.md +1 -0
  23. package/.pi/skills/compose-workflow/SKILL.md +2 -1
  24. package/.pi/skills/craft-skill/SKILL.md +1 -0
  25. package/.pi/skills/deepen-architecture/SKILL.md +1 -0
  26. package/.pi/skills/define-language/SKILL.md +2 -1
  27. package/.pi/skills/define-success/SKILL.md +2 -1
  28. package/.pi/skills/delegate-task/SKILL.md +1 -0
  29. package/.pi/skills/design-interface/SKILL.md +2 -1
  30. package/.pi/skills/develop-tdd/SKILL.md +1 -0
  31. package/.pi/skills/diagnose-root/SKILL.md +2 -1
  32. package/.pi/skills/dispatch-agents/SKILL.md +1 -0
  33. package/.pi/skills/edit-document/SKILL.md +1 -0
  34. package/.pi/skills/elaborate-spec/SKILL.md +2 -1
  35. package/.pi/skills/enforce-first/SKILL.md +2 -1
  36. package/.pi/skills/evolve-skill/SKILL.md +2 -1
  37. package/.pi/skills/execute-plan/SKILL.md +1 -0
  38. package/.pi/skills/fix-bug/SKILL.md +1 -0
  39. package/.pi/skills/grill-me/SKILL.md +2 -1
  40. package/.pi/skills/grill-with-docs/SKILL.md +2 -1
  41. package/.pi/skills/guard-git/SKILL.md +1 -0
  42. package/.pi/skills/hook-commits/SKILL.md +1 -0
  43. package/.pi/skills/inspect-quality/SKILL.md +2 -1
  44. package/.pi/skills/investigate-bug/SKILL.md +2 -1
  45. package/.pi/skills/kickoff-branch/SKILL.md +2 -1
  46. package/.pi/skills/map-codebase/SKILL.md +2 -1
  47. package/.pi/skills/migrate-spec/SKILL.md +1 -0
  48. package/.pi/skills/model-domain/SKILL.md +1 -0
  49. package/.pi/skills/orchestrate-project/SKILL.md +1 -0
  50. package/.pi/skills/organize-workspace/SKILL.md +2 -1
  51. package/.pi/skills/plan-refactor/SKILL.md +1 -0
  52. package/.pi/skills/plan-release/SKILL.md +2 -1
  53. package/.pi/skills/plan-work/SKILL.md +2 -1
  54. package/.pi/skills/release-branch/SKILL.md +2 -1
  55. package/.pi/skills/request-review/SKILL.md +1 -0
  56. package/.pi/skills/research-first/SKILL.md +2 -1
  57. package/.pi/skills/reset-baseline/SKILL.md +2 -1
  58. package/.pi/skills/respond-review/SKILL.md +1 -0
  59. package/.pi/skills/run-evals/SKILL.md +2 -1
  60. package/.pi/skills/run-planning/SKILL.md +2 -1
  61. package/.pi/skills/scope-work/SKILL.md +2 -1
  62. package/.pi/skills/search-skills/SKILL.md +2 -1
  63. package/.pi/skills/seed-conventions/SKILL.md +1 -0
  64. package/.pi/skills/session-state/SKILL.md +1 -0
  65. package/.pi/skills/setup-environment/SKILL.md +2 -1
  66. package/.pi/skills/simulate-agents/SKILL.md +2 -1
  67. package/.pi/skills/slice-tasks/SKILL.md +2 -1
  68. package/.pi/skills/spike-prototype/SKILL.md +2 -1
  69. package/.pi/skills/stocktake-skills/SKILL.md +2 -1
  70. package/.pi/skills/survey-context/SKILL.md +1 -0
  71. package/.pi/skills/terse-mode/SKILL.md +2 -1
  72. package/.pi/skills/trace-requirement/SKILL.md +2 -1
  73. package/.pi/skills/using-bigpowers/SKILL.md +2 -1
  74. package/.pi/skills/validate-fix/SKILL.md +2 -1
  75. package/.pi/skills/verify-work/SKILL.md +2 -1
  76. package/.pi/skills/visual-dashboard/SKILL.md +1 -0
  77. package/.pi/skills/wire-observability/SKILL.md +1 -0
  78. package/.pi/skills/write-document/SKILL.md +1 -0
  79. package/CHANGELOG.md +14 -0
  80. package/SKILL-INDEX.md +34 -33
  81. package/align-grid/SKILL.md +108 -0
  82. package/align-grid/scripts/grid_tokens.py +201 -0
  83. package/align-grid/scripts/verify_grid.js +140 -0
  84. package/dashboard/src/web/client.html +191 -249
  85. package/package.json +1 -1
  86. package/scripts/generate-reference-tables.sh +1 -1
  87. package/scripts/sync-skills.sh +22 -10
  88. package/scripts/validate-skill-yaml.py +73 -0
  89. package/visual-dashboard/scripts/cockpit.html +123 -16
  90. package/visual-dashboard/scripts/frame-template.html +181 -45
  91. package/countable-story-format.md +0 -293
package/.pi/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "bigpowers",
3
- "version": "2.4.0",
4
- "description": "61 skills — 61 agent skills for spec-driven, test-first software development by solo developers",
3
+ "version": "2.5.0",
4
+ "description": "62 skills — 61 agent skills for spec-driven, test-first software development by solo developers",
5
5
  "keywords": [
6
6
  "pi-package"
7
7
  ],
@@ -0,0 +1,102 @@
1
+ ---
2
+ description: "Build editorial/magazine/report webpages on a GENUINE Müller-Brockmann modular grid (International Typographic Style) — not a decorative one. Encodes the discipline (columns + modules + baseline, grotesque type, flush-left, restrained black/white/red palette) AND the hard-won front-end engineering to make the grid real, visible, and verified: one CSS-variable source of truth, an interactive grid-toggle overlay that lives in the SAME content box as the content, subgrid \"bands\" so every element snaps to a column line, an 8px baseline lock, and runtime OPTICAL ALIGNMENT that puts display type's ink (not its box) on the line. Ships with a scaffold generator and a Puppeteer verification harness that proves 0px adherence."
3
+ ---
4
+
5
+
6
+ # Müller-Brockmann Grid Systems — built real, visible, and verified
7
+
8
+ Josef Müller-Brockmann (1914–1996), Zurich; *Grid Systems in Graphic Design* (1981) is the corpus. The grid is treated as an ethic, not decoration: **"The grid system is an aid, not a guarantee. It permits a number of possible uses and each designer can look for a solution appropriate to his personal style. But one must learn how to use the grid; it is an art that requires practice."** This skill encodes that discipline AND — the part most attempts get wrong — the front-end engineering to make the grid genuinely load-bearing on the web, plus a harness that PROVES it.
9
+
10
+ > Two real review notes this skill exists to prevent:
11
+ > 1. *"the grid is just slapped on top and misaligned"* → the overlay wasn't in the same content box as the content (see §2.2).
12
+ > 2. *"the H in the headline is off the grid"* → the headline's BOX was on the grid but its INK wasn't; large glyphs carry a side-bearing (see §2.6). **Box-on-grid ≠ ink-on-grid.**
13
+
14
+
15
+ ## PART 1 — THE DISCIPLINE (decide before drawing)
16
+ - **Objective order.** The grid brings "constructive thought," legibility, and "objective and functional" design. Restraint is the point; the system, not the ego, organizes the page.
17
+ - **Modular grid.** Divide the type area into a field of **modules** — columns AND rows — separated by consistent **gutters**, inside defined **margins**. Text and images occupy whole modules. Müller-Brockmann specimens common field counts (8 / 20 / 32 fields). For the web, a **12-column grid + 8px baseline** is a robust general default; a **6×6 or 4×8 modular field grid** when you want visible rows too.
18
+ - **Baseline grid.** Vertical rhythm is sacred: **leading = a whole multiple of the baseline unit**, and every element snaps to it. This is what makes facing columns and images line up across the page.
19
+ - **Typography.** A **grotesque sans** (Akzidenz-Grotesk / Helvetica; on the web Inter, Helvetica Now, Archivo). **Flush-left, ragged-right.** Few sizes, large jumps in **scale** for hierarchy; objective, not expressive. Big **numerals/data set large** is a signature move.
20
+ - **Palette.** Pure white paper, near-black ink, **one accent — red is canonical**. Avoid the warm-cream "Claude look"; **never blue/purple gradients** (hard house rule).
21
+ - **White space + asymmetry.** Generous margins; asymmetric compositions held in tension by the grid.
22
+
23
+
24
+ ## PART 2 — MAKE THE GRID REAL ON THE WEB (the load-bearing engineering)
25
+ `grid_tokens.py` emits this whole scaffold correctly; the rules below are why it's built the way it is.
26
+
27
+ ### 2.1 One source of truth
28
+ Put every grid parameter in `:root` CSS variables — `--cols, --gutter, --margin, --bl (baseline), --lh (leading=3×bl), --maxw`. **Content and the overlay both read these same variables.** Never hand-author the overlay separately or it will drift.
29
+
30
+ ### 2.2 The overlay MUST live in the SAME content box as the content ← #1 bug
31
+ Failure mode: content sits in a centered `max-width` container while the overlay is a **full-width sibling** of the section. On any viewport wider than `--maxw`, the centered content and the full-width overlay no longer share column positions → "slapped on top / misaligned."
32
+ **Fix:** put `.guides` *inside* the same `.wrap`, and draw the column guides with `left/right = var(--margin)` and the **same** `repeat(var(--cols),1fr)` + `column-gap:var(--gutter)`. Then the overlay columns **are** the content columns at every width. Add left/right margin lines at `var(--margin)`.
33
+
34
+ ### 2.3 Place every element by column LINE via subgrid bands
35
+ Don't eyeball spans. Each horizontal **band** spans all columns and re-exposes them:
36
+ ```css
37
+ .band{grid-column:1 / -1; display:grid; grid-template-columns:subgrid; column-gap:var(--gutter); align-items:start;}
38
+ @supports not (grid-template-columns:subgrid){ .band{grid-template-columns:repeat(var(--cols),1fr);} }
39
+ ```
40
+ Children place with `grid-column: <startline> / <endline>` (e.g. `1 / 6`, `6 / 13`). Every headline, paragraph, photo, caption now snaps to identical lines.
41
+
42
+ ### 2.4 Lock vertical rhythm to the baseline
43
+ - Leading = `--lh` (e.g. 24px = 3×8). **Every line-height a multiple of the baseline, in px (not unitless) for display type** — unitless line-heights on large type push the box off the grid.
44
+ - Every margin/padding a multiple of the baseline. Spread top/bottom padding a multiple too, so content starts on a line.
45
+ - **Media heights = multiples of the leading** (e.g. 240/360/432/480px) so a photo's top AND bottom both land on lines.
46
+ - Hairline rules sit inside a baseline-height band, not free-floating.
47
+
48
+ ### 2.5 The toggle (sizzle within the sizzle)
49
+ A control (button **+ `G` key**) toggles `body.grid-on`; overlay fades 0→1. Overlay draws: translucent **numbered column fields**, the **baseline** (major line every `--lh`, faint minor every `--bl`), and **margin lines**. Showing the real grid the page is built on IS the demo.
50
+
51
+ ### 2.6 OPTICAL ALIGNMENT — display ink, not its box ← the subtle bug
52
+ A 180px headline whose layout box is exactly on line 1 still looks misaligned against body text, because the letterform's **ink** is inset by its **left side-bearing**. Cure at runtime:
53
+ ```js
54
+ // after document.fonts.ready and on resize:
55
+ var cvs=document.createElement('canvas'),ctx=cvs.getContext('2d');
56
+ document.querySelectorAll('.masthead,.numeral,.shead h2,.h2b').forEach(function(el){
57
+ el.style.marginLeft='0px';
58
+ var cs=getComputedStyle(el),ch=(el.textContent||'').trim()[0]; if(!ch) return;
59
+ if(cs.textTransform==='uppercase') ch=ch.toUpperCase();
60
+ ctx.font=cs.fontStyle+' '+cs.fontWeight+' '+cs.fontSize+' '+cs.fontFamily; ctx.textAlign='left';
61
+ var abl=ctx.measureText(ch).actualBoundingBoxLeft; // +ve = ink overhangs left of box
62
+ if(isFinite(abl)) el.style.marginLeft=abl.toFixed(2)+'px'; // shift box so INK lands on the line
63
+ });
64
+ ```
65
+ Apply to the masthead, big numerals, and section headlines. It scales with fluid type (re-runs on resize) and uses the **actually-loaded** font, so it's correct in the user's browser.
66
+ **CRITICAL measurement caveat:** side-bearing is **font-specific**. If you measure with the wrong font you get the wrong nudge. Headless/sandbox Chrome usually lacks the webfont, so canvas falls back to a different grotesque (measured **−16px on the fallback vs −7px on real Inter** for the same `H`). To verify optics offline you must **embed the real webfont** via `@font-face` (local TTF). In production the runtime JS measures the loaded font and is correct.
67
+
68
+
69
+ ## PART 3 — VERIFY (don't trust, measure) → `verify_grid.js`
70
+ Render with headless Chrome (Puppeteer) and assert, at **several widths including > and < `--maxw`** (to catch centered-container drift, e.g. 1440 / 1180 / 900):
71
+ 1. **Column adherence** — every placed `.band > *` left snaps to a column START and right to a column END (~0px). **Exclude the optically-aligned display elements** from this box check (their box is intentionally side-bearing-offset; they're validated in step 4). **Gotcha:** build BOTH the column-start set and the column-end set — a grid item spanning "to line N" ends at the *far* side of the gutter, so single-edge math falsely reports a one-gutter error.
72
+ 2. **Overlay match** — each `.guides .col` rect equals the computed column rect (~0px).
73
+ 3. **Baseline** — text tops modulo the baseline ≈ 0 (tolerance ≈ half a baseline; the box-top is a proxy — the leading does the real work).
74
+ 4. **Optical ink** — each display element's ink-left (box − `actualBoundingBoxLeft`, real font) equals **its own** column line (nearest column-start to its box), not always line 1.
75
+
76
+ Sandbox Chrome flags that work: `--headless=new --no-sandbox --disable-gpu --disable-dbus --use-gl=angle --use-angle=swiftshader`. `file://` works for non-ES-module pages; the CLI `--screenshot` can hang on tall pages — drive via Puppeteer and screenshot per viewport. Read PNGs back with the image-capable Read tool to eyeball a **zoom crop of the top-left corner** (masthead vs body vs column line) — the fastest human check.
77
+
78
+ A clean run looks like: `col=0px overlay=0px baseline≤4px ink=0px` → `GRID VERIFY: PASS`.
79
+
80
+
81
+ ## PART 4 — CRAFT DEFAULTS (so it looks excellent, not just aligned)
82
+ - **Palette:** white `#fff`, ink `#111`, one accent (Swiss red `#e4002b`). No warm-cream Claude look; no blue/purple gradients.
83
+ - **Type:** a real grotesque webfont (Inter / Helvetica Now / Archivo) for display + body; a **mono** (Space Mono / IBM Plex Mono) for folios, captions, grid annotations — reinforces the technical register. Non-Latin via Noto Sans JP etc.
84
+ - **Hierarchy** through scale + weight + white space, not color. Treat key data as **large numerals**. Kicker labels in mono caps. Per-spread folios.
85
+ - **Real photography.** Ground real subjects in real photos (`SearchImages`). **Host each image via `PublishFilePublicly` and embed the `pub.hyperagent.com` URL** — a `PublishWebpage` artifact runs in a sandboxed iframe that can't authenticate thread-scoped `/api/files/...` URLs (broken-image trap).
86
+ - **Type fidelity if you ever rasterize art** (cairosvg / headless screenshots / image-gen reference): a `Helvetica`/`Arial` CSS stack silently falls back to **Noto Sans** (reads like Calibri). Render in **Liberation Sans** or an embedded Helvetica/Arimo TTF before trusting it. (Same trap as the optical-measurement caveat: wrong font in → wrong result out.)
87
+ - **Spread model:** full-width sections, each its own per-spread `.grid` + `.guides`, consistent margins/folios.
88
+
89
+
90
+ ## PART 5 — WORKFLOW
91
+ 1. Pick the subject; gather real photos; host them publicly.
92
+ 2. Generate the scaffold: `python3 grid_tokens.py` (or `--scaffold` for a full page; `--cols/--baseline/--gutter/--margin/--maxw/--accent` to taste; it warns if gutter/margin aren't baseline multiples).
93
+ 3. Build spreads as **subgrid bands**; place everything by **column line**; lock spacing/line-heights/media heights to the **baseline**.
94
+ 4. Add the overlay (same content box) + toggle + optical-alignment JS (already in the scaffold; point its selector list at your display elements).
95
+ 5. Publish, then **verify**: `CHROME=… PUP=… node verify_grid.js <file-or-url> --widths=1440,1180,900`. Eyeball a top-left zoom crop. Fix, republish.
96
+
97
+ ## SCRIPTS
98
+ - **`grid_tokens.py`** — deterministic scaffold generator. Emits the `:root` tokens, `.grid`/`.band` (subgrid) scaffold, `.guides` overlay CSS, toggle JS, and the optical-alignment JS — all wired to one source of truth. `--scaffold` emits a full minimal HTML page. No network/credentials.
99
+ - **`verify_grid.js`** — Puppeteer harness implementing all four checks above with the corrected both-edges column math, the optical-exclusion, per-element column-line ink targeting, and PASS/FAIL output at multiple widths. Env: `CHROME` (chrome binary), `PUP` (puppeteer-core module path).
100
+
101
+ ## CREED
102
+ A grid you can't toggle on and measure is a mood board, not a system. Build it from one source of truth, prove it at 0px, and align the **ink**.
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Chain multiple bigpowers skills into a custom workflow recipe saved in specs/. Use when a project repeats a non-standard skill sequence, or user wants a documented playbook beyond orchestrate-project modes.model: sonnet
2
+ description: Chain multiple bigpowers skills into a custom workflow recipe saved in specs/. Use when a project repeats a non-standard skill sequence, or user wants a documented playbook beyond orchestrate-project modes.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Run 4-phase root cause analysis — reproduce, isolate, hypothesize, verify. Use when a bug is confirmed but root cause is unclear, after investigate-bug, or when user mentions root cause analysis.model: sonnet
2
+ description: Run 4-phase root cause analysis — reproduce, isolate, hypothesize, verify. Use when a bug is confirmed but root cause is unclear, after investigate-bug, or when user mentions root cause analysis.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Benchmark-gated skill evolution — consume bigpowers-benchmark report, propose plan-work change, edit skill via craft-skill, re-run benchmark, record ADR. Use when a skill underperforms on benchmark or stocktake finds systemic gap.model: opus
2
+ description: Benchmark-gated skill evolution — consume bigpowers-benchmark report, propose plan-work change, edit skill via craft-skill, re-run benchmark, record ADR. Use when a skill underperforms on benchmark or stocktake finds systemic gap.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Doc-grounded variant of grill-me — stress-tests plan assumptions by fetching and citing real library or API documentation. Every challenge must cite a real URL. Use when the plan depends on a specific library or external API.model: opus
2
+ description: Doc-grounded variant of grill-me — stress-tests plan assumptions by fetching and citing real library or API documentation. Every challenge must cite a real URL. Use when the plan depends on a specific library or external API.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Look-before-build — search registries, repo, existing skills, and web for prior art before implementing. Appends Prior Art to the spec. Use after survey-context and before elaborate-spec, when adding dependencies, or when the task may already be solved.model: sonnet
2
+ description: Look-before-build — search registries, repo, existing skills, and web for prior art before implementing. Appends Prior Art to the spec. Use after survey-context and before elaborate-spec, when adding dependencies, or when the task may already be solved.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Restore the project to a known clean state between agent runs or experiments. Use between benchmark runs, after a failed spike, or when user wants a clean working tree.model: haiku
2
+ description: Restore the project to a known clean state between agent runs or experiments. Use between benchmark runs, after a failed spike, or when user wants a clean working tree.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Eval-Driven Development — define capability and regression evals before building; code graders use verify commands, model graders use explicit rubrics; log pass@k. Use before develop-tdd on new features, or when measuring agent capability over runs.model: sonnet
2
+ description: Eval-Driven Development — define capability and regression evals before building; code graders use verify commands, model graders use explicit rubrics; log pass@k. Use before develop-tdd on new features, or when measuring agent capability over runs.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: "PLANNING SPINE STEP 1 of 3 — Scope the work: define what is in and out of scope and save as specs/product/SCOPE_LATEST.yaml. Use before slice-tasks or plan-release on any new initiative. Not a substitute for slice-tasks (step 2) or plan-work (step 3)."model: sonnet
2
+ description: "PLANNING SPINE STEP 1 of 3 — Scope the work: define what is in and out of scope and save as specs/product/SCOPE_LATEST.yaml. Use before slice-tasks or plan-release on any new initiative. Not a substitute for slice-tasks (step 2) or plan-work (step 3)."
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Find the right bigpowers skill from natural-language intent using a local lexical index over SKILL.md frontmatter. Use when unsure which skill to invoke, or at start of research-first.model: haiku
2
+ description: Find the right bigpowers skill from natural-language intent using a local lexical index over SKILL.md frontmatter. Use when unsure which skill to invoke, or at start of research-first.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Pre-install dependencies and configure tools before development work begins. Use at session start on a fresh clone, before kickoff-branch, or when user says setup environment or install deps.model: haiku
2
+ description: Pre-install dependencies and configure tools before development work begins. Use at session start on a fresh clone, before kickoff-branch, or when user says setup environment or install deps.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Run Mock User and Auditor agents against a feature in fresh contexts before human review. Use after verify-work, before request-review, when user wants pre-review simulation.model: sonnet
2
+ description: Run Mock User and Auditor agents against a feature in fresh contexts before human review. Use after verify-work, before request-review, when user wants pre-review simulation.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: "PLANNING SPINE STEP 2 of 3 — Slice the work: break a scoped PRD into vertical-slice stories in specs/epics/. Use after scope-work (step 1), before plan-work (step 3). Not a substitute for scope-work or plan-work."model: sonnet
2
+ description: "PLANNING SPINE STEP 2 of 3 — Slice the work: break a scoped PRD into vertical-slice stories in specs/epics/. Use after scope-work (step 1), before plan-work (step 3). Not a substitute for scope-work or plan-work."
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Sequential subagent batch audit of the bigpowers skill catalog — Quick Scan (changed only) or Full (all skills). Use during sustain phase, before a major release, or when catalog drift is suspected.model: sonnet
2
+ description: Sequential subagent batch audit of the bigpowers skill catalog — Quick Scan (changed only) or Full (all skills). Use during sustain phase, before a major release, or when catalog drift is suspected.
3
3
  ---
4
4
 
5
5
 
@@ -1,5 +1,5 @@
1
1
  ---
2
- description: Multi-phase UAT gate — cold-start smoke, build, typecheck, lint, tests, step-by-step manual verification, gaps-closure loop. Use after execute-plan or develop-tdd, before audit-code.model: haiku
2
+ description: Multi-phase UAT gate — cold-start smoke, build, typecheck, lint, tests, step-by-step manual verification, gaps-closure loop. Use after execute-plan or develop-tdd, before audit-code.
3
3
  ---
4
4
 
5
5
 
@@ -0,0 +1,104 @@
1
+ ---
2
+ name: align-grid
3
+ description: "\"Build editorial/magazine/report webpages on a GENUINE Müller-Brockmann modular grid (International Typographic Style) — not a decorative one. Encodes the discipline (columns + modules + baseline, grotesque type, flush-left, restrained black/white/red palette) AND the hard-won front-end engineering to make the grid real, visible, and verified: one CSS-variable source of truth, an interactive grid-toggle overlay that lives in the SAME content box as the content, subgrid \\\"bands\\\" so every element snaps to a column line, an 8px baseline lock, and runtime OPTICAL ALIGNMENT that puts display type's ink (not its box) on the line. Ships with a scaffold generator and a Puppeteer verification harness that proves 0px adherence.\""
4
+ model: sonnet
5
+ ---
6
+
7
+
8
+ # Müller-Brockmann Grid Systems — built real, visible, and verified
9
+
10
+ Josef Müller-Brockmann (1914–1996), Zurich; *Grid Systems in Graphic Design* (1981) is the corpus. The grid is treated as an ethic, not decoration: **"The grid system is an aid, not a guarantee. It permits a number of possible uses and each designer can look for a solution appropriate to his personal style. But one must learn how to use the grid; it is an art that requires practice."** This skill encodes that discipline AND — the part most attempts get wrong — the front-end engineering to make the grid genuinely load-bearing on the web, plus a harness that PROVES it.
11
+
12
+ > Two real review notes this skill exists to prevent:
13
+ > 1. *"the grid is just slapped on top and misaligned"* → the overlay wasn't in the same content box as the content (see §2.2).
14
+ > 2. *"the H in the headline is off the grid"* → the headline's BOX was on the grid but its INK wasn't; large glyphs carry a side-bearing (see §2.6). **Box-on-grid ≠ ink-on-grid.**
15
+
16
+
17
+ ## PART 1 — THE DISCIPLINE (decide before drawing)
18
+ - **Objective order.** The grid brings "constructive thought," legibility, and "objective and functional" design. Restraint is the point; the system, not the ego, organizes the page.
19
+ - **Modular grid.** Divide the type area into a field of **modules** — columns AND rows — separated by consistent **gutters**, inside defined **margins**. Text and images occupy whole modules. Müller-Brockmann specimens common field counts (8 / 20 / 32 fields). For the web, a **12-column grid + 8px baseline** is a robust general default; a **6×6 or 4×8 modular field grid** when you want visible rows too.
20
+ - **Baseline grid.** Vertical rhythm is sacred: **leading = a whole multiple of the baseline unit**, and every element snaps to it. This is what makes facing columns and images line up across the page.
21
+ - **Typography.** A **grotesque sans** (Akzidenz-Grotesk / Helvetica; on the web Inter, Helvetica Now, Archivo). **Flush-left, ragged-right.** Few sizes, large jumps in **scale** for hierarchy; objective, not expressive. Big **numerals/data set large** is a signature move.
22
+ - **Palette.** Pure white paper, near-black ink, **one accent — red is canonical**. Avoid the warm-cream "Claude look"; **never blue/purple gradients** (hard house rule).
23
+ - **White space + asymmetry.** Generous margins; asymmetric compositions held in tension by the grid.
24
+
25
+
26
+ ## PART 2 — MAKE THE GRID REAL ON THE WEB (the load-bearing engineering)
27
+ `grid_tokens.py` emits this whole scaffold correctly; the rules below are why it's built the way it is.
28
+
29
+ ### 2.1 One source of truth
30
+ Put every grid parameter in `:root` CSS variables — `--cols, --gutter, --margin, --bl (baseline), --lh (leading=3×bl), --maxw`. **Content and the overlay both read these same variables.** Never hand-author the overlay separately or it will drift.
31
+
32
+ ### 2.2 The overlay MUST live in the SAME content box as the content ← #1 bug
33
+ Failure mode: content sits in a centered `max-width` container while the overlay is a **full-width sibling** of the section. On any viewport wider than `--maxw`, the centered content and the full-width overlay no longer share column positions → "slapped on top / misaligned."
34
+ **Fix:** put `.guides` *inside* the same `.wrap`, and draw the column guides with `left/right = var(--margin)` and the **same** `repeat(var(--cols),1fr)` + `column-gap:var(--gutter)`. Then the overlay columns **are** the content columns at every width. Add left/right margin lines at `var(--margin)`.
35
+
36
+ ### 2.3 Place every element by column LINE via subgrid bands
37
+ Don't eyeball spans. Each horizontal **band** spans all columns and re-exposes them:
38
+ ```css
39
+ .band{grid-column:1 / -1; display:grid; grid-template-columns:subgrid; column-gap:var(--gutter); align-items:start;}
40
+ @supports not (grid-template-columns:subgrid){ .band{grid-template-columns:repeat(var(--cols),1fr);} }
41
+ ```
42
+ Children place with `grid-column: <startline> / <endline>` (e.g. `1 / 6`, `6 / 13`). Every headline, paragraph, photo, caption now snaps to identical lines.
43
+
44
+ ### 2.4 Lock vertical rhythm to the baseline
45
+ - Leading = `--lh` (e.g. 24px = 3×8). **Every line-height a multiple of the baseline, in px (not unitless) for display type** — unitless line-heights on large type push the box off the grid.
46
+ - Every margin/padding a multiple of the baseline. Spread top/bottom padding a multiple too, so content starts on a line.
47
+ - **Media heights = multiples of the leading** (e.g. 240/360/432/480px) so a photo's top AND bottom both land on lines.
48
+ - Hairline rules sit inside a baseline-height band, not free-floating.
49
+
50
+ ### 2.5 The toggle (sizzle within the sizzle)
51
+ A control (button **+ `G` key**) toggles `body.grid-on`; overlay fades 0→1. Overlay draws: translucent **numbered column fields**, the **baseline** (major line every `--lh`, faint minor every `--bl`), and **margin lines**. Showing the real grid the page is built on IS the demo.
52
+
53
+ ### 2.6 OPTICAL ALIGNMENT — display ink, not its box ← the subtle bug
54
+ A 180px headline whose layout box is exactly on line 1 still looks misaligned against body text, because the letterform's **ink** is inset by its **left side-bearing**. Cure at runtime:
55
+ ```js
56
+ // after document.fonts.ready and on resize:
57
+ var cvs=document.createElement('canvas'),ctx=cvs.getContext('2d');
58
+ document.querySelectorAll('.masthead,.numeral,.shead h2,.h2b').forEach(function(el){
59
+ el.style.marginLeft='0px';
60
+ var cs=getComputedStyle(el),ch=(el.textContent||'').trim()[0]; if(!ch) return;
61
+ if(cs.textTransform==='uppercase') ch=ch.toUpperCase();
62
+ ctx.font=cs.fontStyle+' '+cs.fontWeight+' '+cs.fontSize+' '+cs.fontFamily; ctx.textAlign='left';
63
+ var abl=ctx.measureText(ch).actualBoundingBoxLeft; // +ve = ink overhangs left of box
64
+ if(isFinite(abl)) el.style.marginLeft=abl.toFixed(2)+'px'; // shift box so INK lands on the line
65
+ });
66
+ ```
67
+ Apply to the masthead, big numerals, and section headlines. It scales with fluid type (re-runs on resize) and uses the **actually-loaded** font, so it's correct in the user's browser.
68
+ **CRITICAL measurement caveat:** side-bearing is **font-specific**. If you measure with the wrong font you get the wrong nudge. Headless/sandbox Chrome usually lacks the webfont, so canvas falls back to a different grotesque (measured **−16px on the fallback vs −7px on real Inter** for the same `H`). To verify optics offline you must **embed the real webfont** via `@font-face` (local TTF). In production the runtime JS measures the loaded font and is correct.
69
+
70
+
71
+ ## PART 3 — VERIFY (don't trust, measure) → `verify_grid.js`
72
+ Render with headless Chrome (Puppeteer) and assert, at **several widths including > and < `--maxw`** (to catch centered-container drift, e.g. 1440 / 1180 / 900):
73
+ 1. **Column adherence** — every placed `.band > *` left snaps to a column START and right to a column END (~0px). **Exclude the optically-aligned display elements** from this box check (their box is intentionally side-bearing-offset; they're validated in step 4). **Gotcha:** build BOTH the column-start set and the column-end set — a grid item spanning "to line N" ends at the *far* side of the gutter, so single-edge math falsely reports a one-gutter error.
74
+ 2. **Overlay match** — each `.guides .col` rect equals the computed column rect (~0px).
75
+ 3. **Baseline** — text tops modulo the baseline ≈ 0 (tolerance ≈ half a baseline; the box-top is a proxy — the leading does the real work).
76
+ 4. **Optical ink** — each display element's ink-left (box − `actualBoundingBoxLeft`, real font) equals **its own** column line (nearest column-start to its box), not always line 1.
77
+
78
+ Sandbox Chrome flags that work: `--headless=new --no-sandbox --disable-gpu --disable-dbus --use-gl=angle --use-angle=swiftshader`. `file://` works for non-ES-module pages; the CLI `--screenshot` can hang on tall pages — drive via Puppeteer and screenshot per viewport. Read PNGs back with the image-capable Read tool to eyeball a **zoom crop of the top-left corner** (masthead vs body vs column line) — the fastest human check.
79
+
80
+ A clean run looks like: `col=0px overlay=0px baseline≤4px ink=0px` → `GRID VERIFY: PASS`.
81
+
82
+
83
+ ## PART 4 — CRAFT DEFAULTS (so it looks excellent, not just aligned)
84
+ - **Palette:** white `#fff`, ink `#111`, one accent (Swiss red `#e4002b`). No warm-cream Claude look; no blue/purple gradients.
85
+ - **Type:** a real grotesque webfont (Inter / Helvetica Now / Archivo) for display + body; a **mono** (Space Mono / IBM Plex Mono) for folios, captions, grid annotations — reinforces the technical register. Non-Latin via Noto Sans JP etc.
86
+ - **Hierarchy** through scale + weight + white space, not color. Treat key data as **large numerals**. Kicker labels in mono caps. Per-spread folios.
87
+ - **Real photography.** Ground real subjects in real photos (`SearchImages`). **Host each image via `PublishFilePublicly` and embed the `pub.hyperagent.com` URL** — a `PublishWebpage` artifact runs in a sandboxed iframe that can't authenticate thread-scoped `/api/files/...` URLs (broken-image trap).
88
+ - **Type fidelity if you ever rasterize art** (cairosvg / headless screenshots / image-gen reference): a `Helvetica`/`Arial` CSS stack silently falls back to **Noto Sans** (reads like Calibri). Render in **Liberation Sans** or an embedded Helvetica/Arimo TTF before trusting it. (Same trap as the optical-measurement caveat: wrong font in → wrong result out.)
89
+ - **Spread model:** full-width sections, each its own per-spread `.grid` + `.guides`, consistent margins/folios.
90
+
91
+
92
+ ## PART 5 — WORKFLOW
93
+ 1. Pick the subject; gather real photos; host them publicly.
94
+ 2. Generate the scaffold: `python3 grid_tokens.py` (or `--scaffold` for a full page; `--cols/--baseline/--gutter/--margin/--maxw/--accent` to taste; it warns if gutter/margin aren't baseline multiples).
95
+ 3. Build spreads as **subgrid bands**; place everything by **column line**; lock spacing/line-heights/media heights to the **baseline**.
96
+ 4. Add the overlay (same content box) + toggle + optical-alignment JS (already in the scaffold; point its selector list at your display elements).
97
+ 5. Publish, then **verify**: `CHROME=… PUP=… node verify_grid.js <file-or-url> --widths=1440,1180,900`. Eyeball a top-left zoom crop. Fix, republish.
98
+
99
+ ## SCRIPTS
100
+ - **`grid_tokens.py`** — deterministic scaffold generator. Emits the `:root` tokens, `.grid`/`.band` (subgrid) scaffold, `.guides` overlay CSS, toggle JS, and the optical-alignment JS — all wired to one source of truth. `--scaffold` emits a full minimal HTML page. No network/credentials.
101
+ - **`verify_grid.js`** — Puppeteer harness implementing all four checks above with the corrected both-edges column math, the optical-exclusion, per-element column-line ink targeting, and PASS/FAIL output at multiple widths. Env: `CHROME` (chrome binary), `PUP` (puppeteer-core module path).
102
+
103
+ ## CREED
104
+ A grid you can't toggle on and measure is a mood board, not a system. Build it from one source of truth, prove it at 0px, and align the **ink**.
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: assess-impact
3
- description: "Analyze the blast radius of a proposed change before any code is written. Maps dependents, affected stories, and test coverage. Produces specs/IMPACT.md. Use before plan-work on any non-trivial change, when touching a shared module, or when the user asks "what does this break?"."
3
+ description: "Analyze the blast radius of a proposed change before any code is written. Maps dependents, affected stories, and test coverage. Produces specs/IMPACT.md. Use before plan-work on any non-trivial change, when touching a shared module, or when the user asks \"what does this break?\"."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: audit-code
3
3
  description: "Self-review checklist for the coding agent to run before dispatching a reviewer. Checks CONVENTIONS.md compliance, Boy Scout Rule, test coverage, types, and SOLID. Produces a pass/fail checklist. Use before request-review, before committing, or when user asks for a code quality check."
4
+ model: haiku
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: build-epic
3
3
  description: "Eight-step epic build cycle — reads state.yaml, execution-status.yaml, and one epic capsule; updates status via bp-yaml-set or direct edit. Resume mode runs one step per invocation. Use instead of ad-hoc execute-plan for release work."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: change-request
3
3
  description: "Add a new requirement or reorder epics by WSJF against specs/release-plan.yaml and epic capsule directories. Modes Add and Reorder. Use when a new requirement arrives mid-release or the plan needs prioritization."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: commit-message
3
3
  description: "Reviews working-tree changes, then drafts a Conventional Commits title/body and states the semantic-release version bump a single such commit would imply. Also notes which defensive-code categories were touched. Use when the user wants to commit recent work, prepare a Conventional Commits message, or asks for semantic-release / semver-consistent messaging before git commit."
4
+ model: haiku
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: compose-workflow
3
- description: "Chain multiple bigpowers skills into a custom workflow recipe saved in specs/. Use when a project repeats a non-standard skill sequence, or user wants a documented playbook beyond orchestrate-project modes.model: sonnet"
3
+ description: "Chain multiple bigpowers skills into a custom workflow recipe saved in specs/. Use when a project repeats a non-standard skill sequence, or user wants a documented playbook beyond orchestrate-project modes."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: craft-skill
3
3
  description: "Create new bigpowers skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill for the bigpowers lifecycle."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: deepen-architecture
3
3
  description: "Find deepening opportunities in a codebase, informed by the domain language in specs/tech-architecture/tech-stack.md and the decisions in specs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: define-language
3
- description: "Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to specs/UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD"."
3
+ description: "Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to specs/UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \"domain model\" or \"DDD\"."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: define-success
3
- description: "Convert an imperative task statement into explicit "step → verify: <cmd>" pairs before implementation begins. Use before plan-work when success criteria are unclear, when a task lacks verifiable checkpoints, or when user says "how will we know this is done?"."
3
+ description: "Convert an imperative task statement into explicit \"step → verify: <cmd>\" pairs before implementation begins. Use before plan-work when success criteria are unclear, when a task lacks verifiable checkpoints, or when user says \"how will we know this is done?\"."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: delegate-task
3
3
  description: "Delegate one complex task to a single subagent, review its work in two stages before merging back. Sequential — one agent at a time, with oversight. Use when a task is complex and requires careful review before the result is accepted. Distinct from dispatch-agents (no parallelism here; reviewer sees full diff before proceeding)."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: design-interface
3
- description: "Generate multiple radically different interface designs for a module using parallel sub-agents, then compare trade-offs. Based on "Design It Twice" from A Philosophy of Software Design. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice"."
3
+ description: "Generate multiple radically different interface designs for a module using parallel sub-agents, then compare trade-offs. Based on \"Design It Twice\" from A Philosophy of Software Design. Use when user wants to design an API, explore interface options, compare module shapes, or mentions \"design it twice\"."
4
+ model: opus
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: develop-tdd
3
3
  description: "Test-driven development with red-green-refactor loop using vertical slices. Use for features (epic tasks) or bugs (specs/bugs/BUG-*.md)."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: diagnose-root
3
- description: "Run 4-phase root cause analysis — reproduce, isolate, hypothesize, verify. Use when a bug is confirmed but root cause is unclear, after investigate-bug, or when user mentions root cause analysis.model: sonnet"
3
+ description: "Run 4-phase root cause analysis — reproduce, isolate, hypothesize, verify. Use when a bug is confirmed but root cause is unclear, after investigate-bug, or when user mentions root cause analysis."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: dispatch-agents
3
3
  description: "Dispatch multiple subagents in parallel on independent tasks. No waiting between them — all run concurrently. Use when tasks are truly decoupled and speed matters. Distinct from delegate-task (concurrent here, no inter-task review gate)."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: edit-document
3
3
  description: "Edit and improve documents by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, restructure, or improve any document — including specs/ files, articles, READMEs, or technical writing."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: elaborate-spec
3
- description: "Refine a rough idea into a clear, detailed specification through dialogue. Does not produce code. Use when user has a vague idea, wants to think through a feature before planning, or needs to turn "I want X" into a concrete spec."
3
+ description: "Refine a rough idea into a clear, detailed specification through dialogue. Does not produce code. Use when user has a vague idea, wants to think through a feature before planning, or needs to turn \"I want X\" into a concrete spec."
4
+ model: opus
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: enforce-first
3
- description: "Apply the F.I.R.S.T test quality rubric (Fast, Independent, Repeatable, Self-Validating, Timely) to a test suite or individual tests. Use when develop-tdd is writing tests, when test quality needs to be checked, or when user mentions F.I.R.S.T or "test quality"."
3
+ description: "Apply the F.I.R.S.T test quality rubric (Fast, Independent, Repeatable, Self-Validating, Timely) to a test suite or individual tests. Use when develop-tdd is writing tests, when test quality needs to be checked, or when user mentions F.I.R.S.T or \"test quality\"."
4
+ model: haiku
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: evolve-skill
3
- description: "Benchmark-gated skill evolution — consume bigpowers-benchmark report, propose plan-work change, edit skill via craft-skill, re-run benchmark, record ADR. Use when a skill underperforms on benchmark or stocktake finds systemic gap.model: opus"
3
+ description: "Benchmark-gated skill evolution — consume bigpowers-benchmark report, propose plan-work change, edit skill via craft-skill, re-run benchmark, record ADR. Use when a skill underperforms on benchmark or stocktake finds systemic gap."
4
+ model: opus
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: execute-plan
3
3
  description: "Batch-execute tasks from the active epic capsule sequentially, with a human checkpoint after each step. Use when user has an approved plan and wants step-by-step oversight."
4
+ model: haiku
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: fix-bug
3
3
  description: "Bug fix orchestrator — active_flow fix_bug; reads specs/bugs/BUG-*.md; chains investigate-bug, develop-tdd, validate-fix. Use when user reports a defect."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: grill-me
3
- description: "Interactive assumption-surfacing Q&A that stress-tests a plan through relentless questioning until every decision is resolved. Use when user wants to challenge a plan, validate decisions from conversation/context, or mentions "grill me". For doc-grounded variant, use grill-with-docs."
3
+ description: "Interactive assumption-surfacing Q&A that stress-tests a plan through relentless questioning until every decision is resolved. Use when user wants to challenge a plan, validate decisions from conversation/context, or mentions \"grill me\". For doc-grounded variant, use grill-with-docs."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: grill-with-docs
3
- description: "Doc-grounded variant of grill-me — stress-tests plan assumptions by fetching and citing real library or API documentation. Every challenge must cite a real URL. Use when the plan depends on a specific library or external API.model: opus"
3
+ description: "Doc-grounded variant of grill-me — stress-tests plan assumptions by fetching and citing real library or API documentation. Every challenge must cite a real URL. Use when the plan depends on a specific library or external API."
4
+ model: opus
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: guard-git
3
3
  description: "Block dangerous git commands (push, force push, reset --hard, clean, branch -D, checkout/restore .) and enforce Conventional Commits & Branch Protection before an AI agent runs them. Installs hook scripts for Claude Code, Cursor, Cursor CLI, and Gemini CLI; documents Google Antigravity Terminal deny lists. Use when the user wants git safety hooks, to block git push or destructive git in agents, or to mirror the same policy across AI coding tools."
4
+ model: haiku
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: hook-commits
3
3
  description: "Set up pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing."
4
+ model: haiku
4
5
  ---
5
6
 
6
7
 
@@ -1,6 +1,7 @@
1
1
  ---
2
2
  name: inspect-quality
3
- description: "Interactive QA session where user reports bugs or issues conversationally, and the agent logs them to specs/bugs/registry.yaml with a structured audit schema. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, or mentions "QA session"."
3
+ description: "Interactive QA session where user reports bugs or issues conversationally, and the agent logs them to specs/bugs/registry.yaml with a structured audit schema. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, or mentions \"QA session\"."
4
+ model: sonnet
4
5
  ---
5
6
 
6
7