pixelheros/CCGS Skill Testing Framework/skills/utility/release-checklist.md

Skill Test Spec: /release-checklist

Skill Summary

/release-checklist generates an internal release readiness checklist covering: sprint story completion, open bug severity, QA sign-off status, build stability, and changelog readiness. It is an internal gate — not a platform/store checklist (that is /launch-checklist). When a previous release checklist exists, it shows a delta of resolved and newly introduced issues.

The skill writes its checklist report to production/releases/release-checklist-[date].md after a "May I write" ask. No director gates apply — /gate-check handles formal phase gate logic. Verdicts: RELEASE READY, RELEASE BLOCKED, or CONCERNS.

---

Static Assertions (Structural)

Verified automatically by /skill-test static — no fixture needed.

• Has required frontmatter fields: name, description, argument-hint, user-invocable, allowed-tools
• Has ≥2 phase headings
• Contains verdict keywords: RELEASE READY, RELEASE BLOCKED, CONCERNS
• Contains "May I write" collaborative protocol language before writing the report
• Has a next-step handoff (e.g., /launch-checklist for external or /gate-check for phase)

---

Director Gate Checks

None. /release-checklist is an internal audit utility. Formal phase advancement is managed by /gate-check.

---

Test Cases

Case 1: Happy Path — All Sprint Stories Complete, QA Passed, RELEASE READY

Fixture:

• production/sprints/sprint-008.md — all stories are Status: Done
• No open bugs with severity HIGH or CRITICAL in production/bugs/
• production/qa/qa-plan-sprint-008.md has QA sign-off annotation
• Changelog entry for this version exists
• production/stage.txt contains Polish

Input: /release-checklist

Expected behavior:

1. Skill reads sprint-008: all stories Done
2. Skill reads bugs: no HIGH or CRITICAL open bugs
3. Skill confirms QA plan has sign-off
4. Skill confirms changelog entry exists
5. All checks pass; skill asks "May I write to production/releases/release-checklist-2026-04-06.md?"
6. Report written; verdict is RELEASE READY

Assertions:

• All 4 check categories are evaluated (stories, bugs, QA, changelog)
• All items appear with PASS markers
• Verdict is RELEASE READY
• "May I write" is asked before writing

---

Case 2: Open HIGH Severity Bugs — RELEASE BLOCKED

Fixture:

• All sprint stories are Done
• production/bugs/ contains 2 open bugs with severity HIGH

Input: /release-checklist

Expected behavior:

1. Skill reads sprint — stories complete
2. Skill reads bugs — 2 HIGH severity bugs open
3. Skill reports: "RELEASE BLOCKED — 2 open HIGH severity bugs must be resolved"
4. Both bug filenames are listed in the report
5. Verdict is RELEASE BLOCKED

Assertions:

• Verdict is RELEASE BLOCKED (not CONCERNS)
• Both bug filenames are listed explicitly
• Skill makes clear HIGH severity bugs are blocking (not advisory)

---

Case 3: Changelog Not Generated — CONCERNS

Fixture:

• All stories Done, no HIGH/CRITICAL bugs
• No changelog entry found for the current version/sprint

Input: /release-checklist

Expected behavior:

1. Skill checks all items
2. Changelog check fails: no changelog entry found
3. Skill reports: "CONCERNS — Changelog not generated for this release"
4. Skill suggests running /changelog to generate it
5. Verdict is CONCERNS (advisory — not a hard block)

Assertions:

• Verdict is CONCERNS (not RELEASE BLOCKED — changelog is advisory)
• /changelog is suggested as the remediation
• Other passing checks are shown in the report
• Missing changelog is described as advisory, not blocking

---

Case 4: Previous Release Checklist Exists — Delta From Last Release

Fixture:

• production/releases/release-checklist-2026-03-20.md exists
• Previous: 1 story was incomplete, 1 HIGH bug open
• Current: all stories Done, HIGH bug resolved, but now 1 MEDIUM bug appeared

Input: /release-checklist

Expected behavior:

1. Skill finds the previous checklist and loads it
2. New checklist is generated and compared:
   • Newly resolved: "Story [X] — was open, now Done"
   • Newly resolved: "HIGH bug [filename] — was open, now closed"
   • New item: "1 MEDIUM bug appeared (advisory)"
3. Delta section shows all changes prominently
4. Verdict is CONCERNS (MEDIUM bug is advisory, not blocking)

Assertions:

• Delta section appears in the report with resolved and new items
• Newly resolved items from the previous checklist are noted
• New items not present in the previous checklist are highlighted
• Verdict reflects current state (not previous state)

---

Case 5: Director Gate Check — No gate; release-checklist is an internal audit

Fixture:

• Active sprint with stories and bug reports

Input: /release-checklist

Expected behavior:

1. Skill runs the full checklist and writes the report
2. No director agents are spawned
3. No gate IDs appear in output

Assertions:

• No director gate is invoked
• No gate skip messages appear
• Verdict is RELEASE READY, RELEASE BLOCKED, or CONCERNS — no gate verdict

---

Protocol Compliance

• Checks sprint story completion status
• Checks open bug severity (CRITICAL/HIGH = BLOCKED; MEDIUM/LOW = CONCERNS)
• Checks QA plan sign-off status
• Checks changelog existence
• Compares against previous checklist when one exists
• Asks "May I write" before writing the report
• Verdict is RELEASE READY, RELEASE BLOCKED, or CONCERNS

---

Coverage Notes

• Build stability verification (no failed CI runs) is listed as a check category but relies on external CI system state; the skill notes this as a MANUAL CHECK if CI integration is not configured.
• CRITICAL bugs always result in RELEASE BLOCKED regardless of other items; this is equivalent to the HIGH severity case in Case 2.
• Stories with Status: In Review (not Done) are treated as incomplete and result in RELEASE BLOCKED; this edge case follows the same pattern as the HIGH bug case.