@onuraslan/sdd 1.0.5

package/sdd/skills/spec-to-prd/references/mapping-guide.md

@@ -0,0 +1,95 @@
+# Spec to PRD Mapping Guide
+
+Maps `spec.md` design decisions to PRD sections.
+
+---
+
+## Mapping Table
+
+| spec.md Element | → | PRD Section | Notes |
+|-----------------|---|-------------|-------|
+| `# Feature: [Name]` | → | PRD Title | Use as `# PRD: [Feature Name]` |
+| `## Overview` | → | Section 1: Executive Summary | Condense to 2-3 sentences, remove jargon |
+| Design decisions (problem context) | → | Section 2: Problem Statement | Extract pain points and impact |
+| Design decisions (goals) | → | Section 3: Goals & Objectives | Convert to measurable outcomes |
+| Design decisions (functional) | → | Section 6: Functional Requirements | One FR per distinct capability |
+| Design decisions (technical) | → | Section 9: Technical Considerations | Translate to stakeholder-friendly language |
+| Design decision rationales | → | Throughout | Use as context for why requirements exist |
+| `## Visual Mock` | → | Section 8.1: Wireframes / Mockups | Copy or reference |
+| Trade-offs mentioned | → | Section 9.2: Technical Constraints | Document as constraints |
+| Constraints/Assumptions | → | Section 9.2: Technical Constraints | Or Section 3.2: Non-Goals if scope-related |
+
+---
+
+## Inference Rules
+
+When spec.md doesn't explicitly state something, infer from context:
+
+### Deriving User Stories
+```
+IF spec mentions "users need to X" or "allows Y"
+THEN create user story: "As a [relevant user], I want to [action], so that [benefit from rationale]"
+```
+
+### Extracting Acceptance Criteria
+```
+FOR EACH design decision rationale:
+  IF it mentions a condition or behavior
+  THEN convert to: "- [System] must [behavior]"
+```
+
+### Identifying Success Metrics
+```
+IF spec explicitly mentions a problem like "slow", "error-prone", "manual"
+THEN propose metric for Section 4:
+  - Baseline: current state (may need stakeholder input)
+  - Target: improved state
+  - Method: how to measure
+ELSE
+  Leave Section 4 as "TBD - requires stakeholder input"
+```
+
+### Prioritization (MoSCoW)
+```
+P0 (Must have): Core feature behavior without which feature doesn't work
+P1 (Should have): Important but feature still delivers value without it
+P2 (Could have): Nice to have, deferable to future iterations
+```
+
+---
+
+## spec.md Pattern Recognition
+
+### Decision Categories
+
+| Category Keywords | Map To |
+|-------------------|--------|
+| "UI", "frontend", "user sees", "display", "wireframe", "mockup" | Section 8.1: Wireframes / Mockups |
+| "content", "messaging", "copy", "tone", "localization" | Section 8.2: Content & Messaging |
+| "goal", "objective", "outcome" | Section 3: Goals |
+| "metric", "measure", "baseline", "target" | Section 4: Success Metrics |
+| "user", "story", "as a" | Section 5: User Stories |
+| "must", "required", "need" | Section 6: Functional Requirements |
+| "performance", "latency", "throughput" | Section 7.1: Performance |
+| "auth", "permission", "access" | Section 7.2: Security |
+| "reliability", "availability", "uptime", "recovery" | Section 7.3: Reliability & Availability |
+| "scale", "load", "concurrent" | Section 7.4: Scalability |
+| "WCAG", "a11y", "screen reader" | Section 7.5: Accessibility |
+| "API", "integration", "external" | Section 9.1: Integration Points |
+| "constraint", "limitation", "trade-off" | Section 9.2: Technical Constraints |
+
+---
+
+## Gap Detection
+
+Report these gaps to the user:
+
+| Missing from spec.md | PRD Section Affected | Action |
+|----------------------|---------------------|--------|
+| No problem context | Section 2 | Mark "TBD - add problem statement to spec.md" |
+| No goals/outcomes | Section 3 | Mark "TBD - define success metrics" |
+| No success metrics/KPIs in spec | Section 4 | Mark "TBD - requires stakeholder input" (do NOT fabricate) |
+| Only technical decisions | Section 5, 6 | Infer from capabilities, flag for review |
+| No constraints | Section 9.2 | Leave blank with "None identified" |
+
+---

package/sdd/skills/spec-to-prd/references/prd-format.md

@@ -0,0 +1,122 @@
+# PRD Template
+
+Generate the following file at `docs/sdd/features/<feature-name>/prd.md`:
+
+```markdown
+# PRD: [Feature Name]
+
+| Metadata | Value |
+|----------|-------|
+| Status | Draft / In Review / Approved |
+| Version | 1.0 |
+| Created | YYYY-MM-DD |
+| Owner | [Product Owner / Team] |
+
+---
+
+## 1. Executive Summary
+
+[2-3 sentences summarizing what this feature does and why it matters. Written for executives/stakeholders who won't read the full document.]
+
+---
+
+## 2. Problem Statement
+
+[What user problem or business need does this feature address? Include current pain points and impact.]
+
+### 2.1 Current State
+[Describe the current situation without this feature]
+
+### 2.2 Desired State
+[Describe the desired situation after this feature is delivered]
+
+---
+
+## 3. Goals & Objectives
+
+### 3.1 Primary Goals
+- [Goal 1: Measurable outcome]
+- [Goal 2: Measurable outcome]
+
+### 3.2 Non-Goals
+[What this feature explicitly does NOT do - important for scope management]
+
+---
+
+## 4. Success Metrics
+
+[How will you measure if this feature is successful? Include baseline, target, and time horizon.]
+
+| Metric | Baseline | Target | Time Horizon | Measurement Method |
+|--------|----------|--------|--------------|-------------------|
+| [Metric name] | [Current value] | [Target value] | [Timeframe] | [How you'll measure] |
+
+---
+
+## 5. User Stories
+
+| ID | User Story | Acceptance Criteria | Priority |
+|----|------------|---------------------|----------|
+| US-01 | As a [user], I want to [action], so that [benefit] | - [Criterion 1]<br>- [Criterion 2] | Must have / Should have / Could have |
+| US-02 | As a [user], I want to [action], so that [benefit] | - [Criterion 1]<br>- [Criterion 2] | Must have / Should have / Could have |
+
+---
+
+## 6. Functional Requirements
+
+| ID | Requirement | Description | Priority | Dependencies |
+|----|-------------|-------------|----------|--------------|
+| FR-01 | [Title] | [What the system must do] | P0 / P1 / P2 | [Related FR IDs or external deps] |
+| FR-02 | [Title] | [What the system must do] | P0 / P1 / P2 | [Related FR IDs or external deps] |
+
+---
+
+## 7. Non-Functional Requirements
+
+### 7.1 Performance
+- [Response time, throughput, latency requirements]
+
+### 7.2 Security
+- [Authentication, authorization, data protection requirements]
+
+### 7.3 Reliability & Availability
+- [Uptime, error rate, recovery requirements]
+
+### 7.4 Scalability
+- [User load, data volume growth expectations]
+
+### 7.5 Accessibility
+- [WCAG compliance level, assistive technology support]
+
+---
+
+## 8. User Experience & Design
+
+### 8.1 Wireframes / Mockups
+[Link to or embed visual designs, or describe key UI states]
+
+### 8.2 Content & Messaging
+[Key copy, tone, localization requirements]
+
+---
+
+## 9. Technical Considerations
+
+[High-level technical approach translated from spec.md design decisions - written for technical stakeholders, not implementation detail]
+
+### 9.1 Integration Points
+[External APIs, services, or systems this feature touches]
+
+### 9.2 Technical Constraints
+[Hard constraints from the spec that affect product decisions]
+
+---
+
+## 10. Open Questions
+
+| ID | Question | Context | Decision Needed By | Owner |
+|----|----------|---------|-------------------|-------|
+| Q-01 | [Unresolved question] | [Why it matters] | [Date/milestone] | [Role] |
+```
+
+---

package/sdd/skills/workflow-generator/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: workflow-generator
+description: Asks the user what they want to do, determines the correct workflow, and writes it to docs/workflow.md. Use as the entry point for all SDD workflows.
+disable-model-invocation: true
+---
+
+You are a workflow generator assistant. Your job is to ask the user what they want to do, determine the correct workflow, and write it to `docs/workflow.md`.
+
+## Step 1: Determine Workflow Type
+
+Ask the user to choose one of the following:
+```
+**A) Feature Development** — Implementing a new feature from scratch or from a spec
+
+**B) Bug Fix** — Fixing a confirmed bug in existing code
+
+**C) Enhancement** — Improving or refining an existing feature (UI/UX, performance, usability)
+
+**D) I'm not sure — help me decide** — Let the assistant analyze and recommend the best fit
+```
+If the user chooses **D**, ask clarifying questions to determine the right workflow:
+- Is this something entirely new that didn't exist before? → Feature Development
+- Is something broken that should work? → Bug Fix
+- Is something working but could be better? → Enhancement
+
+## Step 2: Detect Project Scope
+
+	auto-detect the project type by looking at the codebase.
+
+If auto-detection is inconclusive or the project is full-stack, ask the user:
+
+```
+Is this **Backend**, **Frontend**, or **Both**?
+```
+
+## Step 3: Write docs/workflow.md
+
+Write the selected workflow to `docs/workflow.md`. Copy the appropriate reference template below into `docs/workflow.md`.
+
+**Feature Development:**
+- Backend → [reference/workflow-feature-development-backend.md](reference/workflow-feature-development-backend.md)
+- Frontend → [reference/workflow-feature-frontend-development.md](reference/workflow-feature-frontend-development.md)
+
+**Bug Fix:**
+- Backend → [reference/workflow-bug-fix-backend.md](reference/workflow-bug-fix-backend.md)
+- Frontend → [reference/workflow-bug-fix-frontend.md](reference/workflow-bug-fix-frontend.md)
+
+**Enhancement:**
+- Backend → [reference/workflow-enhancement-backend.md](reference/workflow-enhancement-backend.md)
+- Frontend → [reference/workflow-enhancement-frontend.md](reference/workflow-enhancement-frontend.md)
+
+## Step 4: Confirm and Next Steps
+
+After writing the file, report to the user:
+- Which workflow was written
+- Where it was saved (`docs/workflow.md`)
+- How many steps/skills are in the workflow
+- Reminder to follow the steps in order, running each skill sequentially
+
+Next step: `/docs/workflow.md` — user should follow the steps in the written workflow file.

package/sdd/skills/workflow-generator/reference/workflow-bug-fix-backend.md

@@ -0,0 +1,35 @@
+# Workflow: Bug Fix (Backend)
+
+> Generated by workflow-gateway
+
+## Steps
+
+```
+/clear
+/sdd:bug-fix-backend `<bug fix definition>`
+```
+
+→ **Human review** — Check fix, approve
+
+(optional) Verify:
+```
+/sdd:verify-with-curl
+```
+
+→ **Human review** — Approve verification
+
+## optional (at the end)
+
+Gap analysis:
+```
+/sdd-utilty:gap-analysis
+```
+
+→ **Human review** — Review gaps, approve fixes
+
+Code slop review:
+```
+/sdd-utilty:code-slop-review
+```
+
+→ **Human review** — Review findings, decide what to fix

package/sdd/skills/workflow-generator/reference/workflow-bug-fix-frontend.md

@@ -0,0 +1,34 @@
+# Workflow: Bug Fix (Frontend)
+
+> Generated by workflow-gateway
+
+## Steps
+
+```
+/clear
+/sdd:bug-fix-frontend `<bug fix definition>`
+```
+
+→ **Human review** — Check fix, approve
+
+```
+/sdd:verify-with-playwright-mcp
+```
+
+→ **Human review** — Approve verification
+
+## optional (at the end)
+
+Gap analysis:
+```
+/sdd-utilty:gap-analysis
+```
+
+→ **Human review** — Review gaps, approve fixes
+
+Code slop review:
+```
+/sdd-utilty:code-slop-review
+```
+
+→ **Human review** — Review findings, decide what to fix

package/sdd/skills/workflow-generator/reference/workflow-enhancement-backend.md

@@ -0,0 +1,35 @@
+# Workflow: Enhancement (Backend)
+
+> Generated by workflow-gateway
+
+## Steps
+
+```
+/clear
+/sdd:enhancement-backend `<enhancement definition>`
+```
+
+→ **Human review** — Check plan, approve implementation
+
+(optional) Verify:
+```
+/sdd:verify-with-curl
+```
+
+→ **Human review** — Approve verification
+
+## optional (at the end)
+
+Gap analysis:
+```
+/sdd-utilty:gap-analysis
+```
+
+→ **Human review** — Review gaps, approve fixes
+
+Code slop review:
+```
+/sdd-utilty:code-slop-review
+```
+
+→ **Human review** — Review findings, decide what to fix

package/sdd/skills/workflow-generator/reference/workflow-enhancement-frontend.md

@@ -0,0 +1,34 @@
+# Workflow: Enhancement (Frontend)
+
+> Generated by workflow-gateway
+
+## Steps
+
+```
+/clear
+/sdd:enhancement-frontend `<enhancement definition>`
+```
+
+→ **Human review** — Check plan, approve implementation
+
+```
+/sdd:verify-with-playwright-mcp
+```
+
+→ **Human review** — Approve verification
+
+## optional (at the end)
+
+Gap analysis:
+```
+/sdd-utilty:gap-analysis
+```
+
+→ **Human review** — Review gaps, approve fixes
+
+Code slop review:
+```
+/sdd-utilty:code-slop-review
+```
+
+→ **Human review** — Review findings, decide what to fix

package/sdd/skills/workflow-generator/reference/workflow-feature-development-backend.md

@@ -0,0 +1,105 @@
+# Workflow: Feature Development (Backend)
+
+> Generated by workflow-gateway
+
+## Steps
+
+```
+/clear
+/sdd:deep-spec @<what you want>
+/sdd:spec-to-prd
+```
+
+→ **Human review** — Check spec, handle open questions, approve PRD
+
+→ Check PRD size: [small PRD](#small-prd) | [large PRD](#large-prd)
+
+## small scope
+
+```
+/clear
+/implementer @<prd-path>
+```
+
+(optional) Verify:
+```
+/sdd:verify-with-curl
+```
+
+→ **Human review** — Approve API verification
+
+## large PRD
+
+```
+/sdd:prd-to-task @<prd-path>
+```
+
+→ **Human review** — Check task breakdown in feature.md
+
+For each task in `feature.md` (respect dependency order, in sequence):
+
+### Task 1
+
+```
+/clear
+/sdd:chicago-tdd @<task-path>
+```
+
+→ **Human review** — Verify task implementation
+
+(optional) Verify:
+```
+/sdd:verify-with-curl
+```
+
+→ **Human review** — Approve verification
+
+### Task 2
+
+```
+/clear
+/sdd:chicago-tdd @<task-path>
+```
+
+→ **Human review** — Verify task implementation
+
+(optional) Verify:
+```
+/sdd:verify-with-curl
+```
+
+→ **Human review** — Approve verification
+
+## verify all (at the end)
+
+```
+/clear
+/sdd:feature-e2e-verifier @<prd-path>
+```
+
+→ **Human review** — Approve E2E verification
+
+(optional)
+
+## optional (all at the end)
+
+PRD test writer (for acceptance tests):
+```
+/sdd:prd-test-writer @<prd-path>
+```
+
+→ **Human review** — Approve acceptance tests
+
+Gap analysis:
+```
+/sdd-utilty:gap-analysis
+```
+
+→ **Human review** — Review gaps, approve fixes
+
+Code slop review:
+```
+/sdd-utilty:code-slop-review
+```
+
+→ **Human review** — Review findings, decide what to fix

package/sdd/skills/workflow-generator/reference/workflow-feature-frontend-development.md

@@ -0,0 +1,78 @@
+# Workflow: Feature Frontend Development
+
+> Generated by workflow-gateway
+
+## Steps
+
+```
+/clear
+/sdd:deep-spec @<what you want>
+/sdd:spec-to-prd
+```
+
+→ **Human review** — Check spec, handle open questions, approve PRD
+
+→ Check PRD size: [small PRD](#small-prd) | [large PRD](#large-prd)
+
+## small scope
+
+```
+/clear
+/implementer @<prd-path>
+```
+
+(optional) Verify:
+```
+/sdd:verify-with-playwright-mcp
+```
+
+→ **Human review** — Verify implementation and verification
+
+## large PRD
+
+```
+/sdd:prd-to-task @<prd-path>
+```
+
+→ **Human review** — Check task breakdown in feature.md
+
+```
+/clear
+/sdd:feature-implementer @<feature-path>
+```
+
+→ **Human review** — Verify implementation
+
+## verify all (at the end)
+
+```
+/clear
+/sdd:feature-e2e-verifier @<prd-path>
+```
+
+→ **Human review** — Approve E2E verification
+
+(optional)
+
+## optional (all at the end)
+
+PRD test writer (for acceptance tests):
+```
+/sdd:prd-test-writer @<prd-path>
+```
+
+→ **Human review** — Approve acceptance tests
+
+Gap analysis:
+```
+/sdd-utilty:gap-analysis
+```
+
+→ **Human review** — Review gaps, approve fixes
+
+Code slop review:
+```
+/sdd-utilty:code-slop-review
+```
+
+→ **Human review** — Review findings, decide what to fix

package/sdd-backend/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "sdd-backend",
+  "version": "1.0.1",
+  "description": "Backend development skills for API, database, and server-side logic with unit testing.",
+  "author": {
+    "name":"Onur ASLAN"
+  },
+  "license": "MIT",
+  "homepage": "https://github.com/onur-aslan/sdd"
+}

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

@@ -0,0 +1,54 @@
+---
+name: backend-enhancement
+description: Guide backend feature enhancement through interview and implementation steps.
+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`
+
+Follow this process for each enhancement:
+
+1. **Write failing test** - Write a **unit test** that exercises the new or changed code path:
+   - Test should exercise the real code path being enhanced
+   - Mock only external boundaries (database, external APIs, file system)
+   - No internal mocks - test through the real service/controller layer
+   - Verify the test FAILS before proceeding
+
+2. **Fix** - Implement the minimal possible fix to make the test pass
+
+Ensure the build passes without errors after completing the changes.
+
+After completing the changes, invoke the `verify-with-curl` skill to validate and auto-fix any issues.

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

@@ -0,0 +1,21 @@
+---
+name: bug-fix-backend
+description: Fix backend bugs by reproducing them with a failing test and the smallest fix.
+disable-model-invocation: true
+---
+You are a senior backend engineer. Your only job is to fix bugs — nothing else. When given a bug, write a failing unit test first, then apply the smallest possible fix.
+
+**Workflow:**
+1. **Write failing test** - Write a **unit test** that reproduces the bug:
+   - Test should exercise the real code path that is buggy
+   - Mock only external boundaries (database, external APIs, file system)
+   - No internal mocks - test through the real service/controller layer
+   - Verify the test FAILS before proceeding
+2. **Analyze and propose solutions** - Analyze the root cause and identify possible fix approaches:
+   - Present 2-3 viable solution options to the user
+   - For each option, explain: trade-offs, risks, effort, and long-term implications
+   - Wait for user to select which solution to implement
+3. **Fix** - Implement the user-selected solution as the smallest possible fix to make the test pass
+
+**Important:**
+- Always write a failing unit test first - do not skip this step

package/sdd-backend/skills/verify-with-curl/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: verify-with-curl
+description: >
+  Verifies work done in the current context using curl. Auto-fixes issues found.
+  Does not write tests. Trigger when user says "verify-with-curl".
+---
+
+Verifies work done in the current context using curl commands. Test API endpoints, inspect responses, validate status codes, headers, and response bodies. Auto-fix any issues discovered. Restart the app at the start of each iteration, then repeat the curl → compare → fix loop until the API matches the expected behavior. This skill does NOT write tests - manual verification only.