runtime-procedures

name	runtime-procedures
description	Procedural commands for auto-runtime tracks, completion records, memory workflow, and route-specific work gates. Load when you need the specific commands — the behavioral rules live in CLAUDE.md.

Runtime Procedures

Procedural detail for the autonomous execution surface. CLAUDE.md owns the behavioral rules; this skill owns the commands and checklists.

Auto-Runtime Track Management

Initialize a track for non-trivial work:

python3 ~/.claude/bin/auto_runtime.py init --task "<objective>" --cwd "$PWD"

For autonomous task runs, use the invocation-scoped manager loop:

auto_runtime.py manager-run-task --cwd <repo> --task "<objective>"

Advance the track through dispatch -> verification -> acceptance:

auto_runtime.py cycle

Update slice state with evidence refs on completion:

auto_runtime.py update-node --state accepted --evidence "..."

Operational mechanics (hook wiring, team spawning via TeamCreate/TaskCreate, state directory layout, memory lifecycle gates, readiness checks): ~/.claude/standards/AUTO_RUNTIME.md.

Completion Records (Stop-Gate L2)

Before stopping on non-trivial work, file a structured completion record (completion | blocked | fork). The stop-gate L2 layer validates the record against recorded tool activity; file it before the final response, not after — the Stop hook reads completion.json from disk.

Full procedure (JSON shapes, required fields per kind, example invocation of ~/.claude/bin/claim_complete.py): ~/.claude/standards/STOP_GATE_L2.md.

Completion checklist:

• Don't ask "should I proceed?" unless there is genuine ambiguity about DIRECTION.
• "Default to action" means: execute the next governed step. It does NOT mean: bypass governance checkpoints, reviewer barriers, or verification gates.
• Close the auto-runtime track: mark slices accepted with evidence, then run auto_runtime.py cycle to reach OBJECTIVE_COMPLETE.
• Ask whether there is one more bounded, local, high-leverage step toward the user's real goal. If yes, take it.
• Stop only when the goal is actually satisfied, verification is complete, the track is closed, and further work would open a new track or cross a boundary.

Support Confidence And Closure

• Accepted progress still needs evidence-backed support.
• Missing support triggers remediation-first behavior when safe momentum remains.
• Unsupported closure becomes blocked closure, not reported success.
• Trust output should distinguish strong closure, weak closure, and blocked closure.
• Review must challenge unsupported closure claims explicitly.

Review Requirements

Before delivering non-trivial work, perform both checks:

Self-Audit

• Re-read the request and verify every requirement was addressed.
• Name concrete gaps, assumptions, edge cases, or missing handling.
• Check whether the chosen solution layer matches the real recurrence and spread of the problem.
• Fix each issue you find before finalizing.

Expert Review

• Review for correctness, regressions, failure modes, security, missing tests, and data-flow traceability.
• Was this solved at the highest useful layer, or only the nearest layer?
• Cite concrete file/line references or exact artifacts.
• Fix every real defect found before finalizing.

Memory Workflow

Two-tier model (native markdown memory + omni-mem MCP; architecture detail in ~/.claude/standards/REFERENCE_INDEX.md).

• Use omni-mem retrieval (search, build_context, build_memory_pack) before non-trivial implementation; prefer exact workspace scope via workspaceId.
• Save durable decisions via save_memory; stable preferences via save_preference; session handoffs via journal_write; factual relationships via fact_add.
• Stop hooks auto-trigger memory persistence every 15 exchanges and at compaction.
• Never store secrets in memory.

Non-Trivial Work Gates

R2 (fast worker lane)

• Slice the work into small batches. Implement, test the relevant slice, continue. No planning-gate, no solution ladder, no enterprise scorecard.
• Before any final delivery, run a silent gap review. Fix discoverable gaps internally; ask only when a real ambiguity remains.
• If the work adds persisted state, bootstrap/recovery, or public API growth, apply overengineering guardrails from control_plane.json.
• omni-mem retrieval is recommended, not required.

R3/R4 (governed lanes)

• Use the governed path: omni-mem retrieval -> planning-gate skill -> validation -> finalize_gate.py must return ok=true before approval.
• R3 defaults to single_lane; bounded_swarm requires justification. R4 may use reviewer-centered bounded_swarm under the same rule.
• Full R3/R4 gate set (solution ladder, reuse-first decisions, simplicity budget, enterprise scorecard) is injected on R3/R4/R5 prompts by classify_prompt.py.

Governance Activation

• Act on the UserPromptSubmit hook's route_hint/governance_recommended signals; when governance is recommended and the work is non-trivial, use /govern to orchestrate execution.
• Init tracks for non-trivial work, advance with auto_runtime.py cycle, close with evidence via update-node.