Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

sdd-plan

Étoiles31

Forks7

Mis à jour27 avril 2026 à 16:41

SDD step 3. Read feature.md and produce a detailed implementation plan.md tailored to the project's tech stack and architecture. Use after /sdd-feature has produced feature.md.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

sivaprasadreddy

sivaprasadreddy/sdd-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	sdd-plan
description	SDD step 3. Read feature.md and produce a detailed implementation plan.md tailored to the project's tech stack and architecture. Use after /sdd-feature has produced feature.md.

SDD: Implementation Planning

You are acting as a senior software engineer creating a precise, actionable implementation plan.

Pre-conditions

Verify both files exist before proceeding:

feature.md — the feature spec (if missing, tell the user to run /sdd-feature first)
docs/project.md — project context

Process

1. Read Both Files

Read feature.md and docs/project.md in full.

2. Identify the Tech Stack

From docs/project.md, note:

Primary language and framework
Build tool and compile/test commands
Database and data access layer
Messaging systems
Testing frameworks
Any architecture patterns (e.g., Hexagonal, DDD, Layered)

3. Produce plan.md

Create plan.md in the project root with this structure:

# Implementation Plan: <Feature Name>

## Overview
Brief description of the implementation approach.

## Architecture Decisions
- Key design choices and their rationale
- Patterns to follow (aligned with docs/project.md)

## Implementation Steps

### Step 1: <Database/Schema Changes>
- [ ] Create/alter table: `...`
- [ ] Add migration file: `...`
- Files to create/modify: ...

### Step 2: <Domain Layer>
- [ ] Create entity / model: `...`
- [ ] Create value objects: `...`
- [ ] Define repository / data access interface: `...`
- Files: ...

### Step 3: <Application/Service Layer>
- [ ] Create use case / service: `...`
- [ ] Define request/response objects / command objects: `...`
- Files: ...

### Step 4: <Infrastructure/Adapter Layer>
- [ ] Implement repository / data access: `...`
- [ ] External integrations: `...`
- Files: ...

### Step 5: <API / Presentation Layer>
- [ ] Controller / handler / route: `...`
- [ ] Request/response models: `...`
- [ ] API documentation annotations: `...`
- Files: ...

### Step 6: <Tests>
- [ ] Unit tests: `...`
- [ ] Integration tests: `...`
- [ ] API / end-to-end tests: `...`
- Files: ...

## Acceptance Criteria Mapping
| AC | Verified By |
|----|-------------|
| AC-01: ... | `<TestClass#testMethod>` |
| AC-02: ... | `<TestClass#testMethod>` |

## Risks & Mitigations
- Risk: ... → Mitigation: ...

## Estimated Complexity
Low / Medium / High — brief justification

After writing the file, present a summary of the plan and ask the user to approve before proceeding to /sdd-implement.

Plus depuis ce dépôt

même dépôt

sdd-feature

sivaprasadreddy/sdd-skills

SDD step 1. Analyse a feature request and produce a detailed feature.md spec. Use when the user describes a new feature they want to build. Asks for missing details before writing the spec.

2026-04-2731

sdd-init

sivaprasadreddy/sdd-skills

SDD step 0. Analyse the project codebase and create docs/project.md with tech stack, architecture, and conventions. Run once before starting SDD in a new project. If docs/project.md already exists, asks whether to regenerate it.

2026-04-2731

sdd-refine

sivaprasadreddy/sdd-skills

SDD step 2 (optional, repeatable). Read an existing feature.md and refine it by updating or enhancing requirements based on user input. Use when requirements have changed, new edge cases are discovered, or the spec needs clarification before planning or re-planning. Run before /sdd-plan if plan.md already exists.

2026-04-2731

sdd-yolo

sivaprasadreddy/sdd-skills

SDD fast path. Runs the full pipeline — analyse → plan → implement → review → archive — with a single confirmation gate before implementation begins. Stops automatically if Critical or Major issues are found in review. Use when you want to ship a well-understood feature with minimal interruptions.

2026-04-2731

sdd-archive

sivaprasadreddy/sdd-skills

SDD step 7. Archive feature.md and plan.md into docs/specs-archive/<yyyymmddHHMM>-<feature-name>/ directory, then update docs/project.md with the new feature, and any architecture decisions made. Use after /sdd-review is complete and the feature is ready to merge.

2026-04-2731

sdd-review

sivaprasadreddy/sdd-skills

SDD step 5. Reviews the implemented feature code against language and framework best practices, checks for code duplication, security vulnerabilities, performance issues, test coverage, and alignment with feature.md acceptance criteria. Use after /sdd-implement or on any existing feature implementation.

2026-04-2731

SDD: Implementation Planning

You are acting as a senior software engineer creating a precise, actionable implementation plan.

Pre-conditions

Verify both files exist before proceeding:

feature.md — the feature spec (if missing, tell the user to run /sdd-feature first)

docs/project.md — project context

Process

1. Read Both Files

Read feature.md and docs/project.md in full.

2. Identify the Tech Stack

From docs/project.md, note:

Primary language and framework

Build tool and compile/test commands

Database and data access layer

Messaging systems

Testing frameworks

Any architecture patterns (e.g., Hexagonal, DDD, Layered)

3. Produce plan.md

Create plan.md in the project root with this structure:

# Implementation Plan: <Feature Name> ## Overview Brief description of the implementation approach. ## Architecture Decisions - Key design choices and their rationale - Patterns to follow (aligned with docs/project.md) ## Implementation Steps ### Step 1: <Database/Schema Changes> - [ ] Create/alter table: `...` - [ ] Add migration file: `...` - Files to create/modify: ... ### Step 2: <Domain Layer> - [ ] Create entity / model: `...` - [ ] Create value objects: `...` - [ ] Define repository / data access interface: `...` - Files: ... ### Step 3: <Application/Service Layer> - [ ] Create use case / service: `...` - [ ] Define request/response objects / command objects: `...` - Files: ... ### Step 4: <Infrastructure/Adapter Layer> - [ ] Implement repository / data access: `...` - [ ] External integrations: `...` - Files: ... ### Step 5: <API / Presentation Layer> - [ ] Controller / handler / route: `...` - [ ] Request/response models: `...` - [ ] API documentation annotations: `...` - Files: ... ### Step 6: <Tests> - [ ] Unit tests: `...` - [ ] Integration tests: `...` - [ ] API / end-to-end tests: `...` - Files: ... ## Acceptance Criteria Mapping | AC | Verified By | |----|-------------| | AC-01: ... | `<TestClass#testMethod>` | | AC-02: ... | `<TestClass#testMethod>` | ## Risks & Mitigations - Risk: ... → Mitigation: ... ## Estimated Complexity Low / Medium / High — brief justification

After writing the file, present a summary of the plan and ask the user to approve before proceeding to /sdd-implement.