project-plan-hardening

name	project-plan-hardening
description	Converts red-team findings into concrete edits applied consistently across related project plans. Adds kill criteria, launch sequencing, demand validation gates, clean-room tests, and loss-leader budgets. Trigger keywords: apply fixes, harden plan, add kill criteria, sequence launches, apply red-team, fix the plans, add failure thresholds, demand validation.
license	MIT
metadata	{"version":"1.0.0","hermes":{"tags":["Projects","Red-Team","Hardening","Planning","Risk-Management"],"related_skills":[]}}

Hardening Project Plans After Red-Team Review

Systematically convert red-team findings into concrete edits applied consistently across all affected project plans.

Core Principles

1. Analysis without edits is theater — every finding must map to a specific edit or be explicitly marked "accepted risk"
2. Consistency across related plans — shared milestones get identical edits across all copies
3. Preserve plan readability — integrate fixes into existing structure, not bolted-on appendices
4. Make failure explicit — add kill criteria, time checks, demand validation, loss-leader budgets

The Hardening Workflow

Step 1: Inventory Findings

Category	Description
Sequencing	Plans running in parallel that should be sequential
Kill criteria	Missing failure thresholds / exit conditions
Validation gates	Assumptions treated as facts without market evidence
Time/cost reality	Optimistic estimates without experience-based data
Reproducibility	Self-referential tests that don't validate the deliverable
Aspirational economics	Revenue/pricing assumptions without conversion evidence

Step 2: Map Findings to Edits

For each finding: identify affected file(s), target section, and edit type.

Step 3: Apply Edits Consistently

Work through each finding, editing all affected files. Shared milestones get identical edits across plans.

Step 4: Cross-Reference

Add red-team analysis to every affected plan's cross-references.

Step 5: Verify

• Every finding has a corresponding edit or is marked "accepted risk"
• Shared milestones are identical across plans
• Sequencing is consistent (A's "blocked by" matches B's "blocks")
• Kill criteria use concrete thresholds (days, counts), not vague triggers

Hardening Patterns

Kill Criteria

**Kill gate**: If no orders within 60 days of Milestone 3 completion,
downgrade to passive presence and redirect energy.

Must be time-based (30-60 days), activity-based ("after N proposals with zero responses"), and action-specific (defines what "downgrade" means).

Demand Validation

- [ ] **Demand validation**: Check [platform buyer requests] for keywords
  matching your offering. If zero matches, reassess before investing.

Time Checks on Untested Gates

- [ ] **Time check**: Record actual time for [task]. If >[threshold],
  revisit all delivery time estimates before publishing.

Clean-Room Tests

- [ ] **Clean-room test**: Wipe the environment, follow only the written
  documentation (no improvisation), verify [deliverable] works from docs alone.

Launch Sequencing

**Status**: Queued (Launch sequence: 2 of 3)
**Blocked by**: [Previous plan] Milestone [N] gate

Loss-Leader Budgeting

**Loss-leader budget**: The first [N] orders at $[price] are buying reviews,
not earning hourly rate. Budget ~[hours] hours across first [N] orders.

Common Hardening Reference

Addition	Where It Goes	When to Add
Kill criteria	After Milestone 4 gate	Always
Launch sequencing	Plan header + Milestone 3 prerequisite	Multiple plans share resources
Demand validation	First item in Milestone 3	Competitive gap asserted without buyer data
Time check	Last item in Milestone 1	Gate times are estimates
Clean-room test	Last item in Milestone 2	Deliverable includes documentation
Loss-leader budget	Milestone 4 notes	Early pricing below sustainable rate

Key Rules

• Every red-team finding becomes an edit or an explicitly accepted risk — no "recommendations only"
• Apply fixes to ALL affected plans, not just one
• Use concrete kill criteria ("60 days, zero orders") never vague ("if things aren't working out")
• Integrate fixes into relevant milestones, not as separate "Red-Team Fixes" sections
• Sequencing requires explicit blocking dependencies, not just verbal ordering

Insight: red-team skill produces analysis; this skill closes the loop by converting findings into edits.