ac-lock

AC Lock Checkpoint

Runs automatically as Phase 4.0, after Tasks Validation and before the first implementation task. Purpose: give the user one final explicit confirmation that the Acceptance Criteria represent what they actually want — before any implementation begins.

Position in flow

[Tasks Validation]
      ↓
[AC Lock Checkpoint]  ← THIS SKILL
      ↓
Per-Task: implementation

Entry conditions

• prd.md, techspec.md, and tasks.md must exist in tasks/prd-{slug}/
• Generates accepted-criteria.md in .claude/feature-state/{slug}/
• If accepted-criteria.md already exists (resume case): skip extraction, ask user to confirm current locked ACs or unlock to re-confirm
• Implementation must not start until this file is saved

---

Step 1: Extract and Consolidate ACs

Sources

Read ACs from all three documents:

From prd.md:

• "Goals" or "Objectives" section (functional success criteria)
• "Acceptance Criteria" section (if present)
• "Success Metrics" section (if present)

From techspec.md:

• "Validation & Testing Plan" section
• "Acceptance Criteria" section (if present)
• Non-functional requirements that can be verified

From tasks.md:

• "Acceptance Criteria" or "Done When" column/field per task
• Any inline criteria in task descriptions

Deduplication

Merge near-duplicate ACs (same intent, slightly different wording):

• "trainerId is saved to Firestore" + "trainerId is persisted on student document" → consolidate as one
• Use the more specific/verifiable version

Classification

Group ACs into three categories:

1. Functional — observable user/system behavior

   • e.g., "Trainer can see their connected students in /cms/students"

2. Technical — implementation-level verifiable criteria

   • e.g., "POST /api/students saves trainerId field"
   • e.g., "Firestore security rules validated"

3. Quality — non-functional, cross-cutting

   • e.g., "All use cases have unit tests"
   • e.g., "No breaking changes to existing API consumers"