chore: add agentic development toolkit

.agents/skills/groom/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: groom
+description: Groom a box-box GitHub issue into a Ready spec via a seeded grill-me interrogation. Use when the user asks to groom an issue, for example "/groom <issue-number>" or "$groom <issue-number>" with optional "--lens architect". Single-issue path: asks targeted questions, writes a structured spec into the issue body, sets Effort/Priority, and leaves Stage at Research for approval.
+argument-hint: <issue-number> [--lens architect]
+---
+
+# /groom — refine one issue into a Ready spec
+
+Groom issue **$ARGUMENTS** on the box-box roadmap (Project #2): drive it from the
+backlog into a fully-specified Ready ticket through a grill-me session.
+
+## 0. Setup
+- Parse the first token of the arguments as the **issue number**. An optional
+  `--lens <name>` pulls in a lens overlay (currently: `architect`).
+- Run: `source .agents/lib/gh.sh && project_refresh` (fresh field/item state).
+- Load context **before asking anything**: `issue_json <n>`, read `CLAUDE.md`, and
+  explore the code paths the issue implicates.
+- Move it into grooming if it isn't already there: `set_stage <n> Research`.
+
+## 1. Grill
+- Read `.agents/personas/grill.md`. If `--lens <name>` was given, also read
+  `.agents/personas/<name>.md` and apply it on top.
+- Run the grill exactly per those rules: **one question at a time**, recommendation
+  first, **hybrid** asking (AskUserQuestion for discrete decisions with the
+  recommended option first and labelled "(Recommended)"; prose for open-ended), and
+  **explore the code to self-answer** wherever possible — only ask about genuine forks.
+- Track the resolved decisions as you go.
+
+## 2. Synthesize
+- When no open branches remain, summarize the shared design concept in 3–6 bullets and
+  confirm it with the user.
+- Then invoke the **write-spec** skill for issue `<n>`, handing it the resolved
+  decisions, so it renders `.agents/prompts/ready-spec.md` into the issue body and
+  sets Effort + Priority.
+
+## 3. Hand back (human gate)
+- Do **not** auto-advance to Ready — that's the user's call. Report that the spec is
+  written, Stage is `Research`, and they should review the issue and flip Stage →
+  `Ready` when satisfied (`set_stage <n> Ready`).
+- Print the issue URL (`issue_url <n>`).
+
+Stay focused on THIS issue's design throughout. Note but don't chase out-of-scope ideas.

.agents/skills/implement/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: implement
+description: Dispatch a Ready box-box issue to a coding harness (claude/codex/opencode/pi/cursor) in an isolated git worktree, run the build gate, and open a PR. Use when supervising implementation via "/implement <issue-number> --harness <name> [--dry-run]" or from any harness terminal with .agents/bin/dev.
+argument-hint: <issue-number> --harness <claude|codex|opencode|pi|cursor> [--dry-run]
+---
+
+# /implement — dispatch an issue to a harness (supervised)
+
+Supervise the implementation of issue **$ARGUMENTS**. You are SUPERVISING, not coding —
+a fresh harness does the work in its own isolated worktree with clean context. Do not
+edit project files yourself.
+
+## Steps
+1. Parse: `<issue-number> --harness <name> [--dry-run] [--base <branch>]`.
+2. **Preflight (report, don't hard-block):** `source .agents/lib/gh.sh` and check
+   `get_field <n> Stage` is `Ready` and the issue body has an "## Acceptance Criteria"
+   section (a groomed spec). If it's not Ready or has no spec, say so and recommend
+   `/groom <n>` first — proceed only if the user confirms.
+3. **Dispatch:** run `.agents/bin/dev implement <n> --harness <name> [flags]`. For a
+   first run against an unfamiliar harness, suggest `--dry-run` first so the user can
+   eyeball the prompt.
+4. **Report the outcome:** branch, worktree path, gate result (pass/FAILED → draft PR),
+   and the PR URL. On success, Stage will be `In Review`.
+5. If no PR was created (no changes, or push failed), surface exactly why and point at
+   the worktree (`.worktrees/issue-<n>`) so the user can inspect. Diagnose from the
+   dispatcher output; recommend a fix or re-run — don't silently take over the coding.
+
+## Notes
+- The harness adapters and the gate live in `.agents/harnesses.sh` — the single place
+  to tune per-tool flags.
+- From any harness shell, run the same thing directly:
+  `.agents/bin/dev implement <n> --harness <name>`.

.agents/skills/lens-architect/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: lens-architect
+description: Grill/analyze a box-box issue or epic from a software-architecture perspective and post the findings as a comment. Use standalone as "/lens-architect <issue-number>" for an on-the-fly architecture review, or let /groom compose it via "--lens architect". Reads the base grill + architect persona and focuses on reuse, data flow, seams, testability, and risk.
+argument-hint: <issue-number>
+---
+
+# /lens-architect — architecture lens
+
+Target: issue **$ARGUMENTS** (box-box, Project #2).
+
+1. `source .agents/lib/gh.sh`; load context (`issue_json <n>`, `CLAUDE.md`, and the
+   relevant code paths).
+2. Read `.agents/personas/grill.md` + `.agents/personas/architect.md` and run a focused
+   grill from the architecture lens: hybrid asking (AskUserQuestion for discrete
+   decisions, recommendation first; prose otherwise), recommend every answer, and
+   explore the code to self-answer before asking.
+3. When aligned, write an **"## Architecture review"** summary (decisions taken,
+   files/seams affected, risks, the test seam) to a temp file and `add_comment <n> <file>`.
+4. Print the issue URL.
+
+If invoked from **within /groom**, skip the comment — instead return the architecture
+decisions inline so groom can fold them into the spec.

.agents/skills/review/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: review
+description: Locally review a box-box PR against its linked GitHub issue spec, run tests, capture visual screenshots when applicable, create a .review packet, and post a GitHub PR comment. Use when a ticket implementation is ready for independent local review before the human merge gate.
+argument-hint: <pr-number> [--harness <name>] [--publish-screenshots]
+---
+
+# /review — local independent PR review
+
+Review PR **$ARGUMENTS** for box-box using the local-only lifecycle. You are
+reviewing, not implementing. Do not merge the PR.
+
+## 0. Setup
+- Parse the PR number. Optional `--harness <name>` records which reviewer harness is
+  acting; optional `--publish-screenshots` allows pushing visual artifacts to a
+  dedicated artifact branch.
+- Read `.agents/prompts/review.md`, `AGENTS.md`, the PR metadata/diff, and the linked
+  issue body.
+- Identify the implementer harness from the PR body when present. If it matches the
+  reviewer harness, call that out as a reduced independence caveat.
+- Create `.review/issue-<issue>-pr-<pr>/logs`, `screenshots`, and `artifacts`.
+
+## 1. Verify
+- Run the smallest meaningful gates first, then broaden based on risk:
+  `go test` for touched Go packages, `npm run test` and `npm run build` for frontend
+  changes, and hermetic Playwright when user-facing routes changed.
+- Save all command output to `.review/issue-<issue>-pr-<pr>/logs`.
+- Inspect the diff for spec conformance, scope leaks, missing tests, and known project
+  conventions from `AGENTS.md`.
+
+## 2. Visual Packet
+- If the PR changes UI, start a local seeded or mocked preview and capture desktop and
+  mobile screenshots for affected routes.
+- Prefer hermetic mocks/seeded data over live external state.
+- Save screenshots under `.review/issue-<issue>-pr-<pr>/screenshots`.
+- Create a concise `summary.md`; create `index.html` when screenshots exist.
+
+## 3. Publish
+- If `--publish-screenshots` is present, publish only review artifacts to a dedicated
+  branch such as `review-artifacts/pr-<pr>/` and use raw GitHub URLs in the comment.
+- Post a PR comment with:
+  - reviewer harness and implementer harness
+  - result: pass, pass with caveats, or needs changes
+  - local packet path
+  - gates run and results
+  - acceptance-criteria checklist
+  - screenshots or artifact links when available
+  - caveats that the human must inspect
+- If the result is pass/pass-with-caveats, set the linked issue's custom Project
+  `Stage` to `In Review` using `.agents/lib/gh.sh`. Do not set `Done`.
+
+## 4. Hand Back
+- Tell the human exactly what to open locally and what decision remains theirs.
+- Do not merge or delete worktrees.

.agents/skills/write-spec/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: write-spec
+description: Render a groomed design into the box-box Ready-spec template and write it into a GitHub issue body, then set Effort and Priority. Called by /groom after a grill session, or run standalone as "/write-spec <issue-number>" to (re)write an issue's spec from agreed decisions. Does not change Stage.
+argument-hint: <issue-number>
+---
+
+# /write-spec — write the Ready spec into an issue
+
+Target issue: **$ARGUMENTS** (box-box, Project #2).
+
+## Steps
+1. `source .agents/lib/gh.sh`
+2. Gather the agreed design decisions: from the current grooming conversation if one
+   is in progress; otherwise ask the user for the key points, or read the issue and
+   explore the code to draft them and confirm.
+3. Read `.agents/prompts/ready-spec.md` and fill every placeholder:
+   - Concrete, **behavioural** acceptance criteria (checkboxes).
+   - Technical approach grounded in **real files/paths** and the chosen data source.
+   - Test plan mapped to the actual suites (`go test` · `vitest` · hermetic Playwright).
+   - Explicit out-of-scope.
+   - Keep the Definition of Done checklist verbatim.
+   - Stamp the footer: date (from the current-date context), Effort (S/M/L),
+     Priority (P0–P2).
+4. Write it into the issue body: save the filled template to a temp file under the
+   scratchpad and `set_issue_body <n> <file>`. The spec is the single source of truth —
+   only preserve prior body text that captures decisions the spec doesn't.
+5. Set fields: `set_effort <n> <S|M|L>` and `set_priority <n> <P0|P1|P2>`.
+6. Print the issue URL and a one-line summary of what was written.
+
+Do **not** change Stage — `/groom` owns state transitions.