Gated Module Implementation

Gated Module Implementation

Overview

• (1) Plan + (2) Audit: Write the implementation plan, run three rounds of plan audit, fix gaps.
• (3) Human — Plan only: Only one human gate: approve the plan before any task runs. No human approval between code review rounds (those are automatic).
• (4) Execute in order by batch: Tasks (e.g. 1–10) run in order. Behavior depends on Execution mode (below).
• (5) Automatic 3-round review: After all tasks and tests pass, run exactly 3 rounds of code review automatically: round 1 → fix Critical/Important → round 2 → fix → round 3. No human confirmation between rounds.

Unit tests: full coverage. E2E: pass. Test report: generated. No skipped tests.

Execution mode

Announce at start: "I'm using the gated-module-implementation skill for this module." If Auto-loop: also say "Auto-loop mode: I will run all execution batches continuously after plan approval."

---

Phase 1: Plan (Required Before Any Code)

1. Clarify scope and dependencies

   • Identify the module boundary, upstream/downstream services, and shared contracts (API, DB, events).
   • Document in a short "Context & Dependencies" section (can live in the plan file or a linked doc).

2. Write the implementation plan

   • REQUIRED SUB-SKILL: Use writing-plans.
   • Save the plan to the correct project plan/ path (see writing-plans for the table).
   • Plan must include explicit tasks for: unit tests (full coverage), E2E tests (fully runnable), and test report generation. No "skip tests" or "TODO tests."

3. Deliverable

   • One plan file at <project>/plan/YYYY-MM-DD-<feature-name>.md with header, goal, architecture, and bite-sized tasks including test steps.

---

Phase 2: Three Rounds of Audit

Run three audit rounds on the plan (and any linked context). Do not proceed to execution until all three are done and issues are addressed.

Round 1 — Completeness & Scope

• Goal and acceptance criteria are clear and testable.
• All touched files (create/modify/test) are listed with exact paths.
• Dependencies on other modules/APIs/DB are documented; no hidden coupling.
• Edge cases and error paths are covered in tasks or tests.

Output: Short checklist result; list any gaps. Fix the plan if gaps found.

Round 2 — Dependencies & Interfaces

• API contracts (request/response, status codes) are specified where the module touches boundaries.
• DB schema changes (if any) are stated; migrations are in the task list.
• Integration points (policy-service, gateway, SaaS, data-warehouse) respect project boundaries (see .cursor/rules/project.mdc).

Output: Short checklist result; list any conflicts or missing interface specs. Update plan if needed.

Round 3 — Test Strategy & Rollout

• Unit test tasks exist for all new/edited behavior; plan states "full coverage" (or equivalent) and no skipped tests.
• E2E test tasks exist and are runnable (commands and expected pass condition stated).
• A task generates a test report (e.g. coverage report, E2E summary); artifact path or command documented.
• Rollback or feature-flag approach is considered if relevant.

Output: Short checklist result; list any missing test or report steps. Update plan until satisfied.

After Round 3, present a one-paragraph Audit Summary (all three rounds) and say: "Plan ready for human review. Please confirm before execution."

---

Phase 3: Human Review — Plan Approval Only (Once)

Only one human review is required: approve the plan before any task execution. No human approval is needed before or between code review rounds (those are automatic). In Auto-loop mode, there is no human confirmation between Phase 4 batches — only this single plan approval.

Single checkpoint — Approve plan (before first task)

• Present: plan path, goal, audit summary, and any open risks.
• Do not start Phase 4 until the human explicitly confirms (e.g. "approved" / "go ahead" / "execute").
• If the human requests plan changes, update the plan and optionally re-run the relevant audit round(s), then ask for confirmation again.

Between execution batches (Gated mode only)

• Gated mode: After each batch (e.g. tasks 1–3 done): report what was done, show verification, wait for human confirmation before starting the next batch (e.g. 4–6). Tasks run in order; between batches you need "continue" / "go".
• Auto-loop mode: Do not wait for human between batches. After each batch: report and update task state, then proceed immediately to the next batch until all tasks are done.

---