Implements the plan tasks following specs and design, marking progress as it goes.

/sdd-apply <change-name>

• mem_search(query: "sdd/{change-name}/design")

  →

  mem_get_observation(id)

  .
• If not found and Engram not reachable: design content passed inline from orchestrator.

scope_guard_triggered = true
for each file in design.md file change matrix:
    if file extension not in [".md", ".yaml", ".yml"]:
        scope_guard_triggered = false
        break
if scope_guard_triggered:
    → report: "Tech skill preload: skipped (documentation-only change)"
    → skip remainder of Step 0

~/.claude/skills/solid-ddd/SKILL.md

~/.claude/skills/react-native/SKILL.md

~/.claude/skills/react-19/SKILL.md

~/.claude/skills/nextjs-15/SKILL.md

~/.claude/skills/typescript/SKILL.md

~/.claude/skills/zustand-5/SKILL.md

~/.claude/skills/tailwind-4/SKILL.md

~/.claude/skills/go-testing/SKILL.md

Note:

react native

and

expo

are matched before

react

to avoid the shorter keyword absorbing the longer one. Match order is top-to-bottom.

Note: The

always (non-doc changes)

row is evaluated after the scope guard. If

scope_guard_triggered

is

true

(documentation-only change), this row is also skipped.

Note: This table only lists skills that exist in the global catalog. If a skill path does not exist on disk, it is silently skipped.

• If the file exists on disk → read its contents and load its patterns into context
• If the file does not exist on disk → skip silently; note:

  "<skill-name>: skipped (file not found at <path>)"

status: blocked

status: failed

1. The tasks artifact — which tasks are assigned:

   • mem_search(query: "sdd/{change-name}/tasks")

     →

     mem_get_observation(id)

     .
   • If not found and Engram not reachable: tasks content passed inline from orchestrator.
2. The spec artifact — the success criteria (WHAT it must do):

   • mem_search(query: "sdd/{change-name}/spec")

     →

     mem_get_observation(id)

     .
   • If not found and Engram not reachable: spec content passed inline from orchestrator.
3. The design artifact — how to implement it (technical decisions, interfaces):

   • mem_search(query: "sdd/{change-name}/design")

     →

     mem_get_observation(id)

     .
   • If not found and Engram not reachable: design content passed inline from orchestrator.
4. Project config file (

   config.yaml

   at project root) — if it exists, read optional keys:

   diagnosis_commands

   ,

   rules

5. ai-context/conventions.md

   — code conventions
6. Existing code files that I will modify or that serve as pattern references

config.yaml

tdd

• tdd: true

  or

  tdd.enabled: true

  → TDD mode is ON. Report:

  "TDD mode: ON (source: config)"

• tdd: false

  or

  tdd.enabled: false

  → TDD mode is OFF. Report:

  "TDD mode: OFF (explicitly disabled in config)"

  . Skip Sources 2 and 3.
• Key not present → continue to heuristic detection (Sources 2 and 3).

playwright

pytest

vitest

jest

signal_count++

*.test.*

*.spec.*

test_*

*_test.*

signal_count++

• signal_count >= 2

  → TDD mode is ON. Report:

  "TDD mode: ON (source: testing skill + test files)"

• signal_count == 1

  → TDD mode is OFF. Report:

  "TDD mode: OFF ([signal found] but insufficient signals)"

• signal_count == 0

  → TDD mode is OFF. Report:

  "TDD mode: OFF"

config.yaml

diagnosis_commands

• Present: I run each listed command (expected to be read-only). I capture the output (or a summary) for inclusion in the

  DIAGNOSIS

  block. A command that exits non-zero is recorded as a failure; it MUST NOT block the Diagnosis Step — I note the failure in the Risk field and continue.
• Absent: I use only auto-detected read-only commands relevant to the task (or none). I note

  "diagnosis_commands: not configured"

  in the block.

1. I check for warnings per Step 5a (MUST_RESOLVE blocks; ADVISORY is logged and continues)
2. I read the task in tasks.md — extract

   task_id

   (e.g.,

   1.1

   ,

   2.3

   )
3. Check attempt counter BEFORE attempting the task:
   • If

     attempt_counter[task_id]

     is undefined → set

     attempt_counter[task_id] = 0

   • If

     attempt_counter[task_id] >= max_attempts

     :
     • → Mark task

       [BLOCKED]

       in tasks.md (see BLOCKED State section below)
     • → Halt the current phase immediately
     • → Report BLOCKED state to user (see BLOCKED Reporting section below)
     • → STOP — do NOT continue to the next task
4. Increment attempt counter:

   attempt_counter[task_id]++

   — record the current strategy snapshot:

   file_snapshot = list of all files this attempt will modify

5. I consult the specs for the affected domain (success criteria)
6. I consult the design (interfaces, decisions, patterns)
7. I read existing code in related files (to follow the pattern)
8. I implement the task following specs and design
9. Check success:
   • Success (all file operations complete, output as expected, no tool errors):
     • Mark task

       [x]

       in tasks.md
     • Optionally reset

       attempt_counter[task_id] = 0

       (clean state)
     • Proceed to next task
   • Failure (tool error, validation error, unexpected output):
     • Capture current

       file_snapshot_after

       and the error output
     • Same-strategy detection: compare

       file_snapshot_after

       with the snapshot from the previous attempt (if any):
       • If both attempts modified the same files in the same way (see Same-Strategy Detection below):
         • → Mark task

           [BLOCKED]

           with message

           "Identical strategy attempted twice — manual intervention required"

         • → Halt the current phase
         • → Report BLOCKED state to user
         • → STOP — do NOT continue to the next task
       • Otherwise (different strategy):
         • Increment

           attempt_counter[task_id]

           again
         • If

           attempt_counter[task_id] >= max_attempts

           :
           • → Mark task

             [BLOCKED]

             (see BLOCKED State section below)
           • → Halt phase, report to user
           • → STOP — do NOT continue to the next task
         • Otherwise: re-attempt the task with a different approach (loop back to step 8)

tasks.md

- [ ] X.Y description

- [BLOCKED] X.Y description

- [BLOCKED] Task X.Y — description
  - Attempts: N/max_attempts
  - Tried:
    1. [summary of first attempt: what files were modified, what error occurred]
    2. [summary of second attempt]
    3. [summary of third attempt]
  - Last error: [the error message or output from the final attempt]
  - Resolution required: [specific, actionable instruction for the user — not vague]

• What files were modified in that attempt
• What error or failure was observed
• For same-strategy detection blocks: note "Identical strategy detected"

1. I check for warnings per Step 5a (MUST_RESOLVE blocks; ADVISORY is logged and continues)
2. I read the task in tasks.md — extract

   task_id

3. Check attempt counter BEFORE attempting the task (same logic as standard flow step 3): if

   attempt_counter[task_id] >= max_attempts

   , mark

   [BLOCKED]

   , halt phase, report to user, STOP.
4. Increment attempt counter:

   attempt_counter[task_id]++

5. I consult the specs for the affected domain — identify the Given/When/Then scenarios this task covers
6. I consult the design (interfaces, decisions, patterns)
7. I read existing code in related files (to follow the pattern)
8. RED — Write a failing test:
   • I write a test that captures the expected behavior from the spec scenario(s)
   • The test name or description SHOULD reference the spec scenario name
   • I run the test to confirm it fails. If it passes unexpectedly, I report a DEVIATION noting the behavior was already implemented
9. GREEN — Write minimum code to pass:
   • I write only the minimum code necessary to make the test pass
   • I do NOT add extra features, optimizations, or abstractions in this phase
   • I run the test to confirm it passes
10. REFACTOR — Clean up while tests stay green:
    • I clean up the code (remove duplication, improve naming, etc.)
    • I run the tests after refactoring to confirm they still pass
    • If a test breaks during refactoring, I fix the code (not the test) to restore the green state
11. I mark the task as complete in tasks.md:

    - [x]

    — only after REFACTOR is done

• I do NOT fix it silently
• I note it in my report as "DEVIATION: [what and why]"
• If it is a blocker, I stop and report

  status: blocked

[x]

1. Single Responsibility (SRP): Does each new or modified class, function, or module have exactly one reason to change? Signal: can it be described in one sentence without using "and"? If not →

   QUALITY_VIOLATION: SRP — <description>

   .
2. Abstraction appropriateness (OCP): Is new behavior added via extension (new file/class/interface) rather than modification of existing stable code? Are abstractions justified by actual reuse or testability need today — not speculatively? Premature abstractions with no current consumer →

   QUALITY_VIOLATION: OCP — <description>

   .
3. Dependency direction (DIP): Do high-level modules depend on abstractions (interfaces/ports), not on concrete implementations? Dependencies pointing inward toward stable abstractions → PASS. Outward dependencies on volatile implementations →

   QUALITY_VIOLATION: DIP — <description>

   .
4. Domain model integrity: Is business logic inside domain objects (entities, aggregates, value objects), not leaked into services or controllers? An anemic domain model (domain objects with only getters/setters and no behavior) →

   QUALITY_VIOLATION: Domain model — <description>

   . Mark N/A if the task does not touch domain model code.
5. Layer separation: Does the code respect the architectural layers defined in the design (e.g., domain → application → infrastructure)? Cross-layer leakage (e.g., infrastructure detail in a domain entity) →

   QUALITY_VIOLATION: Layer separation — <description>

   .
6. No scope creep: Does the implementation stay strictly within the task's defined scope (tasks.md + design.md)? Files or features outside the scope →

   QUALITY_VIOLATION: Scope creep — <description>

   , escalated to

   DEVIATION

   if it contradicts an observable behavior in the spec.
7. Naming clarity: Do names (classes, functions, variables) reveal intent without requiring a comment to explain them? If a name needs a comment to be understood, rename it first →

   QUALITY_VIOLATION: Naming — <description>

   .

• N/A — [one-line reason]

  : the criterion does not apply to this task (e.g., "task adds a CLI flag — no domain model touched").

• QUALITY_VIOLATION: <principle> — <description>

  : criterion fails. Fix the code BEFORE marking

  [x]

  . If fixing requires scope outside this task, report as

  DEVIATION: <principle> — <description>

  and set

  status: warning

  .
• Non-contradicting violations do NOT block the apply phase. The orchestrator MUST surface all

  QUALITY_VIOLATION

  notes in the phase summary.
• A violation that contradicts a scenario in the spec MUST be escalated to

  DEVIATION

  and MUST set

  status: warning

  .

• I implement the minimum necessary to pass the spec's scenarios
• I do not add features that are not in the proposal
• I do not refactor code that is not part of the change

{
  "status": "ok|warning|blocked|failed",
  "summary": "Implemented [N] tasks of [total]. Phase [X] complete. [TDD mode: active — RED/GREEN/REFACTOR cycle used per task.]",
  "tdd_mode": true,
  "artifacts": [
    "src/services/auth.service.ts — created",
    "src/types/auth.types.ts — created",
    "engram:sdd/{change-name}/tasks — updated"
  ],
  "deviations": ["DEVIATION in task 2.1: [description and reason]"],
  "next_recommended": ["sdd-apply (Phase 2) — if more phases remain", "/sdd-verify <change-name> — verify against specs before committing (run after all phases are complete)"],
  "risks": []
}

The

tdd_mode

field is

true

when TDD mode was active,

false

otherwise. When

true

, the

summary

field mentions that TDD mode was used.

Implementation complete — next step: When all phases are done, the only permitted next-step suggestion is:

Continue with verification? Reply **yes** to proceed or **no** to pause.
_(Manual: `/sdd-verify <change-name>`)_

The summary MUST NOT suggest

/commit

or

git commit

at any phase.

• I read specs BEFORE writing code — they are my acceptance criteria
• I follow design decisions — I do not ignore or silently improve them
• I follow existing project patterns — I do not introduce new ones without justification
• I mark tasks as completed AT THE MOMENT I finish them
• If a task is blocked, I stop and report — I do not skip it
• I do not implement tasks outside my assigned scope
• I do not modify specs or design during implementation
• If something in the spec is ambiguous, I ask before assuming

• MUST_RESOLVE

  warnings MUST block execution until the user provides an explicit answer — there is no skip option

• ADVISORY

  warnings MUST be logged to output but MUST NOT interrupt the execution flow or request user input