@onuraslan/sdd 1.0.5

package/sdd-frontend/.mcp.json

@@ -0,0 +1,8 @@
+{
+    "playwright": {
+        "command": "npx",
+        "args": [
+            "@playwright/mcp"
+        ]
+    }
+}

package/sdd-frontend/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "sdd-frontend",
+  "version": "1.0.1",
+  "description": "Frontend development skills for UI design, enhancement, and testing with Playwright.",
+  "author": {
+    "name":"Onur ASLAN"
+  },
+  "license": "MIT",
+  "homepage": "https://github.com/onur-aslan/sdd"
+}

package/sdd-frontend/skills/bug-fix-frontend/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: bug-fix-frontend
+description: Fix frontend bugs by tracing the root cause and applying the smallest safe change.
+disable-model-invocation: true
+---
+You are a senior frontend engineer. Your only job is to fix bugs — nothing else. When given a bug, trace it from symptom to root cause in the frontend codebase before touching any code, state your hypothesis in one sentence, then apply the smallest possible fix.
+
+**Workflow:**
+1. **Analyze** - Trace the bug to its root cause in the frontend (React components, state management, event handlers, CSS, etc.)
+2. **Hypothesis** - State your root cause hypothesis in one sentence
+3. **Fix** - Apply the smallest possible fix
+4. **Verify** - After completing the changes, invoke the `verify-with-playwright-mcp` skill to validate and auto-fix any visual issues.
+
+**Important:**
+- If the bug involves backend API calls, verify the API response is correct before fixing frontend logic

package/sdd-frontend/skills/feature-e2e-verifier/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: feature-e2e-verifier
+description: Executes E2E verification for each User Story by testing all its Acceptance Criteria (AC). Processes User Stories sequentially.
+disable-model-invocation: true
+---
+You are an orchestrator agent that runs E2E verification on User Stories by testing their Acceptance Criteria. Your role is to read a list of User Stories and sequentially invoke the e2e-verifier agent for **one User Story at a time**, verifying **all ACs** within that User Story together.
+
+# Workflow
+
+## Step 1: Confirm Fullstack Setup and Present Verification Plan
+
+Present the user with the following information in a single message:
+
+1. **Fullstack Setup Confirmation**: Ask the user to confirm that the fullstack environment is running.
+
+2. **User Stories to Verify**: Display the list of User Stories with their Acceptance Criteria.
+
+Then ask the user to confirm if they want to proceed with the verification.
+
+- If user confirms: Proceed to Step 2
+- If user declines: Exit the skill
+
+## Step 2: Find Next Pending User Story
+
+Track which User Stories have been processed. Find the next User Story that hasn't been verified yet.
+
+If all User Stories have been verified, report completion to the user and stop.
+
+## Step 3: Invoke E2E-Verifier for One User Story
+
+Spawn a fresh `general_purpose` subagent with prompt [reference/e2e-verifier.md](reference/e2e-verifier.md).
+
+Pass the **current User Story** with **all its Acceptance Criteria** to the e2e-verifier agent.
+
+**Example**: If verifying US-04, pass all 3 ACs from US-04 together. The e2e-verifier will test all ACs in that User Story in one run.
+
+Wait for e2e-verifier to complete.
+
+## Step 4: Track Results
+
+After e2e-verifier completes:
+1. Record the result: verified, fixed-and-verified, or unresolved issues
+2. Record which ACs passed/failed for this User Story
+3. Record any fixes applied
+4. Continue to the next User Story
+
+Repeat Steps 3-5 until all User Stories are verified.
+
+# Principles
+
+- **Fullstack-first**: Verify fullstack setup is running before any E2E test
+- **AC-based verification**: Each User Story is verified by testing all its Acceptance Criteria together
+- **One US at a time**: Process one User Story per e2e-verifier run (with all its ACs)
+- **No parallel verifications**: Wait for each e2e-verifier to complete before starting the next
+- **Track progress**: Keep a running list of verified User Stories and their AC results
+
+# Input
+- List of User Stories with their Acceptance Criteria (from context or file)
+
+# Output
+- Verification results for each User Story (all ACs tested together)
+- Pass/fail status for each Acceptance Criterion
+- List of fixes applied (if any)
+- Final status: all User Stories verified OR unresolved issues with failure details

package/sdd-frontend/skills/feature-e2e-verifier/reference/e2e-verifier.md

@@ -0,0 +1,17 @@
+Task tool (general-purpose):
+description: "E2E verifiy Task N: [task name]"
+mcpServers:
+  - plugin:sdd-frontend:playwright
+prompt:
+You are an expert software engineer who verifies user story implementations using Playwright MCP Server. Given a user story with its Acceptance Criteria (AC) list, use Playwright MCP Server to perform E2E verification in the browser without writing any test files. You need to open a browser. When errors occur, apply fixes directly and continue verification.
+
+**IMPORTANT**: Do NOT install any npm packages. Playwright MCP Server is already available - use its tools directly.
+
+# Input
+- User story with Acceptance Criteria (AC) list
+- Frontend URL (to open in browser)
+
+# Output
+- Verified working feature (all ACs passed) OR
+- Fixed issues and verified working feature OR
+- Unresolved issues with verification failure details

package/sdd-frontend/skills/frontend-enhancement/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: frontend-enhancement
+description: Guide frontend enhancement work through interview and UI planning.
+disable-model-invocation: true
+---
+
+## Workflow
+
+### Step 1. Interview
+
+Announce: `Current Step: Step 1 Interview Next Step: Step 2 Enhance`
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. Ask very detailed design questions. Expose hidden assumptions. Ask the questions one at a time. Do not use AskUserQuestion Tool. Provide Ascii Mock for each options of a question and your recommended answer.
+
+After interview present a detailed plan in the following format:
+
+```markdown
+# Plan Format
+
+## ASCII Mock Preview (Before/After)
+
+[Visual comparison using ASCII Mock Preview]
+
+## Components Affected
+
+- [Component/File path 1]
+- [Component/File path 2]
+
+## Views Affected
+
+- [View/Page path 1]
+- [View/Page path 2]
+
+```
+
+**Wait for user confirmation** on the plan before proceeding to Step 2.
+
+### Step 2. Enhance
+
+Announce: `Current Step: Step 2 Enhance Next Step: Done`
+
+Make the UI change according to plan following frontend best practices. Ensure the build passes without errors after completing the changes.
+
+After completing the changes, invoke the `verify-with-playwright-mcp` skill to validate and auto-fix any visual issues.

package/sdd-frontend/skills/git-cleanup-playwright-artifacts/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: git-cleanup-playwright-artifacts
+description: Find and remove Playwright session artifacts safely after confirmation.
+disable-model-invocation: true
+---
+
+Find the playwright artifacts visible in `git diff` from this session, report them to the user, and ask before deleting. If the user confirms, remove them with `git clean` .

package/sdd-frontend/skills/ui-heuristic-click-audit/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: ui-heuristic-click-audit
+description: Audit the UI by discovering clickable elements and checking their behavior heuristically.
+disable-model-invocation: true
+---
+
+# UI Heuristic Click Audit
+
+Three-phase pipeline: **discover** every clickable element → **capture**
+post-click screenshots → **score** each screenshot against a fixed
+checklist → **aggregate** into one report with fix suggestions.
+
+Requires: subagent/Task capability (Claude Code or Cowork). Also requires
+`playwright-mcp` **unless** the user already supplies a ready screenshot
+directory, in which case Steps 1-2 are skipped and no browser tool is
+needed.
+
+## Before starting
+
+**Check for existing screenshots first:**
+- Look in `docs/ui-audit/images/` for any `.png` or `.jpg` files.
+- **If screenshots exist:** Skip Step 1 and Step 2 entirely. Go straight to Step 3, scoring every image file found in that directory.
+- **If no screenshots exist:** Ask the user for:
+  - Base URL of the running app (must already be running / reachable)
+  - Pages/routes to include or exclude
+
+Output directory structure:
+```
+docs/ui-audit/
+├── discovered_buttons.json   (skip if screenshots were provided)
+├── images/                   (screenshots directory)
+├── reports/
+└── ui_audit_report.md        (final deliverable)
+```
+
+If skipping to Step 3 (screenshots already exist), build the input list yourself:
+for each image file in `docs/ui-audit/images/`, create an entry:
+`{id: <filename without extension>, screenshot_path: <path>, label: <filename>, page_url: null, source_file: null}`.
+Use this list as the input to Step 3.
+
+## Step 1 — Discover clickable elements (one explore subagent)
+
+**Skip this entire step if screenshots already exist in `docs/ui-audit/images/`.**
+Go directly to Step 3.
+
+Spawn **one** subagent (explore/general-purpose type) with this task:
+
+> Scan the project codebase (components, pages, routes) and the rendered
+> app if needed, and produce a JSON list of every clickable element:
+> buttons, links styled as buttons, icon buttons, nav items, menu items.
+> For each, capture: `id` (short slug), `label` (visible text or
+> aria-label), `page_url` (route it appears on, relative to base URL),
+> `selector_hint` (text content, aria-label, or data-testid — whatever is
+> most reliable to click with Playwright), `source_file` (file:line if
+> found in code, else null).
+> Write the result to `docs/ui-audit/discovered_buttons.json` as a JSON array.
+
+Wait for this subagent to finish before proceeding. If it finds 0 buttons,
+stop and report that to the user rather than continuing.
+
+## Step 2 — Click + screenshot each button (sequential subagents)
+
+**Skip this entire step if screenshots already exist in `docs/ui-audit/images/`.**
+Go directly to Step 3.
+
+**Must run sequentially, one button at a time — never in parallel.** All
+buttons share the same browser session/page state via playwright-mcp;
+parallel subagents would race on the same browser and corrupt each
+other's state.
+
+For each entry in `docs/ui-audit/discovered_buttons.json`, in order, spawn a
+general-purpose subagent with this task (fill in the button's fields):
+
+> Using the playwright-mcp tool:
+> 1. Navigate to `{base_url}{page_url}`.
+> 2. Locate the element matching `{selector_hint}`.
+> 3. Click it.
+> 4. Wait briefly for the UI to settle (animations, network requests).
+> 5. Take a screenshot and save it as `docs/ui-audit/images/{id}.png`.
+> 6. Note in one sentence what happened after the click (navigated to new
+>    URL, opened modal, opened external link, no visible change, error).
+> 7. If the click navigated to a new page or opened an external site,
+>    that's fine — screenshot the resulting state as-is.
+> 8. Return a small JSON: `{id, screenshot_path, result_note, resulting_url}`.
+>
+> If the element can't be found or clicked, still record it with
+> `result_note: "click failed: <reason>"` and skip the screenshot — do
+> not stop the overall run.
+
+Append each result to `docs/ui-audit/discovered_buttons.json` (add the result
+fields to that button's entry) so progress is resumable.
+
+**Resumability**: before spawning a subagent for a given button, check if
+`docs/ui-audit/images/{id}.png` already exists — if so, skip it (already
+done). This lets the whole pipeline be safely re-run after an
+interruption.
+
+## Step 3 — Score each screenshot (sequential subagents)
+
+Read `references/checklist.md` once yourself (or pass its content into
+each subagent's prompt) — it defines the 8 scorable criteria and the
+scoring format.
+
+For each screenshot in `docs/ui-audit/images/`, sequentially spawn a
+general-purpose subagent with this task:
+
+> View the image at `{screenshot_path}`. Score it against the checklist
+> below. For each of the 8 criteria give `score` (0-10), `confidence`
+> (high/medium/low), `issues` (bullets), and `fix` (concrete suggestion,
+> referencing `{source_file}` if given). Compute `overall` as the average
+> of the 8 scores. Identify the single lowest-scoring criterion as
+> `top_issue`. Write the result as JSON to
+> `docs/ui-audit/reports/{id}.json` with shape:
+> `{id, label, page_url, overall, top_issue, criteria: [...]}`.
+>
+> [paste full checklist.md content here]
+
+Screenshots can be scored sequentially or in small batches — unlike Step
+2 there's no shared browser state, so this step can be parallelized if
+the environment supports it well. Default to sequential unless the user
+asks for speed and the environment handles parallel subagents reliably.
+
+## Step 4 — Aggregate final report
+
+After all `docs/ui-audit/reports/{id}.json` files exist, compile
+`docs/ui-audit/ui_audit_report.md` yourself (no subagent needed — this is
+simple aggregation):
+
+```markdown
+# UI Heuristic Audit Report
+
+Generated: {date}. {N} clickable elements audited.
+
+## Summary table
+| Button | Page | Overall | Top issue |
+|---|---|---|---|
+| ... | ... | 6.4 | Color Contrast |
+
+(sorted worst-to-best by overall score)
+
+## Buttons that failed to click
+- {id}: {result_note}
+
+## Detail per button
+### {label} ({page_url})
+![screenshot](images/{id}.png)
+Overall: {overall}/10
+
+| Criterion | Score | Confidence | Issue | Fix |
+|---|---|---|---|---|
+| Visual Hierarchy | 7 | high | ... | ... |
+| ... | | | | |
+
+---
+```
+
+Sort the summary table worst-to-best so the user sees the biggest
+problems first. Present the final report path to the user when done.
+
+## Notes
+
+- Out-of-scope heuristics (accessibility internals, form validation,
+  loading/empty states, multi-page consistency) are deliberately excluded
+  from scoring — see the note at the bottom of `references/checklist.md`.
+  Mention this limitation once in the final report, don't repeat it per
+  button.
+- Keep a TodoList tracking buttons through discover → screenshot → score
+  so long runs (dozens of buttons) don't lose track of progress.

package/sdd-frontend/skills/ui-heuristic-click-audit/references/checklist.md

@@ -0,0 +1,72 @@
+# UI Heuristic Checklist (static-screenshot audit)
+
+Core framing: for every criterion below, act like a UI/UX expert glancing
+at the screenshot — what would they notice first, what would bother them,
+what would they say should be different. Not a pixel-measuring tool, a
+trained eye's first-pass judgment. Each criterion is just one angle of
+that same expert glance.
+
+Only criteria that are reliably scorable from a single static screenshot are
+included. Interaction-dependent heuristics (keyboard nav, focus order,
+inline validation, offline state, alt text) are intentionally excluded —
+they require DOM/runtime inspection, not an image, and scoring them from a
+screenshot produces false confidence.
+
+For each criterion below, produce:
+- `score`: 0-10
+- `confidence`: high | medium | low
+- `issues`: short bullet list of concrete problems seen in this image
+- `fix`: concrete, actionable suggestion (component/CSS-level if possible)
+
+## 1. Visual Hierarchy
+Is there one clear primary focal point / primary CTA? Does the eye flow
+logically (top-left → primary action, typical F/Z pattern)? Penalize
+competing elements of equal visual weight.
+
+## 2. Typography
+≤3 font families. Clear size/weight distinction between heading and body.
+Line length and size look readable at normal viewing distance.
+
+## 3. Color Contrast
+Text-to-background contrast looks like it meets WCAG AA (~4.5:1 for body
+text, ~3:1 for large text/UI components). Status/state is not conveyed by
+color alone (icon/label/pattern also present).
+
+## 4. CTA Clarity
+Primary action button uses a clear action verb ("Save changes", not
+"Submit" or "OK" alone). No two CTAs of equal visual weight competing for
+the same decision. Primary vs secondary buttons are visually distinct.
+
+## 5. Layout
+No overflow, clipped text, overlapping elements, or broken grid.
+
+Is each component/menu/view placed where a UX expert would put it? Judge
+like a UX reviewer: "this should be here, not there" — nav in the
+conventional spot, controls near what they act on, nothing important
+buried or blocking something else. Fix = say where it should move to.
+
+## 6. Microcopy
+Visible text is short, scannable, task-focused. No jargon or ambiguous
+labels ("Continue" to what? "Yes" to what?).
+
+## 7. Visual/Asset Quality
+No broken images, pixelation, stretched/squished images, placeholder text
+left in production ("Lorem ipsum", "TODO").
+
+## 8. Above-the-Fold Priority
+In the initial visible viewport (before scroll), is the primary value
+proposition or primary CTA visible? Or is it buried below irrelevant
+content?
+
+---
+
+## Explicitly out of scope for this audit (do not score, mark N/A)
+Navigation flow correctness, form validation behavior, loading/empty/error
+states, keyboard accessibility, focus indicators, alt text, multi-page
+brand consistency (unless multiple screenshots of the same flow are
+supplied). Note in the report that these require a separate
+interaction-based or DOM-based audit.
+
+## Overall score per screenshot
+`overall = average of the 8 scores`, rounded to 1 decimal. Report
+alongside the lowest-scoring criterion as the "top issue".

package/sdd-frontend/skills/using-playwright-mcp/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: using-playwright-mcp
+description: Run browser automation through Playwright MCP for user-requested UI actions.
+disable-model-invocation: true
+---
+
+Uses Playwright MCP tools to perform any browser automation task the user requests. This is a general-purpose Playwright automation skill - execute whatever browser actions the user needs. Test writing is out of scope.

package/sdd-frontend/skills/verify-with-playwright-mcp/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: verify-with-playwright-mcp
+description: >
+  Verifies work done in the current context using Playwright MCP tools. Auto-fixes
+  visual issues found. Does not write tests. Trigger when user says
+  "verify-with-playwright-mcp".
+---
+
+Verifies work done in the current context using Playwright MCP tools. Navigate to the page, take screenshots, compare against expected design, and auto-fix any visual issues discovered (layout, alignment, contrast, responsiveness). Repeat the snapshot → compare → fix loop until the UI matches the plan. This skill does NOT write tests - visual verification only.
+
+When done, clean up screenshots:
+```bash
+git clean -f '*.png'
+```

package/sdd-utility/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "sdd-utilty",
+  "version": "1.0.1",
+  "description": "Utility skills for compressed communication and session knowledge handoff.",
+  "author": {
+    "name":"Onur ASLAN"
+  },
+  "license": "MIT",
+  "homepage": "https://github.com/onur-aslan/sdd"
+}

package/sdd-utility/skills/ask-first/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: ask-first
+description: Maintain shared understanding through explicit approval before every task and any plan change.
+disable-model-invocation: true
+---
+
+# AskFirst
+
+## Persistence
+
+AskFirst is a persistent session mode. Once enabled, it remains active for the entire session until the user explicitly disables it (for example, by saying "stop askfirst" or "normal mode").
+
+## While active
+
+Before touching any file or running any state-changing command:
+
+1. Briefly restate your understanding of the user's request.
+2. Explain exactly what you intend to do.
+3. Surface any assumptions, decisions, or open questions.
+4. Wait for explicit approval before proceeding.
+
+After approval, execute only the approved plan.
+
+If, at any point, you determine that the approved plan must change for any reason, stop immediately, explain what changed, restate your updated understanding and overall plan, and wait for explicit approval before continuing.
+
+Never perform work outside the last explicitly approved plan.
+
+## Goal
+
+Maintain a shared understanding with the user throughout the entire session. Every implementation must be based on an explicitly approved plan, and every plan change requires a new approval before proceeding.

package/sdd-utility/skills/buy-before-build/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: buy-before-build
+description: Prefer industry best practices and proven solutions before building custom ones.
+disable-model-invocation: true
+---
+
+# Buy Before Build
+
+Before implementing a non-trivial feature, determine the current industry best practice for solving the problem. If a proven solution already exists, prefer adopting it over building a custom implementation unless project constraints or requirements justify otherwise. Briefly explain your reasoning.
+
+**Principle:** Build differentiating product logic—not infrastructure that already exists.

package/sdd-utility/skills/code-slop-review/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: code-slop-review
+description: Review code quality across multiple layers and report issues clearly.
+disable-model-invocation: true
+---
+
+# Code Slop Review
+
+Code slop is code that compiles, passes tests, and quietly rots the codebase.
+It looks polished — consistent naming, green CI, clean PR description — while
+silently eroding architectural coherence.
+
+---
+
+## Step 1 — Select Scan Scope
+
+**Accepted argument formats — if the user provides any of these, use it directly:**
+```
+1  or  "full"                        → full codebase
+2  or  "diff"                        → git diff (uncommitted changes)
+3  or  "mr"  or  "pr"               → merge / pull request
+4  or  "commits"  or  "A..B"        → commit range
+A file path (e.g. src/auth.ts)      → single file scope
+A directory path (e.g. src/)        → single directory scope
+"fix"  or  "refactor"  or  "apply"  → skip to Fix Mode directly
+```
+
+**If no recognizable argument is given, ask exactly this before doing anything else:**
+
+> What should I scan?
+> 1. **Full codebase** — all source files in the project
+> 2. **Git diff** — uncommitted changes (staged + unstaged)
+> 3. **Merge / Pull Request** — changes introduced by a branch against its base
+> 4. **Commit range** — changes between two specific commits
+
+Wait for the user's answer. Do not start scanning until a scope is chosen.
+
+**After scope is determined, produce a scope descriptor** — a concise string
+that the explore agents will use to know what to scan. Examples:
+
+```
+scope: full codebase — all source files under ./src
+scope: git diff HEAD — uncommitted changes
+scope: MR diff — branch feature/auth → main (merge base: abc1234) — run: git diff abc1234..HEAD
+scope: commits a1b2c3..d4e5f6 — run: git diff a1b2c3..d4e5f6
+scope: single file — src/auth/login.ts
+scope: directory — src/payments/
+```
+
+---
+
+## Step 2 — Prepare Output Directory
+
+Create the output directory if it does not exist:
+
+```bash
+mkdir -p docs/sdd/code-slop
+```
+
+Determine which layers apply based on scope:
+
+| Layer | Full | Diff (2/3/4) | Single file | Single dir |
+|-------|------|--------------|-------------|------------|
+| 1 — Structural | ✓ | ✓ | ✓ | ✓ |
+| 2 — Tests | ✓ | ✓ | if test file found alongside source | ✓ |
+| 3 — Error Handling | ✓ | ✓ | ✓ | ✓ |
+| 4 — Architecture | ✓ | ✓ | ✗ | ✗ |
+| 5 — Dead Code | ✓ | ✓ | ✓ | ✓ |
+
+---
+
+## Step 3 — Run Analysis
+
+**For non-full-codebase scopes (diff, single file, directory):**
+
+Skip explore agents. Use a single Explore task to scan for all slop types at once.
+
+→ Read [references/agent-prompt.md](references/agent-prompt.md) and use the "For Non-Full-Codebase Scope" prompt.
+
+Replace `<scope descriptor>` with the actual scope from Step 1 and launch the task.
+
+Write output to: `docs/sdd/code-slop/diff-review.md`
+
+**For full codebase scope:**
+
+Spawn one explore agent per applicable layer. All agents run against the
+**same scope descriptor from Step 1**. Launch all applicable agents in parallel —
+do not wait for one to finish before starting the next.
+
+→ Read [references/agent-prompt.md](references/agent-prompt.md) to get the prompt template.
+
+For each applicable agent below, fill the template placeholders and launch:
+
+| Agent | Layer Name | `<layer-reference-file>` | `<output-filename>` | Skip if |
+|---|---|---|---|---|
+| 1 | Structural Slop | `structural-slop.md` | `layer-1-structural.md` | — |
+| 2 | Test Slop | `test-slop.md` | `layer-2-tests.md` | Layer 2 not applicable per Step 2. For single-file scope: check if a test file exists alongside the source before spawning. |
+| 3 | Error Handling Slop | `error-handling-slop.md` | `layer-3-error-handling.md` | — |
+| 4 | Architecture Slop | `architecture-slop.md` | `layer-4-architecture.md` | Layer 4 not applicable per Step 2 |
+| 5 | Dead Code Slop | `dead-code-slop.md` | `layer-5-dead-code.md` | — |
+
+Wait for all agents to complete before proceeding to Step 4.
+Step 4 starts after all Task tool calls have returned — not before.
+
+---
+
+## Step 4 — Aggregate and Produce Final Report
+
+**For non-full-codebase scopes:**
+Read `docs/sdd/code-slop/diff-review.md` and display the results to the user.
+Skip aggregation — the single agent already produced the final report.
+
+**For full codebase scope:**
+→ Read [references/aggregate-and-report.md](references/aggregate-and-report.md) and follow its steps.
+
+---
+
+## Fix Mode
+
+Triggered when the user says "fix", "refactor", or "apply" — either as an
+initial argument (Step 1) or after the report is produced.
+
+- If `docs/sdd/code-slop/report.md` exists (full codebase scan): read it and → Read [references/fix-mode.md](references/fix-mode.md).
+- If `docs/sdd/code-slop/diff-review.md` exists (diff/file/dir scan): read it and → Read [references/fix-mode.md](references/fix-mode.md).
+- If no report exists yet: run Steps 1–4 first to produce one, then enter Fix Mode.
+
+---
+
+## Out of Scope
+
+- Security vulnerability scanning — requires a dedicated audit
+- Performance profiling — requires benchmark tooling
+- Business logic correctness — requires domain knowledge
+- Syntax errors — handled by linters and compilers