plan-harden

name	plan-harden
description	Risk-triggered plan reinforcement that deepens verification, rollback, and guardrail detail before plan review

Plan Hardening

Strengthen an implementation plan before review when the work has elevated runtime, migration, security, or blast-radius risk. This is a narrow middle step between impl-plan and plan-review, not a general meta-orchestrator.

When to Use

Invoke after impl-plan when the plan shows one or more hardening signals:

• public API, schema, or contract changes
• auth, security, permission, or compliance-sensitive behavior
• migrations, backfills, destructive data/config actions, or irreversible steps
• external integrations, operator checkpoints, or partial-rollout complexity
• high runtime or rollback risk

Inputs

• plan_path: (Required) Path to the plan file in docs/exec-plans/.

Output

The same plan file, updated with a ## Plan Hardening section that records:

• risk triggers and protected invariants
• reinforced instructions and learnings consulted
• risky actions using the ProposedAction / ActionRisk / ActionResult vocabulary when applicable
• added verification, rollback, monitoring, and operator-checkpoint detail

Required Protocol

When the agent-intercom capability pack is installed, follow .github/instructions/agent-intercom.instructions.md: broadcast when plan hardening starts, call out blocked approval or rollout questions, and warn if operator visibility is degraded.

When the agent-engram capability pack is installed, follow .github/instructions/agent-engram.instructions.md: prefer indexed search when retrieving related modules, prior closure artifacts, or implementation patterns.

When the strict-safety capability pack is installed, also follow .github/instructions/strict-safety.instructions.md: classify risky actions, approval boundaries, and expected rollback states explicitly rather than leaving them implicit.

Phase 1: Read the Plan and Confirm Hardening Need

1. Read the plan file.
2. Extract the hardening signals, runtime surfaces, risky actions, and open rollout questions.
3. Confirm whether extra hardening is required before plan review.

If the plan does not materially need hardening, append a short note explaining why and return the same plan path.

Phase 2: Pull Reinforcing Context

1. Search docs/compound/ for related incidents, prior fixes, or known rollout traps.
2. Re-read any instruction files that apply to the affected surfaces.
3. Identify missing operational detail: verification depth, approval path, fallback path, rollback coupling, owner, or validation window.

Phase 3: Harden the Plan

Enrich the plan so risky work is specific and reviewable:

• state the exact high-risk triggers and invariants to preserve
• enumerate risky actions as ProposedAction entries when the work has destructive, contract, migration, or high-blast-radius potential
• assign ActionRisk for each risky action and note whether approval is needed
• deepen runtime verification with environment prechecks, target scenarios, and blocked-path handling
• deepen operational closure with monitoring signals, rollback triggers, rollback procedure, owner, and validation window
• call out human checkpoints, partial-rollout constraints, or fallback paths for external integrations and browser/runtime dependencies

Phase 4: Append the Hardening Record

Append a ## Plan Hardening section to the plan with:

• whether hardening was required and why
• the learnings and instruction files consulted
• any ProposedAction / ActionRisk entries that must be carried forward
• the added verification, closure, and rollback detail
• unresolved operator decisions that still block safe execution

Quality Criteria

• risky plans become more specific, not just longer
• verification, rollback, and monitoring gaps are closed or explicitly called out
• prior learnings are reflected when relevant
• risky actions are classified clearly when the plan has elevated blast radius
• the output remains a single plan artifact that can travel directly into plan-review

Model Routing

This skill operates at Tier 2 (Standard) — risk-triggered plan enrichment from defined signals.

Generated by autoharness | Template: plan-harden/SKILL.md.tmpl