@onuraslan/sdd 1.0.5

package/sdd/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "sdd",
+  "version": "1.0.2",
+  "description": "Automated workflows for feature development and bug fixing using plan-driven development. Spec-Driven Development (SDD) from planning to Jira export. Modular plugin structure with sdd-frontend, sdd-init, and sdd-utilty sub-plugins.",
+  "author": {
+    "name":"Onur ASLAN"
+  },
+  "license": "MIT",
+  "homepage": "https://github.com/onur-aslan/sdd"
+}

package/sdd/skills/chicago-tdd/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: chicago-tdd
+description: Apply Chicago School TDD with a strict red-green cycle.
+disable-model-invocation: true
+---
+You are an expert software engineer who strictly adheres to the Chicago School of TDD (Classic TDD). Your mission is to apply Classic TDD to the Scenarios of a given task using a strict Red-Green cycle. Mock only external boundaries. No internal mocks. All codes must be written with best practices. Follow the workflow below and do not skip any step. 
+
+# IRON LAWS
+- **Test before implementation - never write code without a failing test**
+- **One test at a time.**
+- **Test behavior, not internal implementation details.**
+
+# WORKFLOW
+
+## Step 1: Happy Path
+- Write test for ONLY happy path scenario one at a time.
+- Run RED: Verify the happy path test fails at runtime (no compile errors).
+- Run GREEN: Write minimal code to make the happy path test pass.
+
+## Step 2: Edge Cases
+- Write tests for ALL remaining edge case scenarios one at a time
+- Run RED: Verify all edge case tests fail at runtime (no compile errors).
+- Run GREEN: Write minimal code to make ALL edge case tests pass
+
+## Step 3: Done
+- Update the task's Status in `feature.md` to Done

package/sdd/skills/deep-spec/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: deep-spec
+description: Conducts an interview-driven design session using a multi-level zoom approach (L5:Domain to L1:Line), producing a structured spec.md under docs/sdd/features/. Use when user mentions "deep-spec", "spec-designer", or wants to design a new feature through guided questioning.
+disable-model-invocation: true
+---
+
+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. Do not implement, write code, or modify source files — this skill only creates the spec.
+
+## Zoom & Tour Integration
+
+**Zoom Levels:** L5:Domain → L4:System → L3:Component → L2:Function → L1:Line
+
+**Tour Tracking:**
+- Track `currentZoom` L{M}: {LevelName} (starts with optimal zoom level)
+- Track `currentTour` number as {N} (starts at 1)
+- Track `tourQuestions` count per tour
+- Announce: `🎯 Tour {N} (L{M}: {LevelName}) — Question {K}`
+
+After each design decision within a tour, continue questioning. Track current zoom level and announce it.
+## Steps
+
+**Step 1.** Announce: `🎯 Starting Tour {N} at L{M}: {LevelName}...`
+Explore the codebase at current zoom level — only once per tour.
+
+**Step 2.** Deep Think about next design question at current zoom level.
+Announce: `🎯 Tour {N} (L{M}: {LevelName}) — Question {K}`
+
+**Step 3.** Ask one design question with options, ASCII mock, and recommendation.
+
+Format:
+```
+[Question text]?
+
+A) [Option A title]
+   [ASCII mock for A]
+
+B) [Option B title]
+   [ASCII mock for B]
+
+C) [Option C title]
+   [ASCII mock for C]
+
+✅ Recommended: [A/B/C] — [one-line reason]
+```
+
+**Step 4.** After user answers, keep the decision in context (do not write to file yet).
+- If there are more design questions at this zoom level → Go To Step 2
+- If no more meaningful questions at this level → Proceed to Step 5 (End of Tour)
+
+**Step 5. End of Tour.** Announce current tour and zoom level. Ask:
+
+```
+🎯 Tour {N} complete at L{M}: {LevelName}.
+
+A) Zoom deeper — start Tour {N+1} at L{M-1} (implementation details)
+B) Done — finalize spec
+
+✅ Recommended: [A/B] — [one-line reason based on plan complexity]
+```
+
+**If user selects A (Zoom deeper):** Announce `🎯 Starting Tour {N+1} at L{M-1}...`, keep `askedQuestions` intact (do not reset), and Go To Step 2. Probe only new, deeper questions that have not been asked before — never re-ask a question from an earlier tour.
+
+**If user selects B (Done):** Read [spec-format.md](spec-format.md) and write `docs/sdd/features/<feature-name>/spec.md` directly with the collected decisions.
+
+---
+
+## Next Step
+
+**→ `/spec-to-prd`**

package/sdd/skills/deep-spec/spec-format.md

@@ -0,0 +1,32 @@
+# Spec Format
+
+Write the following file at `docs/sdd/features/<feature-name>/spec.md`.
+
+Use the collected design decisions from all tours to fill it in. Nothing else.
+
+```markdown
+# Feature: [Feature Name]
+
+## Overview
+[One-paragraph summary of what this feature does, derived from the user's initial request and tour context.]
+
+## Design Decisions
+
+### [Category]
+
+**Decision:** [What was chosen]
+
+**Decision:** [What was chosen]
+
+## Visual Mock
+[If there are any visual/UI decisions, include visual mockups, wireframes, or layout descriptions here. If none, omit this section.]
+```
+
+## Rules
+
+- Group decisions by logical category (UI, data, architecture, integration, etc.)
+- Capture final decision and key reasoning if multiple rounds of discussion
+- Include constraints and assumptions discovered during questioning
+- Do NOT include any code
+- Do NOT invent new decisions — only what was explicitly captured during tours
+- Do NOT include task lists, vertical slices, priorities, or implementation plans — this file is decisions only

package/sdd/skills/feature-implementer/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: feature-implementer
+description: Orchestrates feature implementation by sequentially delegating tasks to task-implementer agent based on feature.md task order.
+disable-model-invocation: true
+---
+You are an orchestrator agent that implements features by sequentially delegating tasks to the task-implementer agent. Your role is to read a feature.md file, identify pending tasks, and invoke task-implementer for each task in the correct order.
+
+# Workflow
+
+## Step 1: Find Next Pending Task
+
+From the Task Order table, find the **first** task that meets these criteria:
+1. Status is `Todo` or `Pending`
+2. All tasks it depends on have status `Done`
+
+If no tasks are pending (all are `Done`), the feature implementation is complete. Report this to the user and stop.
+
+Wait for user confirmation.
+
+## Step 2: Invoke Task-Implementer
+
+Spawn a fresh `general_purpose` subagent with prompt [reference/task-implementer.md](reference/task-implementer.md).
+
+Wait for task-implementer to complete.
+
+## Step 3: Verify and Continue
+
+After task-implementer completes:
+1. Update the task status to `Done` in feature.md
+2. Check build and logs for any errors
+
+If successful, return to **Step 2** to find the next pending task.
+
+If failed, report the issue to the user and wait for guidance.
+
+# Principles
+
+- **Sequential execution**: Only one task at a time, respecting dependencies
+- **No parallel tasks**: Wait for each task to complete before starting the next
+- **Dependency-aware**: Never start a task before its dependencies are done
+- **Minimal orchestration**: Delegate implementation to task-implementer, don't implement yourself
+
+# Input
+- Feature file: `docs/sdd/features/<feature>/feature.md`
+
+# Output
+- Updated feature.md with completed tasks
+- Implemented code for each task

package/sdd/skills/feature-implementer/reference/task-implementer.md

@@ -0,0 +1,5 @@
+Task tool (general-purpose):
+description: "Implement Task N: [task name]"
+
+prompt:
+Implement the task at `docs/sdd/features/<feature>/tasks/<task-name>.md`. Read the task definition, extract the Implementation Steps, and create a ToDoWrite task list with a parent task and child tasks for each step. Implement each step sequentially, running build/compile after each to verify and fix errors. Finally, perform a gap analysis comparing the implementation against the task requirements and acceptance criteria.

package/sdd/skills/implementer/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: implementer
+description: Implement the current context into code and verify it builds cleanly.
+disable-model-invocation: true
+---
+
+Implement whatever has been defined in the current context by writing/modifying code. Run build/compile to verify no errors. Fix any build errors. Then perform a gap analysis comparing what was implemented against the original requirements.
+
+## Out of scope
+
+- Writing tests

package/sdd/skills/prd-test-writer/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: prd-test-writer
+description: Orchestrates test writing for each User Story's Acceptance Criteria (AC) in a PRD. Uses general-purpose Task Tool in parallel for each US. Orchestrator writes all reports from agent output.
+disable-model-invocation: true
+---
+
+# PRD Test Writer
+
+Announce at start: "prd-test-writer: Analyzing PRD for User Stories and Acceptance Criteria..."
+
+---
+
+## Workflow
+
+### Step 1. Read PRD and Extract User Stories
+
+Read `docs/sdd/features/<feature-name>/prd.md` and extract:
+- All User Stories from the User Stories table (Section 5)
+- For each User Story: ID (US-01, US-02, etc.), description, and Acceptance Criteria list
+
+**Validation:** If no User Stories found, exit with: "No User Stories found in PRD"
+
+### Step 2. Spawn Task Tools in Parallel
+
+For each User Story that needs tests, use the Task tool with `subagent_type=general-purpose`.
+
+Read the template at [references/user-story-test-writer-prompt.md](references/user-story-test-writer-prompt.md) and replace placeholders:
+
+| Placeholder | Value |
+|---|---|
+| `<us-id>` | e.g. US-01 |
+| `<us-description>` | Full User Story text |
+| `<ac-list>` | Bulleted Acceptance Criteria (one per line, each prefixed with `- `) |
+
+**Announce:** "Launching <N> test-writer tasks in parallel..."
+
+### Step 3. Wait for All Tasks to Complete
+
+Wait for all parallel test-writer tasks to finish.
+
+### Step 4. Aggregate Results
+
+Collect results from all test-writer tasks:
+- ✅ Passed: User Stories with tests written successfully
+- ❌ Failed: User Stories where test writing failed
+
+For each successful task, extract from the agent output:
+- Test file path created (must start with `US_` prefix, e.g., `US_01-*.test.ts`)
+- Test count
+- AC coverage details
+
+### Step 5. Generate Feature Test Report
+
+Write `docs/sdd/features/<feature-name>/test-report.md`:
+
+```markdown
+# Feature Test Report: <feature-name>
+
+| Metadata | Value |
+|----------|-------|
+| Feature | <feature-name> |
+| PRD | docs/sdd/features/<feature-name>/prd.md |
+| Total User Stories | <N> |
+| Tests Written | <N> |
+
+## User Story Results
+
+| US-ID | Description | Test File | Status | Test Count |
+|-------|-------------|-----------|--------|------------|
+| US-01 | ... | US_01-*.test.ts | ✅ | 5 |
+| US-02 | ... | US_02-*.test.ts | ✅ | 3 |
+```
+
+### Step 6. Finish
+
+Announce completion with summary: feature name, user stories processed, tests written, and report location.
+
+---
+
+## Principles
+
+- **Parallel Execution**: All test-writer tasks run in parallel for speed
+- **AC-Driven**: Tests are derived from Acceptance Criteria only
+- **No Source Modifications**: This skill only writes tests, never modifies production code
+- **Orchestrator Writes Reports**: Test-writer agents return results directly; the orchestrator writes all reports
+- **Aggregated Report**: One feature-level report summarizes all results

package/sdd/skills/prd-test-writer/references/user-story-test-writer-prompt.md

@@ -0,0 +1,12 @@
+Task tool (general-purpose):
+description: "Write unit tests for <us-id>"
+
+prompt:
+Write unit tests for the following User Story by analyzing the source code and following existing test patterns in the codebase. Write tests for EACH Acceptance Criterion, including happy path, edge cases, and error handling. Tests must be derived from Acceptance Criteria only — do not invent requirements. Each test should be isolated and deterministic. Prefer mocking external dependencies (APIs, databases) unless integration tests are requested. Use the existing test framework (Jest, Vitest, pytest, etc.). Do NOT modify any source code — only write tests.
+
+**Naming Convention:** Test files MUST start with `US_` prefix followed by the US ID (e.g., `US_01-*.test.ts`, `US_02-*.test.ts`) to indicate they were generated by prd-test-writer.
+
+## Input
+<us-description>
+
+<ac-list>

package/sdd/skills/prd-to-task/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: prd-to-task
+description: Convert a PRD into an ordered task list with explicit implementation steps.
+disable-model-invocation: true
+---
+This skill processes workflow step by step. Each step must be done as if Steps are prompted by user then user see result and then prompt next step. You are like an orchestrator for user prompt. **Wait user confirmation at the end of each step**.
+
+Gherkin Scenario outcomes (`Then` `And` blocks) must be **implementation-agnostic** and testable at the service/use-case boundary. Scenarios will serve as **integration test specifications** — structured for automated test generation. Avoid flakky test scenarios.
+
+# Workflow
+
+## Step 1. External Interface Analysis
+
+Analyze the PRD to identify which external interfaces this feature uses.
+
+1. **Identify Layers:** List all architectural layers this feature touches
+2. **Identify Bottom-External-Interface:** Determine the lowest external interface
+3. **Define Vertical-Slice Tasks:** Each vertical slice = one top interface component → one bottom-external-interface flow
+4. **Generate ASCII Mock:** Create ASCII diagrams showing how vertical slices cut through layers
+   - First show the Layer Overview Diagram (all layers + components)
+   - Then show one Vertical Slice Detail Diagram per slice
+   - Follow format in [reference/ascii-mock-format.md](reference/ascii-mock-format.md)
+
+**Wait for user confirmation.**
+
+## Step 2. Define Happy-Path Scenario
+
+Define only one end-to-end happy-path scenario for each [vertical-slice] task.
+
+**Wait for user confirmation.**
+
+## Step 3. Define Edge-Case Scenarios
+
+Define only critical end-to-end scenarios other than the [happy-path-scenario] for each [vertical-slice]
+
+**Wait for user confirmation.**
+
+## Step 4. Define Task Dependencies
+
+Map dependencies between [vertical-slice] tasks exclude [enabler] and [cross-cutting] Tasks since they are merged into [vertical-slice] tasks. Determine execution order. Generate an ASCII dependency graph.
+
+**Wait for user confirmation.**
+
+# Input
+- prd.md
+# Output
+- Write feature.md file strictly following [reference/feature-template.md](reference/feature-template.md) format.
+- Write ONLY [vertical-slice] tasks strictly following [reference/task-template.md](reference/task-template.md) format. Do not write [enabler] and [cross-cutting] tasks.
+
+# Out Of Scope
+- Test outcomes which can be verified by UI tests

package/sdd/skills/prd-to-task/reference/ascii-mock-format.md

@@ -0,0 +1,67 @@
+# ASCII Mock Format for Vertical Slices
+
+## Layer Overview Diagram
+
+Show all layers and their components at a glance:
+
+```
+                    LAYER DIAGRAM
+┌────────────────────────────────────────────┐
+│  PRESENTATION                              │
+│  ┌────────┐  ┌────────┐  ┌────────┐       │
+│  │ Screen │  │ Widget │  │ Dialog │       │
+│  └───┬────┘  └───┬────┘  └───┬────┘       │
+├──────┼──────────┼──────────┼──────────────┤
+│  DOMAIN         │          │              │
+│  ┌───┴────┐  ┌──┴───┐  ┌──┴─────┐        │
+│  │UseCase │  │Service│ │Manager │        │
+│  └───┬────┘  └──┬───┘  └──┬─────┘        │
+├──────┼──────────┼──────────┼──────────────┤
+│  DATA           │          │              │
+│  ┌───┴────┐  ┌──┴───┐  ┌──┴─────┐        │
+│  │ Repo   │  │Gateway│ │ Store  │        │
+│  └───┬────┘  └──┬───┘  └──┬─────┘        │
+├──────┼──────────┼──────────┼──────────────┤
+│  EXTERNAL       ▼          ▼              │
+│  ┌────────┐  ┌────────┐  ┌────────┐       │
+│  │REST API│  │ gRPC   │  │ Queue  │       │
+│  └────────┘  └────────┘  └────────┘       │
+└────────────────────────────────────────────┘
+```
+
+## Vertical Slice Detail Diagram
+
+Create one diagram per vertical slice, showing how it cuts through all layers:
+
+```
+         VERTICAL SLICE 1: Read User Profile
+         ────────────────────────────────────
+         
+         ┌──────────────┐
+         │   Screen     │  ◄── ENTRY: User opens profile page
+         └──────┬───────┘
+                │
+                ▼  ════════════════════════════
+         ┌──────────────┐
+         │  UseCase     │  ◄── Business logic: GetUserProfile
+         └──────┬───────┘
+                │
+                ▼  ════════════════════════════
+         ┌──────────────┐
+         │  Repository  │  ◄── Data access layer
+         └──────┬───────┘
+                │
+                ▼  ════════════════════════════
+         ┌──────────────┐
+         │  REST API    │  ◄── EXIT: GET /api/users/:id
+         └──────────────┘
+```
+
+## Rules
+
+- Show each vertical slice as a separate diagram
+- Use `▼` for flow direction
+- Use `═══` marks to highlight the slice path through layers
+- Label ENTRY (top) and EXIT (bottom) points clearly
+- Include a one-line description at each layer (what happens at that step)
+- Include a brief description of what the slice validates (in the title)

package/sdd/skills/prd-to-task/reference/feature-template.md

@@ -0,0 +1,20 @@
+# Feature Format
+## Location
+Path: `docs/sdd/features/<feature-name>/feature.md`
+
+## Structure
+```markdown
+# Execution Plan
+
+## Task Order
+
+| # | Task | File | Status | Depends On |
+|---|------|------|--------|------------|
+| 1 | [Task name] | [task1_{task-name}.md](tasks/task1_{task-name}.md) | Pending | — |
+| 2 | [Task name] | [task2_{task-name}.md](tasks/task2_{task-name}.md) | Pending | Task 1 |
+| 3 | [Task name] | [task3_{task-name}.md](tasks/task3_{task-name}.md) | Pending | Task 1 |
+| 4 | [Task name] | [task4_{task-name}.md](tasks/task4_{task-name}.md) | Pending | Task 2, Task 3 |
+
+## Notes
+[Sequencing decisions that are not obvious from the dependency graph. If empty, omit this section.]
+```

package/sdd/skills/prd-to-task/reference/task-template.md

@@ -0,0 +1,63 @@
+# Task Definition Format
+
+## Rules
+
+- Task definition files must be self-contained — do not reference spec.md or prd.md. Copy all necessary context, decisions, and constraints into the task file
+- No gap between the task files and prd. Cumulative tasks context must cover prd.
+- All context must be in the task file to implement.
+- If Gherkin applies: every task must have at least one happy path, one edge case, one negative path scenario — in that order
+- Never invent quantitative or hardware constraint values — only use values explicitly stated in prd.md
+
+## Location
+Path: `docs/sdd/features/<feature-name>/tasks/<task-name>.md`
+
+## Structure
+```markdown
+# [Task Name]
+
+## Task-Meta
+- Feature: <feature-name>
+- Status: ⬜ Todo | 🔴 In Progress | ✅ Done
+
+## Context
+[2-3 sentences summarizing what this task does and why it matters. Written for executives/stakeholders who won't read the full document.]
+
+## Design/Implementation Decisions
+
+### [Category]
+
+**Decision:** [What was chosen]
+
+**Decision:** [What was chosen]
+
+## Visual Mock
+[If there are any visual/UI decisions, include visual mockups, wireframes, or layout descriptions here. If none, omit this section.]
+
+## Implmenetation Steps
+[Pre non-tdd task]
+[A short implementations steps in order to do this task.]
+
+## Out of Scopes
+[Not to be done in this task]
+
+## Scenarios
+
+### ✅ [Happy Path]
+> Story happy path — 1 only
+**Given** [system state / precondition]
+**When**  `[call / action + exact input]`
+**Then**  `[expected result / return]`
+**And**   `[if critical]`
+
+### ⬜ [Edge Case]
+> AC: PROJ-10
+**Given** [precondition]
+**When**  `[call + invalid / bad input]`
+**Then**  `[error / signal / rejection]` 
+**And**   `[if critical]`
+
+## Conventions
+- Naming:  `[test naming rule]`
+- Mock:    [what is replaced with what]
+- Seed:    [how initial state is set up]
+```

package/sdd/skills/spec-to-prd/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: spec-to-prd
+description: Converts spec.md files into PRD (Product Requirements Document) format. Use when user says "spec-to-prd", "convert to PRD", "write PRD from spec", or wants to generate a product requirements document from an existing feature spec.
+disable-model-invocation: true
+---
+
+# Spec to PRD Converter
+
+Transforms `spec.md` (technical specification with design decisions) into `prd.md` suitable for stakeholder review and product planning.
+
+---
+
+## Workflow
+
+### Step 1: Locate and Read spec.md
+
+**Announce:** "Step 1: Reading spec.md..."
+
+Find and read `docs/sdd/features/<feature-name>/spec.md`. Extract:
+- Feature name (from `# Feature: [Name]`)
+- Overview/summary
+- All design decisions with rationales
+- Any visual mockups or UX notes
+
+**Validation:** If spec.md does not exist, exit with error: "spec.md not found at docs/sdd/features/<feature-name>/spec.md"
+
+---
+
+### Step 2: Analyze for PRD Content
+
+**Announce:** "Step 2: Analyzing spec for PRD content..."
+- Explore the repo to understand the current state of codebase, if you haven't already.
+- Read [references/mapping-guide.md](references/mapping-guide.md). Apply the mapping table and inference rules to extract PRD content from spec.md design decisions.
+
+---
+
+### Step 3: Generate prd.md
+
+**Announce:** "Step 3: Generating prd.md..."
+
+	- Read [references/prd-format.md](references/prd-format.md). Use strictly this format and write `docs/sdd/features/<feature-name>/prd.md` following the template structure.
+
+---
+
+### Step 4: Report Output
+
+**Announce:** "Step 4: PRD generation complete"
+
+Report to the user:
+1. Path to generated PRD: `docs/sdd/features/<feature-name>/prd.md`
+2. Sections that need stakeholder input (marked as TBD)
+3. Any gaps where spec.md lacked sufficient detail for PRD completeness
+
+---
+
+## Edge Cases
+
+### Missing spec.md
+**Error:** "spec.md not found. Run `deep-spec` or create spec.md at `docs/sdd/features/<feature-name>/spec.md` first."
+
+### Incomplete spec.md
+If spec.md exists but lacks sufficient detail:
+- Generate PRD with all sections
+- Mark incomplete sections clearly with "TBD - requires spec.md update"
+- Report specific gaps: "Section 7.2 (Security) could not be populated - no security-related design decisions found in spec.md"
+
+### Multiple features in one spec.md
+If spec.md contains multiple distinct features:
+- Report: "spec.md appears to contain multiple features. Consider splitting into separate spec.md files per feature for cleaner PRD generation."
+- Generate a single PRD but note this in the report
+
+---
+
+## Next Step
+
+**→ `/prd-to-task`**