Activate the prompt-forge skill and run its AUTHOR workflow for:

$ARGUMENTS

Produce the .prompt.md file on the canonical skeleton (task, context, sequential_thinking, todos, authorization, constraints, output_contract, validation, example).

Examples

1. Minimal — positional goal only

/proofpunk:forge-prompt "code review assistant for a Go monorepo"

Authors a complete .prompt.md on the canonical XML skeleton with the always-on workflow (thinking, todos, authorization, file-output).

2. With flags — control output and depth

/proofpunk:forge-prompt "incident triage runbook prompt" --out prompts/triage.prompt.md --depth advanced

Writes to an explicit path with the advanced tag set (edge cases, failure modes, output contract).

3. Composed — forge, rate, iterate until it ships

/proofpunk:forge-prompt "support-agent system prompt" --out prompts/support.prompt.md
/proofpunk:rate-prompt prompts/support.prompt.md --in-place

Forge v1, then RATE it against the 100-point rubric and remediate in place until the threshold is met.

5. Full command — every option selected

/proofpunk:forge-prompt author "migration plan for Postgres 15 → 17 across 3 services" --out .planning/pg17.prompt.md --depth advanced

AUTHOR mode, advanced depth (full evaluation + remediation guidance) written to a named file — ready for rate-prompt and then implement.

Activate the implement skill and run it against:

$ARGUMENTS

Follow the skill's execution loop exactly: distill TRUE success criteria (get explicit approval if they are not self-evident), decompose into tasks, execute each task to completion, and validate only through end-user testing that produces proof. Report the criteria-proof table when done.

Examples

1. Minimal — positional goal only

/proofpunk:implement "team workspaces with invite flow"

Distills TRUE criteria (asks for approval if not self-evident), then runs all stages 0-7 interactively.

2. With flags — control the execution mode

/proofpunk:implement "migrate billing to Stripe" --mine --parallel --auto

Mines past sessions first, fans scouts/plan-stages/build-lanes out with executable lane contracts, and never stops until every criterion is proven.

3. Composed — chained with other commands

/proofpunk:forge-prompt "billing migration build" --out .prompts/billing.prompt.md
/proofpunk:implement .prompts/billing.prompt.md

Forge the build prompt first, review it, then implement from the approved prompt with tests-first per task.

4. Full command — every option selected

/proofpunk:implement "add Stripe billing webhooks with signature verification" --parallel --auto --mine

Mines past sessions first, fans out scouts, forges the prompt, decomposes with proof obligations, runs independent lanes in parallel with executable lane contracts, tests before code per task, and never stops until every criterion is proven. The write path never creates test files — validation is the completed user job.

/proofpunk:install — project memory installer

Sets up the memory layer that makes the doctrine stick in THIS project using the conventions of the platform you're running on. Platform defaults (verified against vendor docs, 2026-08-13):

Also know the asymmetries: Claude Code auto-loads @path references from CLAUDE.md; OpenCode does NOT — the AGENTS.md template therefore instructs explicit on-demand reads instead of @ imports.

Acceptance criteria (all must hold — report each)

• The platform's memory file exists, is ≤ 200 lines, and uses the correct name for the platform (table above).
• Doctrine lives inside <!-- proofpunk:begin --> … <!-- proofpunk:end --> markers; nothing outside the markers was edited.
• Scoped rule files exist in the platform's rules directory with valid frontmatter (skipped cleanly with --no-rules).
• The verification block at the end was actually run, output in the report.

Step 1 — Detect (report findings, don't ask)

Platform: --platform if given; otherwise infer from the agent you are (Claude Code → claude-code; OpenCode → opencode; OMP → omp; else agents). Project: stack manifests (package.json/pyproject/go.mod/Cargo.toml), the root directory name, existing memory files (CLAUDE.md AND AGENTS.md — note both, they interact per the table), existing rules dirs, and whether the project is a TUI (ink/textual/ratatui in dependencies).

Step 2 — Write or merge the memory file

Template: assets/claude-md-template.md (claude-code/omp) or assets/agents-md-template.md (opencode/agents) in this plugin — read the right one. Substitute {{PROJECT_NAME}}, {{TEST_COMMAND}} {{BUILD_COMMAND}} with detected values (omit lines with no detected value — never write "unknown").

• No existing file → create from the template.
• Existing file → merge: replace an existing marked section in place otherwise append it. Never edit outside the markers.
• Both CLAUDE.md and AGENTS.md exist on opencode → warn that AGENTS.md wins and CLAUDE.md is ignored by OpenCode; merge into AGENTS.md only.
• --clobber → replace the whole file (explicit opt-in).
• After writing: count lines; if >200, compress the proofpunk section (never the user's own content outside markers).

Step 3 — Write scoped rules (skip with --no-rules)

From assets/rules/ in this plugin:

• claude-code/omp: write into .claude/rules/ — proof-obligations.md (global), evidence-contract.md (paths: evidence dirs), tui-driving.md (only when Step 1 detected a TUI).
• opencode: same three files into .opencode/rules/ (the opencode-rules plugin convention); if that plugin isn't installed, say so and note that unscoped rules still apply via AGENTS.md.
• agents: no rules directory convention — fold the proof-obligations rule into the AGENTS.md marked section instead.

Never overwrite a differing existing rule file — report the conflict and write <name>.proofpunk.md instead (unless --clobber).

Step 4 — Verify (run this, paste real output)

wc -l CLAUDE.md AGENTS.md 2>/dev/null
wc -l .claude/rules/*.md .opencode/rules/*.md 2>/dev/null
grep -c "proofpunk:begin" CLAUDE.md AGENTS.md 2>/dev/null
head -3 .claude/rules/proof-obligations.md .opencode/rules/proof-obligations.md 2>/dev/null
tail -n 3 ~/.claude/proofpunk-loads.jsonl 2>/dev/null || echo "no load log yet (fires next session)"

Report

Table: file | action (created/merged/skipped/conflict) | lines. Then the acceptance checklist with PASS/FAIL per row. A partial install is reported UNVERIFIED, never "done".

Examples

/proofpunk:install                                        # detect platform, merge, rules, verify
/proofpunk:install --platform opencode                    # AGENTS.md + .opencode/rules/
/proofpunk:install --platform agents --no-rules           # AGENTS.md only, rules folded in
/proofpunk:install --clobber                              # replace the memory file wholesale
/proofpunk:install --platform claude-code --no-rules --clobber   # every option selected

Activate the prompt-forge skill and run its RATE workflow on:

$ARGUMENTS

Write NAME.rating.md plus the remediated prompt file per the skill's file-output contract. Unexecuted suggestions are UNVERIFIED — remediate, do not merely advise.

Examples

1. Minimal — positional file only

/proofpunk:rate-prompt prompts/support.prompt.md

Scores against the 100-point rubric, writes support.rating.md, and applies remediations to a NEW file (default consent level).

2. With flags — consent and output control

/proofpunk:rate-prompt prompts/support.prompt.md --in-place --report-only

Rates and reports without rewriting: the rating file lands, the prompt is untouched.

3. Composed — regression-test a prompt change like code

/proofpunk:rate-prompt prompts/v2.prompt.md --out prompts/v2.remediated.md
/proofpunk:verify "run both prompt versions against the 3 failure cases and diff the outputs"

Rate the revision, then end-user-test the behavioral difference with executed evidence — no vibes-based prompt reviews.

4. Redirected output — remediate and ship regardless of score

/proofpunk:rate-prompt .planning/pg17.prompt.md --out .planning/pg17.remediated.md --ship-below-threshold

Scores against the 7-dimension /100 rubric, remediates, and writes the remediated file to the given path. Note: --in-place and --out are exclusive (same-file edit vs. separate output); --report-only and --out are also exclusive (scorecard-only vs. writing a redirected deliverable) — they conflict and fail fast if combined. --ship-below-threshold finalizes even if the result grades needs-work/rewrite; omit it to require a passing score before shipping.

Activate the codebase-truth-audit skill and audit:

$ARGUMENTS

Ground every conclusion in a commit, command output, or path:line that resolves in the checked-out tree. Pause for explicit approval before any behavior-changing or destructive remediation.

Examples

1. Minimal — audit the current repo

/proofpunk:truth-audit .

Full intent-vs-implementation audit with evidence-backed findings; pauses before any behavior change.

2. With flags — bound the window

/proofpunk:truth-audit . --start 2026-06-01 --label pre-release

Audits only the June-forward window and tags all evidence with the pre-release label.

3. Composed — audit, then harden what the audit surfaces

/proofpunk:truth-audit . --label q3
/proofpunk:implement "remediate the 3 HIGH findings from the q3 truth audit"

The audit produces the findings; implement executes the approved remediation to end-user proof.

5. Full command — every option selected

/proofpunk:truth-audit . --start 2026-01-01 --end 2026-08-13 --label fy26-h2-audit

Windowed session-intent alignment across the whole repo, every commit in the window mapped to its transcript intent or marked unrecoverable, labeled evidence pack under .planning/audits/fy26-h2-audit/.

Run end-user validation directly — the same protocol implement runs inline in Stage 5 (platform detection via references/platform-routing.md, then the matching references/*-validation.md runbook), with the proof standard owned by end-user-testing:

$ARGUMENTS

Run the real system (server, CLI, UI) and exercise the actual user flows. Every claim in the final report must cite executed evidence — a command output, response, or artifact. Unexecuted checks are UNVERIFIED, never PASS.

Examples

1. Minimal — verify the work just completed

/proofpunk:verify

Detects the platform, starts the real runtime, drives the feature as the end user, emits a cited verdict.

2. With a scope — verify one flow

/proofpunk:verify "password reset flow, from email link to dashboard"

Scoped end-user test: only the named flow is driven, but every step still requires executed evidence.

3. Composed — prove a implement run before accepting it

/proofpunk:implement "stripe webhook handler"
/proofpunk:verify "deliver a test webhook and confirm idempotent processing"

Implement builds and proves per task; verify independently re-proves the user-visible outcome before sign-off.

4. Scoped — everything you can select

/proofpunk:verify src/checkout

verify takes a single positional scope — there are no flags to combine. Everything else is the proof standard: fresh run-scoped evidence, the assertion defined first, verdict citing full paths.