voidmachine 0.0.0 → 5.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-orchestrate/.source

@@ -0,0 +1,16 @@
+Distilled from official contracts, checked against installed versions on 2026-10-08:
+- Herdr 0.9.0 automation: https://raw.githubusercontent.com/herdrdev/herdr/v0.9.0/docs/next/website/src/content/docs/agent-automation.mdx
+- Herdr 0.9.0 restoration: https://raw.githubusercontent.com/herdrdev/herdr/v0.9.0/docs/next/website/src/content/docs/session-state.mdx
+- Herdr metadata implementation: https://github.com/herdrdev/herdr/blob/v0.9.0/src/metadata_tokens.rs
+- Herdr resume_argv version boundary: https://github.com/herdrdev/herdr/blob/v0.9.2/CHANGELOG.md
+- Native runtime CLI help (Codex and Claude) and mission-engine review-receipt/specialist-lifecycle contracts in this repository.
+Adaptations/rejections: docs/plans/skill-audits/void-orchestrate.md.
+
+Adaptive delegation, researched 2026-10-13 (distilled, no upstream code copied):
+- OpenAI native subagents: https://learn.chatgpt.com/docs/agent-configuration/subagents
+- Anthropic research teams: https://www.anthropic.com/engineering/multi-agent-research-system
+- OpenClaw context and collection: https://docs.openclaw.ai/tools/subagents/tool-reference
+- OpenClaw lifecycle: https://docs.openclaw.ai/tools/subagents/slash-command
+- OpenClaw responsibilities: https://docs.openclaw.ai/concepts/parallel-specialist-lanes
+- Hermes delegation: https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation
+- Hermes task selection: https://hermes-agent.nousresearch.com/docs/guides/delegation-patterns

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

@@ -0,0 +1,311 @@
+---
+name: void-orchestrate
+description: Delegate independent research and substantial implementation through native agents; choose context, isolation and bounded concurrency, collect results and preserve review evidence. Use the supported session host.
+---
+
+# Orchestrate
+
+The user-facing coordinator keeps intent, decisions and synthesis. This skill owns
+adaptive delegation, transport and continuity; `void-implement` owns delivery quality
+and `void-autopilot` its loop. Neither a pane nor a report grants merge permission.
+
+## Choose work and capabilities
+
+Read project instructions, the approved task and Git state; preserve other writers'
+changes. Before dispatch, inspect the actual native agent tools and their supported
+context, permissions, completion and resume capabilities. Use the best supported
+capabilities for the task in the current session; an installed executable or an
+environment hint alone does not validate a host, identity or permission.
+
+Herdr is optional for consumers, not discretionary inside a validated Herdr session.
+When fresh discovery validates the coordinator in Herdr, use its adapter below for
+durable terminal workers and mission visibility. Short agents remain native; never
+duplicate an agent to give it a pane. Outside Herdr, use the current supported host
+(such as tmux) when its required capabilities and ownership can be verified. This
+policy adds no tmux transport and never relaunches through the legacy kernel.
+Without supported presentation, retain native delegation and report the limitation;
+do not claim durability from a pane or unsupported API. Failed or ambiguous host
+discovery blocks the affected host action: diagnose it, never silently switch hosts
+or act on an unrelated project. Native work independent of that action may continue.
+
+- Work directly for a tiny targeted change, a single tool call, mechanical processing,
+  or tightly coupled work where delegation adds no useful separation.
+- Delegate bounded independent research and exploration during brainstorm and plan.
+  Keep the user conversation, evaluation of sources and decisions in the coordinator.
+- Delegate substantial implementation to one writer when supported. A writer
+  already assigned the unit executes it; never delegate the same complete workflow
+  recursively. Retain that writer for corrections. Before parallel feature slices,
+  define disjoint ownership, dependencies and acceptance of the integrated result.
+- No native agent capability: execute sequentially and state the limitation. A
+  mandatory independent review or required isolation remains a blocker; do not
+  replace it with self-review or silently weaken its requirement.
+
+## Brief and bound the delegation
+
+Use a fresh context by default. Choose a supported fork only when the task needs
+conversation history. Give objective, relevant context/source revision, owned paths,
+permissions, acceptance, result format and bounds. Tell writers they are not alone
+and must preserve others' changes. Ask researchers for conclusions, source references,
+uncertainty and remaining questions, not all intermediate logs. Ordinary research
+uses this lightweight brief: do not invent specialist events or review receipts.
+Formal specialist envelopes and evidence follow the independent contract below.
+
+Count writer, research and review children together against observed available runtime slots
+and the coordinator's bounded dispatch; queue work when full. Preserve tighter caller
+limits, including Autopilot's ticket cap and the central schema's four-worker limit.
+This is no machine-wide quota. Do not create recursive child coordinators or redispatch
+the same complete workflow. Required formal specialists remain dispatched by their
+designated owner within the shared available capacity. Do not duplicate a child's work
+in the coordinator. Run independent work concurrently only when it helps the critical
+path; use ordinary tools for mechanical operations. Respect permissions throughout.
+
+Read-only research needs no new worktree. Reviews use an immutable exact subject.
+Concurrent authors need isolated assigned worktrees and disjoint ownership; if
+isolation fails, serialize rather than share concurrent writes. Required isolation
+that cannot be met stays blocked. A sole writer may reuse its assigned checkout;
+Autopilot retains its per-ticket worktree requirement. Follow the universal durable
+worktree invariant and existing shared Git restrictions, irrespective of display.
+
+## Collect and resume honestly
+
+Prefer native completion events; otherwise wait in bounded slices. A wait timeout
+is not failure. Reconcile an uncertain launch or side effect before retrying. Use
+partial results when useful, distinguish failure from missing output, and verify
+acceptance before claiming success. Reuse the same session for corrections; confirm
+that a new instruction was consumed or reflected in the result before calling it applied.
+
+Distinguish saved work, live session, retained result and delivered result. A finished
+turn or report alone proves no accepted outcome or crash recovery. Use the selected
+runtime's actual persistence/recovery path; expose a lost session or unknown effects.
+Never invent a durable inbox. Preserve formal receipts separately from working notes.
+
+## Short native specialists
+
+Pass the returned specialist envelope unchanged: runtime, agentName, missionId,
+contextPack and, when present, reviewSubject and reviewScope. Invoke the runtime's
+native fresh-context primitive; native Agent calls are not intercepted. Keep the
+real opaque context ID exactly as returned, including slash-prefixed names; it is
+data, never a filesystem path. Record actual starts/completions with
+`mission specialist-event`; never invent IDs or convert a failed call into a review.
+Before another invocation, reconcile any existing invocation for the same envelope.
+Preserve the complete result; incomplete results go back to the same agent.
+With `panel.provider: orchestrator`, only ORCH launches and collects this panel.
+Missing required native capability is reported with cause and next action.
+
+## Herdr adapter: recovery
+
+The following Herdr sections apply when the session-host policy selects this adapter.
+Native delegation without it does not require these central files or pane discovery.
+
+Read project instructions, the approved task and the current Git status. Preserve
+other writers' changes. Resolve the canonical Git common directory, SHA-256 its
+absolute real path as UTF-8, and inspect
+`~/.local/state/orchestra/<project>/<mission>/`. Never use an inherited workspace
+variable or a stale pane ID as authority. Read mission.md, the applicable
+workers/<label>/brief.md and report.md. Re-read `herdr pane list` before every
+identity decision. Match **label + worktree**, using the canonical worktree path.
+Refuse multiple matches, incomplete discovery, symlinks, traversal and invalid data.
+After reattachment/restart, ORCH atomically updates pane_id and coordinator.workspace
+from that validated fresh inventory. Hooks and workers never write these hints.
+A missing unrelated historical worktree does not invalidate a current identity.
+
+The coordinator is the existing ORCH session, never a second agent opened for display.
+Resolve its own label + worktree before selecting its workspace. Keep each writer
+in its assigned worktree. Do not affect any other project, workspace or pane.
+An uncertain launch or prompt acknowledgement requires reconciliation of that same
+worker before retrying. A timeout proves neither launch failure nor prompt loss.
+
+## Herdr adapter: explicit coordinator context
+
+If unique discovery refuses multiple compatible missions, ORCH reads the target
+mission and reports, then atomically replaces its local, unversioned
+`<canonical worktree>/.void/machine/orchestra-selection.json`. Schema 1 is strict
+JSON, at most 4096 UTF-8 bytes: `{ "schema": 1, "project": "<project-sha256>",
+"mission": "<existing-id>", "coordinator": { "label": "ORCH", "worktree":
+"/absolute/canonical/worktree" } }`. ORCH alone writes it; hooks never repair it.
+No unknown or duplicate keys, YAML, traversal, symlinks or partial writes.
+
+This selects context only, never execution state or permissions. Full bounded
+central discovery still runs; malformed unrelated missions or limits refuse.
+A stale/invalid binding never falls back. Verify selected coordinator label and
+canonical worktree against the current worktree and a fresh `herdr pane list`;
+missing or duplicate live matches refuse. Never prefer timestamps, running status
+or pane tokens to decide intent. Without a binding, preserve unique discovery.
+Clear/compact/resume re-read selection and central state without launching workers.
+Separate worker worktrees retain their own mission, attempt and report discovery.
+A selected terminal mission retains the guarded cleanup below: never clear tokens
+belonging to another mission. No binding belongs in the programme descriptor.
+
+## Herdr adapter: central files and ownership
+
+Use schema: 1 YAML frontmatter, strict string keys and one document, followed by
+Markdown. Reject duplicate keys, tags, anchors, aliases and unknown fields. Bound
+mission/report to 64 KiB, brief to 256 KiB, discovery to 64 entries and 1 MiB of
+mission bytes; exceeding a bound is incomplete, never a unique match.
+See the shipped technical contract `docs/ORCHESTRA.md` in the harness source for
+schemas; the operational fields are listed here so an installed skill is sufficient.
+
+- mission.md: schema, mission, project, status, updated_at (UTC ISO), repository
+  (canonical Git common path), coordinator {label, worktree, workspace?}, workers.
+- Worker entries: label, agent (codex or claude), worktree, branch, ticket, status,
+  attempt; optional pane_id and session are hints only. At most four workers.
+- Coordinator status and worker status: planned, running, blocked, done, failed.
+- report.md: schema, mission, attempt, worker, branch, status (running, blocked,
+  done, failed), commits (full SHAs), tests (passed, failed, not_run), updated_at.
+  Body: actual commands/results, proof locations, risks, questions and remaining work.
+- brief.md: absolute paths, exact base, footprint, acceptance criteria, ownership,
+  permissions, forbidden effects and current attempt. No secrets. Explicitly warn
+  that other writers exist and their changes must be preserved.
+
+ORCH alone writes mission and briefs; each worker alone writes its report. Use an
+atomic replacement: write an exclusive temporary sibling, then rename. Hooks never
+write these files. A new work turn gets a new attempt; resume keeps its attempt.
+A valid report for the current mission/attempt overrides workers[].status at every
+event. An absent report falls back to the manifest. Malformed, foreign, partial or
+unrecognized stale reports refuse usage; never turn a parse failure into absence.
+The files carry coordination state, not independent review proof.
+
+## Herdr adapter: copyable starting files
+
+Replace the example project hash with SHA-256 of the canonical common Git path.
+Replace every path, branch, ticket and timestamp from actual observations. These
+three files are authored by their owner, never by the hook.
+
+mission.md:
+
+```yaml
+---
+schema: 1
+mission: dev-42
+project: "<project-sha256>"
+status: planned
+updated_at: "2026-10-08T10:00:00.000Z"
+repository: /absolute/repository/.git
+coordinator:
+  label: ORCH
+  worktree: /absolute/repository
+  workspace: wA
+workers:
+  - label: WORK-1
+    agent: codex
+    worktree: /absolute/worktrees/dev-42
+    branch: work/dev-42
+    ticket: DEV-42
+    status: planned
+    attempt: implementation-1
+---
+# Mission
+Scope, acceptance criteria, canonical mission journal and proof locations.
+```
+
+workers/WORK-1/brief.md:
+
+```yaml
+---
+schema: 1
+mission: dev-42
+attempt: implementation-1
+worker: WORK-1
+---
+# Work
+Worktree: /absolute/worktrees/dev-42. Branch: work/dev-42.
+Base: <verified full commit SHA>. Ticket: DEV-42.
+Footprint: <exact owned files/directories>; preserve every other writer's edits.
+Acceptance: <complete observable criteria and verification commands>.
+Limits: <role permissions, forbidden effects, human gates>.
+Report: /absolute/mission/workers/WORK-1/report.md, owned only by this worker.
+Resume: <actual runtime session and the recipe from the table below>.
+```
+
+workers/WORK-1/report.md:
+
+```yaml
+---
+schema: 1
+mission: dev-42
+attempt: implementation-1
+worker: WORK-1
+branch: work/dev-42
+status: running
+commits: []
+tests: not_run
+updated_at: "2026-10-08T10:00:00.000Z"
+---
+# Checkpoint
+Completed: <actual changes>. Verification: <commands, results and proof paths>.
+Remaining: <work and exact next action>. Risks/questions: <observed limitations>.
+```
+
+## Herdr adapter: durable workers
+
+Read installed `herdr --help`, `herdr agent --help` and the live schema before
+issuing commands. Use structured argv, exact acknowledged identities and bounded
+waits/output. The launch recipes for the selected worktree are:
+
+| Kind | Launch argv | Resume argv | Short contexts | ctx capability |
+| --- | --- | --- | --- | --- |
+| codex | `--no-daemon --add-dir <absolute-mission>` | `resume <actual-session> --no-daemon --add-dir <absolute-mission>` | Native fresh context | Unmeasurable without a supported usage source |
+| claude | `--add-dir <absolute-mission>` | `--resume <actual-session> --add-dir <absolute-mission>` | Native Agent, no interception | Fresh transcript usage plus required context.windowTokens |
+
+Use the selected kind's executable and preserve these options on every launch/resume:
+
+```sh
+herdr agent start <unique-mission-worker-name> --kind <kind> --pane <resolved-pane> -- <argv-from-table>
+```
+
+The arguments after `--` belong to the selected runtime. The name is unique within
+the mission; it is not an invented native session ID. Resolve the pane first and
+keep the session ID actually returned by the runtime.
+
+Apply the role's existing permission/read-only policy; `--add-dir` only grants the
+specified directory, never disables a sandbox or an approval. Unsupported kind or
+option: diagnose and stop that launch. Do not update or restart Herdr to make it fit.
+Register planned worker before creating its owned surface. Keep the returned pane
+ID as a hint, launch once, submit the brief once, then reconcile by label + worktree.
+Use `herdr agent wait` in bounded slices and read the report after every turn.
+Idle/done is a turn ending, never proof the task passed. Request a missing report
+from the same session. Follow up in that session; never create a duplicate worker.
+After /clear read the same mission; after a killed process resume its actual session
+in the same worktree. Missing session: retain the mission and expose the loss.
+
+`resume_argv` is absent from Herdr 0.9.0 and 0.9.1, present from 0.9.2. Publish it
+only after the installed schema proves support. Otherwise retain the complete resume
+recipe in the brief. Never claim restart restoration was tested without doing it.
+
+## Herdr adapter: projection and closure
+
+The hook publishes source void-machine on SessionStart startup/resume/clear/compact
+and Stop after re-reading central state and fresh Herdr identities. Pane tokens:
+mission, worker, ticket, wstatus; coordinator-only workspace: mission, wstatus, workers.
+These are file status, never agent state. ctx requires the selected kind's measured capability from the table; unavailable measurement stays unavailable. Clear
+removes ctx before fresh measurement. State TTL is 86400000 ms, ctx TTL 7200000 ms.
+Sequences are exact nanosecond decimal BigInts captured before discovery. Old or
+equal seq is ignored by Herdr. Tokens are global keys, not source namespaces: another
+source may overwrite them; null clears globally. Never reconfigure cockpit to win.
+
+Terminal mission cleanup explicitly clears keys on all still-resolved owned panes,
+only where the currently projected mission still matches. Only the resolved
+coordinator clears workspace keys, again after verifying the displayed mission.
+A late closure of A must not clear B. A worker SessionEnd never cleans the workspace.
+When no mission is active, recover the verified displayed terminal mission; do not
+choose arbitrary history. Discovery/transport errors never trigger a purge.
+After collection and acceptance ORCH may close its owned surfaces; retain worktrees,
+branches and evidence according to their own lifecycle. Do not close the coordinator.
+
+## Independent review
+
+Commit the candidate before the independent pass. Keep a fresh read-only reviewer,
+different from the writer, on the exact reviewedCommit, baseCommit and
+acceptanceCriteriaHash. Preserve its actual canonical request/start/completion and
+receipt (native-context or supported review-artifact provenance). Artifact provenance
+stays within the existing project boundary and must match its digest and invocation.
+A central report marked done is never a review receipt. Preserve limitations honestly.
+
+For autopilot, `autopilot review --ticket <id> --pr <n> --head <sha> --round <1|2>
+--mission <canonical-id>` checks the target ticket against the existing bounded ticket reader (filename identity
+and frozen content hash), then prepares the exact review subject/worktree and, when
+pending, returns awaiting-native-review. ORCH performs the native invocation and
+records its real receipts, then repeats the same command to collect. Do not start a
+new mission to repair a pending attempt. Budgets, protected paths, HEAD drift checks,
+local verdict admission and merge holds remain enforced. In-flight legacy runs are
+collected through their existing transport and journals; never duplicate them.

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

@@ -0,0 +1,10 @@
+kind: action
+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,246 @@
+---
+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.
+
+---
+
+## Delegated investigation
+
+Invoke `void-orchestrate` for independent dependency, codebase or verification
+investigations that inform the plan. The coordinator integrates the results into
+one dependency graph and retains scope, sequencing and approval decisions; agents
+do not independently approve plans or start implementation.
+
+## 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.