voidmachine 0.0.0 → 4.0.0

package/core-assets/skills/void-observability/harness.yaml

@@ -0,0 +1,15 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: standard
+activation: always
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: pretooluse
+    codex: pretooluse
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-plan/.source

@@ -0,0 +1,15 @@
+Sources for `void-plan` skill (see `docs/plans/skill-audits/void-plan.md` for full audit):
+
+- superpowers/plan — primary source. Used to ship Phase A–C of this very harness.
+- superpowers/executing-plans — KEEP EXTERNAL. Plans transition to it. No improvement vector identified.
+- superpowers/subagent-driven-development — reference for parallelizable plans.
+- citypaul plan templates — sectioning style, numbered steps with verification gates.
+- plan-review — composed for high-risk plans (post-write review via CEO/Eng/Design/DevEx lenses; was gstack /autoplan, vendored in DEV-385).
+- gstack /spec — VENDORED (DEV-388, the planning half): the executability gate (an unfamiliar implementer/agent could execute with zero follow-up questions) + MVP-cut-first. The precision/grounding half went to brainstorm.
+
+Strategy: distill. Three deliberate changes from superpowers:
+1. TDD mode per step (declared inline)
+2. Resume point is first-class (every plan has one)
+3. Verification gates between steps map explicitly to hooks
+
+No companion hooks; the discipline is in the plan structure + downstream composition.

package/core-assets/skills/void-plan/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: void-plan
+description: Turn an approved spec into vertical slices with dependencies, TDD mode, verification gates, checkpoints, and a tracker handoff. Use after brainstorm approves a spec.
+---
+
+# plan — voidcorp craftsman edition
+
+The spec answers "what should we build." This skill answers "in what order, with what gates, and how later sessions recover the work." Plans live on disk. Every implementation step declares its TDD mode. Verification gates between steps prevent regressions.
+
+**Attribution**: see `.source`. Primary source: superpowers/plan, adapted for void-machine.
+
+---
+
+## When to invoke
+
+Invoke immediately after `void-brainstorm` approves a spec. The plan is the next deliverable before any code.
+
+**A `source: forge` spec is a ready spec.** When `docs/specs/YYYY-MM-DD-<slug>.md` carries `source: forge` in its frontmatter (the forge→harness artifact contract), consume it **directly** — it already holds the 18 recon variables, the winning design, and the critique verdict, so `void-brainstorm` need not have run. Plan from it as-is; if it is partial (missing critique, or a field absent in an older `forge_version`), plan around the holes and flag them as the first open decisions rather than re-deriving the whole thing.
+
+Do NOT invoke without an approved spec. If you find yourself wanting to plan without a spec, that means brainstorm was skipped — go back.
+
+---
+
+## Plan structure
+
+A plan is a markdown file at `docs/plans/YYYY-MM-DD-<topic>-plan.md`. Frontmatter:
+
+```yaml
+---
+title: <topic>
+date: YYYY-MM-DD
+status: in-progress  # in-progress → executing → done
+spec: docs/specs/YYYY-MM-DD-<topic>.md
+ticket: <tracker id, once `void-ticket` has created it; leave empty until then>
+author: <user> + Claude/Codex
+high_risk: false  # set true if the plan touches payment, auth, prod data migration, security-sensitive code → triggers plan-review recommendation
+---
+```
+
+Then sections:
+
+1. **Goal** — one paragraph from the spec
+2. **Steps** — numbered, each with the structure below
+3. **Review checkpoints** — explicit points where the user reviews work-to-date
+4. **Execution handoff** — dependency/order table for tracker-backed programs, or a resume point for a standalone sequential plan
+
+---
+
+## Step structure
+
+Each implementation step has this shape:
+
+```markdown
+### Step N — <imperative subject>
+
+- **Goal**: <one sentence>
+- **Depends on**: [step-3, step-5] (or "none")
+- **TDD mode**: strict | souple | exploratory
+- **Verification gate**: <what must pass before moving to step N+1>
+- **Expected commits**:
+  - `test: <reproducing or new behavior>`
+  - `feat: <implementation>` (or `fix:` / `refactor:` per `void-commit-discipline`)
+- **Notes**: <constraints, gotchas, hook implications>
+```
+
+### TDD mode declaration
+
+Every implementation step states its mode. Examples:
+
+- **strict** — new business behavior, hotfix on payment surface, refactor that changes payment behavior
+- **souple** — glue at integration boundary covered by higher-level test, framework wiring
+- **exploratory** — spike, POC, throwaway script
+
+The declared mode flows into `tdd-guard` enforcement at execution time. If mode is missing, the plan is incomplete.
+
+### Verification gate
+
+Each step's gate states which checks must pass before moving on. Examples:
+
+- `tsc --noEmit && vitest run --filter checkoutCart`
+- `pre-commit hooks dry-run on staged set` (composes with `tdd-guard`, `tigerstyle-check`, `no-any-grep`, etc.)
+- `mutation testing score ≥ 90%` (strict mode steps with critical surface)
+
+The gate is observable. The user sees the output before the next step begins.
+
+---
+
+## Vertical slices over horizontal phases
+
+Slice the plan into **vertical tranches** that cut through every layer (UI → domain → persistence) and deliver one end-to-end testable behavior. Do NOT phase horizontally — "first the whole schema, then the whole API, then the whole UI."
+
+Why vertical wins:
+
+- A vertical slice is verifiable and mergeable on its own: it produces working, demonstrable value at each step.
+- Horizontal phasing accumulates undeliverable work and hides integration errors until the final wiring step, exactly when they are most expensive to fix.
+- Each slice exercises the seams between layers early, so contract mismatches surface in step 1, not step 8.
+
+Prefer "checkout one item, end to end" then "checkout many items" over "all models, then all ports, then all UI." Each step in the plan should name the thin slice it ships.
+
+**MVP-cut first** (vendored from gstack `/spec`): the first slice is the smallest version that delivers real value — name it explicitly, and defer everything not required to prove that value. The plan grows from a shipping core, not toward one.
+
+---
+
+## Review checkpoints
+
+For non-trivial plans (≥ 5 steps), declare 1–2 explicit checkpoints where the user reviews work-to-date.
+
+```markdown
+### Checkpoint A — after Step 4
+
+User reviews the domain layer (Steps 1–4) before proceeding to the adapters layer.
+
+Stop here. Run `void-verify`. Wait for user signal to proceed.
+```
+
+Checkpoints prevent "I shipped 10 steps before you noticed step 3 was wrong."
+
+---
+
+## Resume point
+
+Use this only for a standalone sequential plan that is not decomposed into tracker tickets. The execution skill updates it as steps complete. Format:
+
+```markdown
+## Resume point
+
+**Next step**: Step 5 (Implement Stripe adapter)
+
+**Completed**:
+- ✅ Step 1: Domain models (commit `feat: domain Order + LineItem + Money`)
+- ✅ Step 2: OrdersPort interface (commit `feat: OrdersPort port interface`)
+- ✅ Step 3: In-memory adapter (commit `feat: in-memory OrdersAdapter for tests`)
+- ✅ Step 4: checkoutCart use-case (commits `test:` + `feat:`)
+
+**Pending**:
+- ⏳ Step 5: Stripe adapter
+- ⏳ Step 6: Server Action boundary
+- ⏳ Step 7: UI Server Component
+- ⏳ Step 8: E2E happy-path test
+```
+
+The next session reads the resume point and continues.
+
+For a provider-backed multi-unit programme, do not maintain a second mutable next-step pointer in
+the plan. Instead, add a final `Execution handoff` table that gives each plan unit a stable order
+key, title, dependency keys, estimate, and human-gate flag. After `void-ticket` creates the native
+units and dependency relations, it installs `.void/program.md`; the declared progress provider
+then owns current state and readiness.
+
+---
+
+## Plan self-review
+
+After writing the plan, scan for:
+
+1. **Placeholders** — any TBD / TODO / vague steps? Fix.
+2. **Missing verification gates** — every step has one? Fix.
+3. **Missing TDD mode** — every implementation step declares one? Fix.
+4. **Unrealistic dependencies** — does step N actually need step N-1, or could they parallelize?
+5. **Missing execution handoff** — a standalone plan has a correct resume point; a tracker-backed program has the complete stable order/dependency table?
+6. **Frontmatter `spec:`** — links back to the approved spec?
+7. **Executability gate** (vendored from gstack `/spec`) — could an *unfamiliar* implementer or agent execute this plan with **zero follow-up questions**? Walk one step as if you'd never seen the codebase: is every file named, every metric quantified, every acceptance criterion observable? Any "figure it out at implementation time" is an ambiguity to resolve now.
+
+Fix inline. Then user-review gate.
+
+---
+
+## User-review gate
+
+Ask the user to review the plan before execution begins:
+
+> "Plan written and committed to `docs/plans/<file>.md`. Please review and let me know if you want changes before we start executing."
+
+Wait for response. If changes requested, make them and re-run self-review.
+
+---
+
+## Transition to execution
+
+After plan approval, transition to:
+
+- **`void-ticket`** when the plan becomes multiple provider-native units. It writes native dependencies and the programme descriptor after the pool is approved.
+- **`void-implement`** for a named single ticket or standalone implementation unit.
+- **`void-autopilot`** only when the user requests its attended independent-ticket flow.
+
+For a provider-backed programme, later sessions recover work through `.void/program.md` and the
+declared progress adapter; they do not mutate the plan or checkpoint to repoint the next unit.
+
+---
+
+## High-risk plans — plan-review recommendation
+
+If `high_risk: true` in the frontmatter, recommend running `void-plan-review` (the `all` mode) after the plan is written but before execution begins.
+
+`void-plan-review` critiques the plan through CEO / Eng / Design / DevEx lenses, auto-decides the mechanical calls and surfaces the taste calls for the user. It catches issues brainstorm may have missed. It proposes findings; this skill's author folds them in.
+
+Set `high_risk: true` when the plan touches:
+
+- Payment / billing surface
+- Authentication / authorization changes
+- Production data migration (composes with `void-migrations`)
+- Security-sensitive code (secrets, auth tokens, PII)
+- LLM call sites with user-controlled input (composes with `void-security-guidance` LLM section)
+
+---
+
+## Composition with other skills
+
+- **Upstream — `void-brainstorm`**: the approved spec is the input.
+- **Downstream — `void-ticket`**: converts a multi-ticket plan into native tracker items and installs its active handoff.
+- **Downstream — `void-implement`**: executes one complete ticket and maintains its tracker lifecycle.
+- **With `void-autopilot`**: drains independent ready tickets only through its attended flow.
+- **With `void-tdd`**: per-step mode selection lives in the plan.
+- **With `void-code-review`**: review checkpoints declared in the plan are honored.
+- **With `void-verify`**: the plan's "Done" criteria feed the completion checklist.
+- **With `void-plan-review`**: optional multi-lens review for high-risk plans (downstream of this skill, upstream of implementation).
+- **With `void-commit-discipline`**: each step states the expected conventional-commit message.
+
+---
+
+## Anti-rules
+
+- MUST NOT plan without an approved spec.
+- MUST NOT skip TDD mode declaration per implementation step.
+- MUST NOT skip verification gates per step.
+- MUST NOT omit the applicable execution handoff: resume point for standalone work, tracker table for a multi-ticket program.
+- MUST NOT skip the spec link in frontmatter.
+- MUST NOT execute the plan (downstream skills do that).
+
+---
+
+## Final rule
+
+```
+Approved spec → plan written → self-review → user approves → ticket or implement.
+Otherwise → it is not voidcorp plan.
+```
+
+The plan is the contract between sessions and between agent and user. Make it explicit.

package/core-assets/skills/void-plan/harness.yaml

@@ -0,0 +1,14 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: action
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-plan-review/.source

@@ -0,0 +1,12 @@
+Sources for `void-plan-review` skill (see `docs/plans/skill-audits/void-plan-review.md` for full audit):
+
+- gstack /plan-ceo-review (1434 LOC + sections) — the CEO lens: premise/leverage/trajectory challenge, mandatory weighted alternatives, and the four scope modes (EXPANSION/SELECTIVE/HOLD/REDUCTION). The EXPANSION mode is the plan-level "10x" move.
+- gstack /plan-eng-review (990 LOC + sections) — the Eng lens: architecture soundness, four-data-path failure modes, the deep test-coverage trace + regression-iron-rule + coverage map, performance.
+- gstack /plan-design-review (1455 LOC + sections) — the Design lens: IA hierarchy, interaction-state coverage, journey/emotional arc, AI-slop classifier, responsive/a11y.
+- gstack /plan-devex-review (1418 LOC + sections) — the DevEx lens: developer journey, time-to-first-value (TTHW) vs competitors, error-message quality, docs, upgrade path.
+- gstack /autoplan (1810 LOC) — distilled into the `all` MODE (not a separate skill): fixed CEO→Design→Eng→DX order, the decision taxonomy (Mechanical auto / Taste + User-challenge escalate), the 6 decision principles, cross-lens theme synthesis, single final gate.
+- OpenAI "designing delightful frontends" + Steve Krug "Don't Make Me Think" — re-cited for the Design lens' slop bar and usability laws (paraphrased, not pasted).
+
+Strategy: distill (5 sources → 1 skill, 129 LOC). Chosen over 4-5 dedicated skills (anti-bloat: one subject = "critique a written plan"; mirrors code-review's one-skill-many-dimensions) and over extending plan (authoring != adversarial multi-persona critique; would overlap >30%). autoplan dissolves into a mode (YAGNI). See docs/DECISIONS.md (2026-07-10, DEV-385).
+
+Rejected (not vendored): all gstack runtime (preamble bash, gbrain, telemetry, plan-mode detection, AskUserQuestion D-numbering/completeness machinery, Codex-CLI invocation, voice/writing-style); the named-founder "Cognitive Patterns — How Great X Think" rosters (highest copy-risk, least load-bearing — the value is the checks, not the name-dropping); the dx-hall-of-fame.md exemplar corpus (calibration reference, not methodology). The shared substrate (scope gate, one-finding-one-question, registries, task list, verdict, second-opinion) was factored ONCE rather than duplicated per lens to stay under the 30% cross-lens overlap cap.

package/core-assets/skills/void-plan-review/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: void-plan-review
+description: "Critique a written plan (not a diff) via four lenses: CEO premise/ambition, Eng test-coverage, Design states/slop, DevEx time-to-first-value. Proposes findings; the author disposes."
+---
+
+# plan-review — voidcorp craftsman edition
+
+`void-brainstorm` pressure-tests the idea and `void-plan` authors the plan. This skill sits between the written plan and implementation: it **critiques an already-written plan** from up to four expert lenses, surfaces findings one decision at a time, and appends an Implementation Tasks list to the plan. It is read-mostly — it **proposes**; the plan's author (you, via `void-plan`) **disposes**. It never writes code and never restructures the plan itself.
+
+Invoke it on a plan in `docs/specs/` or `docs/plans/` before the plan becomes tickets. Pick one lens, several, or `all` (the orchestrated pass, below).
+
+**Attribution**: see `.source`. Distilled from gstack `/plan-ceo-review`, `/plan-eng-review`, `/plan-design-review`, `/plan-devex-review`, `/autoplan` (methodology only; the runtime and the named-founder rosters are rejected).
+
+---
+
+## The shared contract (every lens obeys this)
+
+- **Scope gate first.** Before reviewing, state what the plan touches and what is explicitly NOT in scope. A plan touching > 8 files or > 2 new services is a size smell — flag it before anything else.
+- **One finding = one decision.** Surface findings interactively, one at a time, each as a concrete decision with 2-3 options (always including "do nothing / defer") and a recommendation mapped to a stated preference. Never dump a wall of findings.
+- **Severity**: `P1` blocks ship · `P2` same-branch follow-up · `P3` later. Effort is dual-scaled (human hours vs AI-agent minutes — completeness is cheap when an agent implements).
+- **Findings become tasks, not edits.** The lens appends an Implementation Tasks list (P1/P2/P3) to the plan. It does not silently rewrite the plan; the author folds the fixes in. Registries the plan should already contain (Not-in-scope, What-already-exists, diagrams) are `void-plan`' job — the lens flags their absence, it does not own them.
+- **Verdict**: `CLEARED` (no P1 unresolved) or `NOT CLEARED` with the blocking findings named.
+- **Optional second opinion.** For a high-stakes plan, run one independent pass (a fresh subagent, or a second model) and surface only where it disagrees — cross-model tension is signal.
+
+---
+
+## Lens: CEO — is this the right thing, at the right ambition?
+
+The only lens that may challenge the **premise** and say "scrap it, do this instead." It accepts nothing as given.
+
+- **Premise & leverage**: right problem? a cheaper reframing? real outcome vs a proxy metric? cost of doing nothing? what existing code already solves each sub-problem?
+- **Trajectory**: current → delta → 12-month ideal. Reversibility 1-5 (one-way vs two-way door); path dependency; debt introduced; "obvious to a new engineer in 12 months?"
+- **Alternatives are mandatory**: 2-3 approaches, weighting *minimal-viable* and *ideal-architecture* equally, each with effort/risk/reuse; recommend one; do not proceed without approval. (Authoring the chosen approach is `void-plan`' job — the lens forces the comparison, not the write-up.)
+
+**Scope mode** (pick once, up front — this is the plan-level 10x move):
+- `EXPANSION` — cathedral: run the 10x check, sketch the Platonic-ideal version, name ≥ 5 delight opportunities. Default for greenfield.
+- `SELECTIVE` — hold rigor as the baseline, then offer neutral expansion candidates + platform potential to cherry-pick. Default for an enhancement.
+- `HOLD` — maximum rigor, no expansion; > 8 files / > 2 services is a smell. Default for a bugfix.
+- `REDUCTION` — ruthless minimum. Default for a > 15-file plan.
+
+**Verdict shape**: CRITICAL GAP / WARNING / OK per area, plus the unresolved decisions.
+
+---
+
+## Lens: Eng — is this buildable, testable, and will it not break?
+
+The gating lens. Owns the deep **test-coverage trace** no other lens does. Four sections, each answered even when "no issues":
+
+- **Architecture**: boundaries and dependency direction, coupling / SPOFs, scaling, security architecture, the distribution/build pipeline, and one realistic production-failure scenario per new codepath.
+- **Failure modes**: every codepath walked for four data paths — happy / nil / empty / upstream-error. A failure that is neither rescued nor tested is a CRITICAL GAP.
+- **Tests**: detect the framework; trace every branch, error, and null path; map interaction edge cases (double-submit, navigate-away, stale data, slow network, concurrency); decide unit vs E2E vs eval per behavior. **A regression fix ships with a test — non-negotiable.** Emit a coverage map of what is and isn't covered.
+- **Performance**: N+1, unbounded memory, missing caching on hot paths.
+
+**Output**: per-finding `[severity] (confidence N/10) file:line`, and quote the line that motivates each finding (no quote → it is unverified, drop the confidence). Verdict CLEARED / NOT CLEARED gates the plan.
+
+---
+
+## Lens: Design — what does the user perceive on screen?
+
+Scope-gated: no UI in the plan → skip. Judges what reaches the user's eyes.
+
+- **Information architecture**: explicit primary / secondary / tertiary emphasis per screen.
+- **Interaction-state coverage**: every state the user actually hits — loading, empty, error, success, partial — described as what the user *sees*. A missing state is a first-class plan gap, not a detail.
+- **Journey & emotional arc**: the 5-second / 5-minute / 5-year read of the feature.
+- **AI-slop risk**: classify the surface (marketing vs app-UI vs hybrid) and hold it to the matching bar; reject generic-AI-generated patterns. (Bar and blacklist re-derived from OpenAI's "designing delightful frontends" + Krug — cited in `.source`, composes with `void-frontend-design` / `void-ui-review`.)
+- **Responsive & a11y**: per-viewport intent, keyboard path, ARIA, 44px targets, 4.5:1 contrast — as plan requirements, not afterthoughts.
+
+**Output**: rate each dimension `N/10 → M/10` with the fix written into the plan; "design-complete" when every dimension ≥ 8.
+
+---
+
+## Lens: DevEx — is the developer-facing surface a good journey?
+
+Scope-gated: no API / CLI / SDK / library / docs surface → skip. Audits the developer journey from "never heard of it" → hello-world → upgrade. Signature metric: **time-to-first-value (TTHW)**, scored against real competitors (verify with a web search, do not invent numbers).
+
+- **Getting started**: one-command install, try-before-install, steps to a working example.
+- **Interface design**: guessable naming, sensible defaults, coverage vs dropping to raw HTTP, progressive disclosure.
+- **Error messages**: trace three real error paths — each names the problem, the cause, the fix, and links docs.
+- **Docs**: findable in 2 minutes, copy-paste works, version-matched.
+- **Upgrade path**: blast radius, deprecation warnings, codemods, semver honored.
+- **Dev environment**: LSP autocomplete, non-interactive CI, types, hot reload, cross-platform.
+
+**Output**: a DX scorecard (each dimension Score/Prior/Trend + TTHW tier + competitive rank); TTHW > 10 min is blocking; any dimension < 6 is critical DX debt. This lens judges the *plan's promises*; once the surface ships, `void-devex-audit` measures the reality against them.
+
+---
+
+## `all` — the orchestrated pass (replaces gstack autoplan)
+
+Runs the applicable lenses in the fixed order **CEO → Design → Eng → DX** (Design/DX skipped when their scope gate is empty). The order is load-bearing: each phase completes and writes its findings before the next. autoplan is a **mode here, not a separate skill** — once the lenses are one skill, an orchestrator that "runs the four" is a mode, not a new subject (YAGNI).
+
+Between phases, auto-decide only the safe class; escalate the rest:
+- **Decision taxonomy**: *Mechanical* (one correct answer) → auto-decide. *Taste* (defensible either way) and *User-challenge* (contradicts a stated goal) → surface to the human, never auto-decide.
+- **Decision principles** for the Mechanical class: choose completeness; fix the whole blast radius (auto-approve in-radius expansions under ~1 day / 5 files / no new infra); when two fixes are equivalent, take the cleaner one without agonizing; reject duplication, reuse; explicit-and-graspable beats clever; bias toward flagging over blocking.
+- **Cross-lens synthesis**: a concern raised by 2+ lenses is a high-confidence theme (the dedup that makes the multi-lens pass worth more than four solo runs).
+- **One final gate**: present the aggregated, deduped task list and the auto-decision audit trail; the human approves / overrides / challenges / revises-and-re-runs the affected lens. The pass drives to this gate; it never auto-applies plan edits beyond appending the task list.
+
+---
+
+## Composition & boundaries
+
+- **Downstream of `void-plan`** (which authors the plan) and **upstream of implementation** (`void-implement`). It reviews the artifact `void-plan` produced.
+- **Not `void-brainstorm`**: brainstorm pressure-tests the *idea* (is there demand?); plan-review critiques the *written plan* (is it the right shape, buildable, complete?). Different artifact, different question.
+- **Not `void-code-review`**: that reviews a *diff*; this reviews a *plan* before any code exists.
+- **Not `doctrine-critic`**: that judges a diff against VoidCorp doctrine; this critiques a plan across product/eng/design/DX lenses.
+- **Composes with `void-frontend-design` / `void-ui-review`** (the Design lens defers UI build-craft and audit to them), `void-devex-audit` (the DevEx lens's shipped-surface counterpart — this judges the plan, that measures the deployed reality), and `void-security-guidance` / `void-security-audit` (the Eng lens routes a deep security concern there).
+
+---
+
+## Anti-rules
+
+- MUST NOT rewrite the plan — it appends a findings/task list; the author folds fixes in.
+- MUST NOT own plan structure or registries (Not-in-scope, diagrams) — that is `void-plan`.
+- MUST NOT re-litigate the idea's demand — that is `void-brainstorm`.
+- MUST NOT review code or a diff — that is `void-code-review`.
+- MUST NOT auto-decide a Taste or User-challenge call — those go to the human.
+- MUST NOT dump findings in bulk — one finding, one decision.
+- MUST NOT vendor the gstack runtime or the named-founder "how great X think" rosters.
+
+---
+
+## Final rule
+
+```
+Written plan → pick lens(es) → one finding at a time → Implementation Tasks appended → CLEARED verdict.
+The lens proposes; the author disposes. Otherwise → it is not voidcorp plan-review.
+```
+
+A plan reviewed by the right lens before it becomes tickets is cheaper by an order of magnitude than the same gap found in code review.

package/core-assets/skills/void-plan-review/harness.yaml

@@ -0,0 +1,15 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: action
+activation: on-demand
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-qa/.source

@@ -0,0 +1,15 @@
+Sources for `void-qa` skill (see `docs/plans/skill-audits/void-qa.md` for the full distribution matrix):
+
+- gstack /qa (1642 LOC, "Test → Fix → Verify") — VENDORED (DEV-390): the QA methodology. Kept + distilled: the QA-engineer-AND-bug-fixer role, test-as-a-user (never read source to test), the modes (diff-aware default / full / quick / regression), the clean-working-tree precondition for atomic fix commits, the Orient → Explore → Document → Score → Triage → Fix-loop → Self-regulate → Report workflow, the per-page checklist (interactive / forms / navigation / empty-loading-error-overflow states / console-after-every-interaction / responsive), the two evidence tiers (interactive before/after vs static single shot), the health-score rubric (per-category deductions + weights), the atomic `fix(qa):` commit-per-fix + re-verify + regression-test + verified/best-effort/reverted classification, and the WTF self-regulation stop-and-ask heuristic.
+- gstack /qa-only (1214 LOC) — VENDORED as the `--report-only` mode (phases through Report, no fix loop). No second skill: report-only is a mode, not a subject.
+- gstack /design-review (1952 LOC), live half — the live-screenshot visual QA is re-homed here as the "visual pass" that COMPOSES `void-ui-review` (which already owns the visual-craft methodology: register split, squint test, interaction-state coverage, technical audit). This skill drives the browser; void-ui-review supplies the bar. No duplication.
+- REPOINTED, not ported: every gstack `$B <cmd>` browse-daemon call (goto/snapshot/click/fill/console/viewport/screenshot) maps onto the `mcp__claude-in-chrome__*` MCP tools (navigate/computer/read_page/form_input/read_console_messages/resize_window/gif_creator/read_network_requests), with `tabs_context_mcp` called first. Full daemon port was ~190 CDP/Chromium files and weeks of work; the re-point is the same prose on a browser layer Claude Code already ships. This IS the epic's "Vague 4" claude-in-chrome re-point.
+- REJECTED (gstack runtime, not doctrine): the browse binary + `./setup` + bun bootstrap, CDP-mode detection, gbrain/learnings search + log, telemetry/review-log, the `~/.gstack/projects` + chromium-profile cookie import (claude-in-chrome uses the user's real logged-in Chrome, so cookie import is moot — documented as a rejection per the ticket), TESTING.md / CLAUDE.md auto-edit.
+- REJECTED (scope creep, routed elsewhere): the entire Test-Framework-Bootstrap block (detect runtime → research → install → write TESTING.md). Standing up a test framework is `void-tdd`/`void-testing`, not QA. A QA skill that also bootstraps a framework is two subjects; the ticket's "un sujet, un skill" forbids it.
+
+Strategy: distill + repoint. One skill, one subject ("live browser QA of a running web app"). qa-only folds in as a mode; the visual pass composes ui-review; the regression test composes tdd/testing. < 30% overlap is structural: this drives the browser + functional/fix loop; ui-review judges visuals; devex-audit audits dev surfaces; tdd/testing author suites.
+
+Companion change (same ticket, gated by Folpe): the "Never use mcp__claude-in-chrome__*" rule in ~/.claude/CLAUDE.md predates the claude-in-chrome adoption and makes this skill unusable; it is lifted in the same move.
+
+DEV-444 adaptation: UI evidence now covers mobile and desktop applicable states, carries the current
+diff identity, and is handed to a fresh Visual Craft Director; unavailable browser proof blocks.

package/core-assets/skills/void-qa/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: void-qa
+description: "Live browser QA of a running web app via the claude-in-chrome MCP: systematic exploration, edge/error/empty states, atomic fix loop, evidence-backed report. Report-only mode available."
+---
+
+# qa — voidcorp craftsman edition
+
+You are a QA engineer AND a bug-fix engineer. Test a running web app like a real user — click everything, fill every form, check every state — using the **claude-in-chrome MCP** to drive the browser. When you find a bug, fix it in source with an atomic commit, then re-verify. Produce a structured report with before/after evidence.
+
+This tests the *shipped, running app* through a real browser. It is not unit/E2E authoring (`void-tdd` + `void-testing` own that), and it does not judge visual craft from code (`void-ui-review` owns that — this skill composes it for the live visual pass).
+
+**Attribution**: see `.source`. Vendored from gstack `/void-qa` + `/qa-only` + the live half of `/design-review`, repointed off the gstack browse daemon onto the claude-in-chrome MCP already present in Claude Code. The gstack runtime (browse binary, gbrain/learnings, telemetry, `~/.gstack` artifacts, test-framework bootstrap) is rejected.
+
+---
+
+## When to invoke
+
+- Verifying a running app after a change (the default: a feature branch, "does it actually work?").
+- Auditing a deployed site for bugs and broken flows.
+- A report-only pass (no fixes) before a review or handoff.
+
+Do NOT use this to author a unit/E2E suite (`void-tdd`/`void-testing`), to audit UI craft from code (`void-ui-review`), or to audit a dev-facing API/CLI/SDK surface (`void-devex-audit`).
+
+## Browser tooling: claude-in-chrome (load first)
+
+The execution primitives are the `mcp__claude-in-chrome__*` tools. If they are deferred, load the core set in **one** ToolSearch call before anything else:
+
+`select:mcp__claude-in-chrome__tabs_context_mcp,mcp__claude-in-chrome__navigate,mcp__claude-in-chrome__computer,mcp__claude-in-chrome__read_page,mcp__claude-in-chrome__tabs_create_mcp,mcp__claude-in-chrome__read_console_messages,mcp__claude-in-chrome__form_input,mcp__claude-in-chrome__gif_creator,mcp__claude-in-chrome__resize_window,mcp__claude-in-chrome__read_network_requests`
+
+Command mapping from the old gstack browse (`$B`) to the MCP:
+
+| Need | claude-in-chrome tool |
+|------|-----------------------|
+| Session tab context (**call first**) | `tabs_context_mcp` |
+| Open the target in a **new** tab | `tabs_create_mcp` |
+| Navigate | `navigate` |
+| Click / type / screenshot | `computer` |
+| Fill a form field | `form_input` |
+| Read DOM / accessibility tree | `read_page` |
+| Console errors after an action | `read_console_messages` (filter with `pattern`) |
+| Network (data-fetch 404s) | `read_network_requests` |
+| Responsive viewport | `resize_window` |
+| Record a repro | `gif_creator` |
+
+## Hard constraints (claude-in-chrome reality)
+
+- **`tabs_context_mcp` first**, every session. Never reuse a tab id from another session; open a fresh tab with `tabs_create_mcp` unless the user names a tab.
+- **Permissions are per-site.** If a site is not authorized and permission is refused, STOP and tell the user which site to allow — never loop retrying the same denied call.
+- **Never trigger a JS dialog** (`alert`/`confirm`/`prompt`) or a browser modal — they block the extension and kill the session. For repro debugging use `console.log` + `read_console_messages`, not `alert`. Warn the user before touching any element that may open one.
+- **Not headless.** claude-in-chrome drives the user's real, interactive Chrome (already logged in — no cookie import, no `~/.gstack/chromium-profile`). QA in a cloud/cron session with no interactive Chrome is **out of scope** — an assumed limitation the browse daemon did not have; say so rather than faking it.
+- After 2-3 failed tool calls, a page that will not load, or unexpected tangents: stop and ask the user, do not keep retrying.
+
+## Modes
+
+- **Diff-aware** (default on a feature branch with no URL) — read the branch diff, map changed files to affected pages/routes, detect the local dev server, test only those pages plus a homepage smoke. The common case.
+- **Full** (a URL is given) — systematic exploration of every reachable page; 5-10 well-evidenced issues; health score.
+- **Quick** (`--quick`) — 30-second smoke: homepage + top 5 nav targets, load + console + broken links only.
+- **Regression** (`--regression <baseline.json>`) — run full, then diff against a prior baseline: fixed vs new vs score delta.
+- **Report-only** (`--report-only`, the old `/qa-only`) — phases through Report, then STOP. No fix loop, no commits.
+
+## Precondition: clean working tree
+
+Each fix must be its own atomic commit, so before fixing, `git status --porcelain` must be empty. If dirty, ask the user to commit / stash / abort first (recommend commit — preserve their work before QA adds fix commits). Report-only mode may run on a dirty tree.
+
+## Workflow
+
+1. **Orient** — `tabs_context_mcp`, open the target in a new tab, screenshot, read the page, check console. Detect the framework (Next.js `__next` / `_next/data`; Rails `csrf-token`; SPA = client routing) and note it. For an SPA, map nav from `read_page` (client routes, not raw links).
+2. **Explore** — visit pages systematically. Per page: visual scan of the screenshot; click interactive elements; fill + submit forms (empty, invalid, edge, overflow); walk navigation in and out; exercise **the states a user actually hits — empty, loading, error, overflow**; check console after every interaction; for responsive, `resize_window` then **verify the screenshot dimensions actually changed** — on some setups it resizes the window without re-rendering to a true mobile viewport, so confirm before trusting a "mobile" shot (else note responsive as unverified). Depth over breadth: more time on core flows (auth, checkout, search), less on static pages.
+3. **Document** — write each issue the moment you find it, never batch. Two evidence tiers: an **interactive** bug gets a before-screenshot, the action, an after-screenshot (a `gif_creator` repro for a flow); a **static** bug gets one annotated screenshot. Verify a bug reproduces once before writing it. For a UI quality pass, capture mobile and desktop for every applicable state and bind each capture to the current diff hash; a later CSS/UI diff makes it stale. Redact credentials (`[REDACTED]`). Surface every screenshot to the user (Read the file) — otherwise it is invisible.
+4. **Health score** — per-category 0-100 (Console, Links, Visual, Functional, UX, Performance, Content, Accessibility) minus severity deductions (critical -25 / high -15 / medium -8 / low -3), weighted average. Record it as the baseline.
+5. **Visual pass** — for visual/interaction judgment on the live screenshots, compose `void-ui-review`, then hand the current-diff evidence to `core:visual-craft-director` in fresh context. This skill drives the browser; `void-ui-review` supplies the craft bar; the specialist owns the independent verdict. If the browser or required captures are unavailable, report the UI pass blocked rather than certifying from prose.
+6. **Triage** — sort by severity; fix per tier: `--quick` critical+high · standard (default) +medium · `--exhaustive` +low. Mark unfixable-from-source (third-party, infra) as deferred.
+7. **Fix loop** (skipped in report-only) — per issue in severity order: locate source (grep/glob — only now do you read code); make the **minimal** fix (no refactor, no scope creep); commit one fix `fix(qa): <issue> — <desc>`; re-test the page with a before/after pair + console + a regression test that reproduces the bug (compose `void-tdd`/`void-testing` — assert behavior, not "it renders"); classify **verified / best-effort / reverted** (`git revert` on a regression → defer).
+8. **Self-regulation** — every 5 fixes or after any revert, stop and evaluate: reverts, fixes touching many files, all-low-severity remaining, and unrelated-file edits all raise the "this is going wrong" signal. Above the threshold, or past a hard cap of ~50 fixes, STOP and show the user before continuing.
+9. **Report** — issues with severity + evidence + fix status (verified/best-effort/reverted/deferred) + commit SHA; health-score delta baseline → final; a one-line PR summary ("QA found N, fixed M, health X → Y"). If the final score is worse than baseline, warn prominently. Write it under the project's report location, not `~/.gstack`.
+
+## Composition & boundaries
+
+- **With `void-ui-review`** — this skill owns driving the browser and the functional/fix loop; `void-ui-review` owns the visual-craft judgment applied to the live screenshots (step 5). No restated design rules here.
+- **With `void-tdd` / `void-testing`** — the regression test in the fix loop is authored per their discipline. This skill finds bugs in a running app; they own how the test that locks the fix is written.
+- **Not `void-devex-audit`** — that audits a developer-facing surface (API/CLI/SDK/docs journey, TTHW); this QAs an end-user web app in a browser. Different surface.
+- **Not E2E authoring** — Playwright suites are `void-testing`'s output; this is exploratory human-style QA of the deployed thing.
+- **Supersedes** gstack `/void-qa`, `/qa-only`, and the live-screenshot half of `/design-review`.
+
+## Anti-rules
+
+- MUST NOT test by reading source — test as a user; read code only in the fix loop, to locate the bug.
+- MUST NOT trigger a blocking JS dialog / modal — it kills the claude-in-chrome session.
+- MUST NOT reuse a cross-session tab id, or assume a headless/CI browser — mark non-interactive sessions out of scope.
+- MUST NOT bundle fixes — one atomic `fix(qa):` commit each; revert on regression.
+- MUST NOT include credentials in the report — `[REDACTED]`.
+- MUST NOT bootstrap a test framework or edit CI/CLAUDE.md — that is `void-tdd`/`void-testing`, not QA.
+- MUST NOT vendor the gstack runtime (browse binary, gbrain/learnings, telemetry, `~/.gstack` artifacts, cookie-profile import).
+
+## Final rule
+
+```
+Running app → load claude-in-chrome (tabs_context first) → orient → explore every state → document with
+evidence → score → triage → atomic fix + regression test + re-verify → self-regulate → report.
+Report-only stops before the fix loop. Otherwise → it is not voidcorp qa.
+```
+
+QA is the discipline of hitting the app the way a user will, before the user does — and, when it breaks, fixing it under the same evidence bar that found it.

package/core-assets/skills/void-qa/harness.yaml

@@ -0,0 +1,15 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: action
+activation: on-demand
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-refactor/.source

@@ -0,0 +1,9 @@
+Sources for `void-refactor` skill (see `docs/plans/skill-audits/void-refactor.md` for full audit):
+
+- Kent Beck "Tidy First?" 2023 — https://www.oreilly.com/library/view/tidy-first/9781098151232/ — separate Tidyings from Behavior Changes, Two-Hat principle
+- Martin Fowler "Refactoring" 2nd ed. 2018 — https://martinfowler.com/books/refactor.html — catalog of named refactors + smells catalog
+- Michael Feathers "Working Effectively with Legacy Code" 2004 — Sprout Method, Wrap Method for legacy/untested code
+- citypaul/.dotfiles refactor notes — Tidy-First commit cadence
+- Joshua Kerievsky "Refactoring to Patterns" — referenced, used sparingly (not daily practice)
+
+Strategy: distill. Author for void-machine with two modes mirroring tdd. Reject monolithic-rewrite framing. Companion hooks: tidying-commit-prefix, refactor-named-grep. Allowed Fowler names in ../../hooks/fowler-refactors.txt.