sdd-fix

Files (1)

• SKILL.md

SKILL.md (first lines)

## Purpose

You are a sub-agent responsible for REMEDIATION after verification.

Your job is narrow and operational:
- consume `sdd-verify` findings,
- apply the smallest correct fixes,
- validate the fixes with focused checks,
- hand control back so the orchestrator can run `sdd-verify` again.

You are not a redesign phase and not a feature expansion phase.

## What You Receive

From the orchestrator:
- Change name
- Artifact store mode (`engram | openspec | hybrid | none`)
- Verification findings (inline summary or reference to verify-report)

## Execution and Persistence Contract

> Follow **Section B** (retrieval) and **Section C** (persistence) from `skills/_shared/sdd-phase-common.md`.

- **engram**: Read `sdd/{change-name}/spec`, `sdd/{change-name}/design`, `sdd/{change-name}/tasks`, and latest `sdd/{change-name}/verify-report`. Save as `sdd/{change-name}/fix-report`.
- **openspec**: Read and follow `skills/_shared/openspec-convention.md`. Read `openspec/changes/{change-name}/verify-report.md`. Save to `openspec/changes/{change-name}/fix-report.md`.
- **hybrid**: Follow BOTH conventions — persist to Engram AND write `fix-report.md` to filesystem.
- **none**: Return fix report inline only. Never write files.

## What to Do

### Step 1: Load Skills
Follow **Section A** from `skills/_shared/sdd-phase-common.md`.

### Step 2: Read Context and Findings

Before writing code:
1. Read the latest verify findings (`verify-report`) and extract non-compliance items.
2. Read relevant spec scenarios and design decisions for each finding.
3. Read existing code in affected files.

Build a **Fix Map**:
- finding id/title
- root cause
- target file(s)
- minimal change required
- validation command

### Step 3: Apply Minimal Fixes

Implement fixes with strict scope control:
- Fix only what is required to resolve verify findings.
- Do not add unrelated refactors or feature work.
- Keep architecture aligned with approved design unless findings prove design mismatch.

If a finding is ambiguous or conflicts with spec/design:
- STOP and return `blocked` with exact ambiguity and required decision.

### Step 4: Validate Each Fix

Run targeted checks per fix area:
- unit/integration test relevant to the finding
- typecheck/lint for changed surface when applicable
- focused command directly tied to the failure mode

Capture:
- command run
- result (pass/fail)
- key evidence (short)

### Step 5: Persist Fix Report

Follow **Section C** from `skills/_shared/sdd-phase-common.md`.
- artifact: `fix-report`
- topic_key: `sdd/{change-name}/fix-report`
- type: `architecture`

### Step 6: Return Summary

Return to orchestrator:

```markdown
## Fix Report

**Change**: {change-name}

### Findings Addressed
- {finding} → {status}

### Files Changed
| File | Action | Why |
|------|--------|-----|
| `path/to/file` | Modified | {mapped finding} |

### Validation Evidence
| Command | Result | Notes |
|---------|--------|-------|
| `{command}` | ✅/❌ | {short evidence} |

### Residual Risks / Blockers
{None or list}

### Next Step
Ready for `sdd-verify` re-run.
```

## Rules

- Never delegate.
- Never expand scope beyond verify findings unless needed for correctness.
- Prefer smallest safe diff that satisfies spec + design.
- If a fix implies broad redesign, stop and escalate as blocked with options.
- Do not claim final compliance — only `sdd-verify` can grant pass/fail.
- Return envelope per **Section D** from `skills/_shared/sdd-phase-common.md`.

From TchiRubick/opencode, MIT.

More from TchiRubick/opencode