Menu
Team-lead drives plan hardening after the current plan state already exists in repo docs.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Guide a consuming repository through `sc-lint-version` adoption using the authoritative consumer-integration workflow, existing CLI testability seams, existing simulators or transcripts, and only thin normalization hooks when unavoidable.
Orchestrate sc-lint sprint work where team-lead coordinates, clint is the sole developer, and quality-mgr enforces the QA gate.
Session initialization for the team-lead identity. Confirms identity and detects whether a full team restore is needed. Only run when ATM_IDENTITY=team-lead.
Run the repo Rust TODO finder during sprint-end or integration review and turn every discovered TODO into a QA finding rather than deferred work.
Orchestrate pre-dispatch QA finding triage as team-lead. Launch one qa-triage agent per finding, collect phase-scoped Turtle records, aggregate by promoted branch, and only then dispatch branch-scoped fix assignments to clint.
Orchestrate multi-sprint phase execution as team-lead. Manages sprint waves, scrum-master lifecycle, PR merges, clint reviews, and integration branch strategy. This skill is for team-lead only, not for scrum-masters.
Basé sur la classification professionnelle SOC
| name | plan-hardening |
| version | 1.4.0 |
| description | Team-lead drives plan hardening after the current plan state already exists in repo docs. |
| depends_on | {"codex-orchestration":"0.x"} |
Audience: team-lead only.
Use this only for phase-plan hardening before implementation starts or resumes.
team-lead routes the process but is not the authority for rewriting the
plandevelop before
startingSprint plan approved by:
plan-scope-reviewercritical-plan-reviewerquality-mgrAlways use:
.claude/skills/plan-hardening/sprint-planning-guidelines.md| # | Route to | Input required | Output expected | Read before executing |
|---|---|---|---|---|
| 1 | clint | vars file | step-1 fenced JSON | steps/step-1.md |
| 2 | plan-scope-reviewer (background) | context + step-1 JSON | step-2 fenced JSON | steps/step-2.md |
| 3 | clint | step-2 JSON | step-3 fenced JSON | steps/step-3.md |
| 4 | critical-plan-reviewer (background) | context + step-3 JSON | step-4 fenced JSON | steps/step-4.md |
| 5 | clint | step-4 JSON | step-5 fenced JSON | steps/step-5.md |
| 6 | quality-mgr | step-5 JSON + QA vars file | codex-orchestration plan-QA handoff | steps/step-6.md |
team-lead must keep a round table for every /plan-hardening run.
Minimum columns:
| Round | Step | Reviewer | reviewed_commit | status | blocking | important | minor | findings_hash | supersedes | Note |
|---|
Use the example in:
.claude/skills/plan-hardening/examples/plan-hardening-rounds.example.mdteam-lead only checks the top-level status and expected mode fields on
each fenced JSON response before advancingreviewed_commit changed or
findings_hash changedreviewed_commit and the same
findings_hash again, treat it as a stale replay and do not open a new
hardening roundFAIL three times without converging, escalate to
the user before continuing.claude/skills/plan-hardening/01-plan-scope-review.xml.j2.claude/skills/plan-hardening/02-sprint-scope-hardening.xml.j2.claude/skills/plan-hardening/03-consistency-hardening.xml.j2.claude/skills/plan-hardening/steps/step-1.md.claude/skills/plan-hardening/steps/step-2.md.claude/skills/plan-hardening/steps/step-3.md.claude/skills/plan-hardening/steps/step-4.md.claude/skills/plan-hardening/steps/step-5.md.claude/skills/plan-hardening/steps/step-6.md.claude/skills/plan-hardening/examples/plan-hardening-vars.example.json.claude/skills/plan-hardening/examples/plan-hardening-rounds.example.md.claude/skills/plan-hardening/examples/plan-hardening-qa-vars.example.json.claude/skills/plan-hardening/sprint-planning-guidelines.md