devflow-prompts 1.0.0

package/flows/devflow.2-rev-design.prompt.md

@@ -0,0 +1,132 @@
+---
+description: Review technical design for implementability and edge cases
+---
+
+# /devflow.2-rev-design
+
+## Description
+Review technical design to detect gaps, unhandled edge cases, and conflicts with coding rules.
+
+## Input Requirements
+
+**Input Type: File Path (Required)**
+- Provide path to your design file
+- **Filename MUST contain task-id** (e.g., `FEAT-001-design.md`, `TASK-123.md`)
+  - Task-id is needed to name output files
+  - Can be anywhere in filename: `FEAT-001`, `TASK-123`, `BUG-456`
+- **File can be located anywhere** (not limited to `/devflow-prompts`)
+- Examples:
+  - `~/work/FEAT-001-design.md` ✅
+  - `/tmp/TASK-123-spec.md` ✅
+  - `./my-BUG-456-design.md` ✅
+  - `~/design.md` ❌ (no task-id)
+- AI will read file and extract task-id from filename
+
+**Rule File**: `devflow.2-rev-design.rule.md` from `/devflow-prompts/rules/` (Design review checklist)
+
+## Input Validation
+
+- **Design file**: Required, must exist
+- **File name**: MUST contain task-id pattern `[A-Z]+-[0-9]+` (e.g., `FEAT-001-design.md`, `TASK-123.md`)
+- **Coding rules**: `devflow.2-rev-design.rule.md` is required
+
+**If validation fails**: Stop immediately and output error message.
+
+## Output Format
+1. **Review findings** (grouped)
+2. **Concrete improvements** (actionable bullets)
+3. **Revised version**: Full updated `{#task-id}-design.md`
+
+## Prompt
+
+```
+You are a Principal Engineer reviewer.
+Review the technical design for implementability, edge cases, and alignment with coding rules.
+
+INPUTS:
+1) Current {#task-id}-design.md
+<<<
+{USER INPUT HERE - MUST be a file path}
+>>>
+
+INSTRUCTIONS:
+
+1. **Read Input File**:
+   - The user will provide a file path.
+   - Use available file-reading tool (e.g. `view_file`) to read content.
+   - **Fallback**: If tool is unavailable, ask user to paste content.
+   - IF input is NOT a file path, ask user to provide a file path.
+   - File paths can be anywhere in the filesystem, not limited to `/devflow-prompts`.
+
+2. **Extract Task ID** (for file path input):
+   - Extract task-id from filename using pattern: `[A-Z]+-[0-9]+`
+   - Examples: `FEAT-001-design.md` → `FEAT-001`
+   - If no task-id found, ask user to provide it
+
+3. **Coding rules**:
+<<<
+{paste coding rules}
+>>>
+
+OUTPUT:
+1) Review findings (grouped by priority):
+- P0 (Critical - Must fix): Major gaps, security risks, blocked implementation
+- P1 (Important - Should fix): Missing edge cases, observability gaps
+- P2 (Improvement - Nice to have): Clarity, naming, minor conflicts
+2) Concrete improvements (actionable bullets)
+3) Produce a revised version:
+- Apply ALL critical improvements (P0/P1)
+- Output ONLY the full updated markdown for {#task-id}-design.md (same template)
+
+RULES:
+- Keep headings unchanged.
+- If info is missing from requirement, keep it as open questions instead of guessing.
+```
+
+## Review Checklist
+
+### Implementability
+- [ ] API contracts detailed enough to implement?
+- [ ] Data model has migration scripts?
+- [ ] Business logic has concrete steps?
+- [ ] Error handling complete?
+
+### Edge Cases
+- [ ] Concurrent access handled?
+- [ ] Timeout scenarios?
+- [ ] Resource limits (memory, disk)?
+- [ ] Data consistency?
+
+### Security
+- [ ] Input validation complete?
+- [ ] AuthN/AuthZ clear?
+- [ ] Rate limiting?
+- [ ] Data privacy (PII, encryption)?
+
+### Observability
+- [ ] Logs sufficient for debugging?
+- [ ] Metrics for monitoring?
+- [ ] Tracing if needed?
+
+### Rollout
+- [ ] Feature flag?
+- [ ] Migration plan?
+- [ ] Rollback plan?
+- [ ] Backward compatibility?
+
+### Coding Rules Compliance
+- [ ] Follows architecture patterns?
+- [ ] Naming conventions?
+- [ ] Folder structure?
+- [ ] Testing strategy aligned?
+
+## Usage Example
+
+## Usage Example
+
+```bash
+/devflow.2-rev-design /devflow-prompts/specs/FEAT-001/FEAT-001-design.md
+```
+
+## Next Steps
+After review is done → run `/devflow.3-gen-code` to generate code

package/flows/devflow.3-gen-code.prompt.md

@@ -0,0 +1,155 @@
+---
+description: Generate feature code from technical design (git patch format)
+---
+
+# /devflow.3-gen-code
+
+## Description
+Generate feature source code from technical design, output as git unified diff (patch).
+
+## Input Requirements
+
+**Input Type: File Path (Required)**
+- Provide path to your design file
+- **Filename MUST contain task-id** (e.g., `FEAT-001-design.md`, `TASK-123.md`)
+  - Task-id is needed to name output patch file
+  - Can be anywhere in filename: `FEAT-001`, `TASK-123`, `BUG-456`
+- **File can be located anywhere** (not limited to `/devflow-prompts`)
+- Examples:
+  - `~/projects/FEAT-001-design.md` ✅
+  - `/tmp/TASK-123-spec.md` ✅
+  - `./my-BUG-789.md` ✅
+  - `~/design.md` ❌ (no task-id)
+- AI will read file and extract task-id from filename
+
+**Rule File**: `devflow.3-gen-code.rule.md` from `/devflow-prompts/rules/` (Coding standards)
+
+**Task Mode (Optional, Default: NEW)**
+- `NEW`: Generating code for a new feature.
+- `UPDATE`: Updating or refactoring existing code.
+
+**Coding Rule Files**:
+- `devflow.3-gen-code.rule.md` (required). **MUST define project structure/roots.**
+
+## Input Validation
+
+- **Design file**: Required, must exist
+- **File name**: Must match pattern `{task-id}-design.md`
+- **Coding rules**: `devflow.3-gen-code.rule.md` is required
+- **Task Mode**: Must be `NEW` or `UPDATE` (case-insensitive)
+
+**If validation fails**: Stop immediately and output error message.
+
+## Output Format
+
+**Git unified diff (patch)** - NOT markdown!
+
+**Save to**: `/devflow-prompts/specs/{#task-id}/{#task-id}-feature.patch`
+
+Format:
+```diff
+diff --git a/path/to/file.ext b/path/to/file.ext
+index abc123..def456 100644
+--- a/path/to/file.ext
++++ b/path/to/file.ext
+@@ -10,6 +10,12 @@ existing code
++new code line 1
++new code line 2
+ existing code
+```
+
+## Prompt
+
+```
+You are a Senior Developer.
+Implement the feature EXACTLY following the technical design and coding rules.
+
+INPUT 1: {#task-id}-design.md
+<<<
+{USER INPUT HERE - Can be a file path OR design document content}
+>>>
+
+INPUT 2: Task Mode
+<<<
+{USER INPUT HERE - NEW | UPDATE}
+>>>
+
+INSTRUCTIONS:
+
+1. **Behave based on Mode**:
+   - **IF Mode is UPDATE**:
+     - CRITICAL: You MUST read the actual existing code files referenced in the design first.
+     - You are acting as a Maintainer. Safety and backward compatibility are top priorities.
+     - ONLY generate changes specified in the design.
+   - **IF Mode is NEW**:
+     - You are acting as a Creator. Follow standard architecture patterns.
+     - Generate complete files for the new feature.
+
+2. **Read Input File**:
+   - The user will provide a file path.
+   - USE `view_file` tool to read its content.
+   - IF input is NOT a file path, ask user to provide a file path.
+   - File paths can be anywhere in the filesystem, not limited to `/devflow-prompts`.
+
+3. **Extract Task ID** (for file path input):
+   - Extract task-id from filename using pattern: `[A-Z]+-[0-9]+`
+   - Examples: `FEAT-001-design.md` → `FEAT-001`
+   - If no task-id found, ask user to provide it
+
+4. **Understand Existing Codebase**:
+   - Inspect folder structure and naming conventions using **Coding Rules** as a guide.
+   - Use `list_dir` to explore relevant directories if paths are not explicit.
+   - **IF Mode is UPDATE**:
+     - Identify existing patterns (API handlers, services, repos) in the files related to the design.
+     - Reuse existing abstractions.
+
+INPUT 2: Coding rules (devflow.3-gen-code.rule.md)
+<<<
+{paste coding rules}
+>>>
+
+OUTPUT FORMAT:
+- Provide ONLY a git-style patch (unified diff).
+- Include only changed/new files.
+- No explanations outside the diff.
+
+RULES:
+1. **General Implementation (All Modes)**:
+   - Do not redesign. Only implement what is in the tech doc.
+   - Follow layering and naming conventions from coding rules.
+   - Add validation, error handling, and logging/metrics hooks as specified in design.
+   - **Traceability**: When implementing, add short comments referencing the design section (e.g., `// FEAT-001 §4 API`).
+   - **Ambiguity**: If design lacks implementation detail, implement the simplest compliant version and note TODO in code comment.
+   - **Ordering**: Generate files in deterministic order (API → domain → infra → tests).
+
+2. **Mode-Specific Rules**:
+   - **For NEW**:
+     - Create full file structures based on templates.
+     - Ensure new files are registered in system (e.g. dependency injection, router).
+   - **For UPDATE**:
+     - **Backward Compatibility**: Existing public interfaces MUST remain working unless design explicitly says to break them.
+     - **Minimal Touch**: Do NOT modify lines of code not related to the requirement.
+     - **Context Aware**: You must match the style of the *specific file* you are editing, even if it differs slightly from global rules (local consistency).
+```
+
+## Rules/Guidelines
+1. ✅ **No redesign** - Only implement what's in tech doc
+2. ✅ **Follow conventions** - Layering, naming from coding rules
+3. ✅ **Add validation** - Input validation as specified
+4. ✅ **Error handling** - Handle errors as designed
+5. ✅ **Logging/metrics** - Add hooks as specified
+6. ✅ **Minimal changes** - Only necessary changes
+7. ✅ **Traceability** - Reference design section in comments
+8. ✅ **Handle Ambiguity** - Simple version + TODO for missing details
+9. ✅ **Deterministic Order** - API → Domain → Infra → Tests
+
+## Usage Example
+
+## Usage Example
+
+```bash
+/devflow.3-gen-code /devflow-prompts/specs/FEAT-001/FEAT-001-design.md
+```
+
+## Next Steps
+After applying patch → run `/devflow.3-rev-code` to review

package/flows/devflow.3-rev-code.prompt.md

@@ -0,0 +1,150 @@
+---
+description: Review generated code patch for quality and correctness
+---
+
+# /devflow.3-rev-code
+
+## Description
+Review generated code patch to check correctness, quality, and alignment with tech doc.
+
+## Input Requirements
+
+**Input Type: File Paths (Required)**
+- Provide paths to your design file and patch file
+- **At least one filename MUST contain task-id** (e.g., `FEAT-001-design.md`)
+  - Task-id is needed to name output files
+  - Can be anywhere in filename: `FEAT-001`, `TASK-123`, `BUG-456`
+- **Files can be located anywhere** (not limited to `/devflow-prompts`)
+- Examples:
+  - `~/FEAT-001-design.md ~/feature.patch` ✅
+  - `/tmp/TASK-123-spec.md /tmp/code.diff` ✅
+  - `./design.md ./patch.diff` ❌ (no task-id)
+- AI will read both files and extract task-id from filenames
+
+**Rule File**: `devflow.3-rev-code.rule.md` from `/devflow-prompts/rules/` (Code review checklist)
+
+**Task Mode (Optional, Default: NEW)**
+- `NEW`: Reviewing new feature code.
+- `UPDATE`: Reviewing update/refactor code (Expect minimal diffs).
+
+## Input Validation
+
+- **Design file**: Required, must exist
+- **Generated patch**: Required, must be valid git diff format
+- **Coding rules**: `devflow.3-rev-code.rule.md` is required
+
+**If validation fails**: Stop immediately and output error message.
+
+## Output Format
+1. **Findings** (grouped)
+2. **Mandatory fixes list**
+3. **Corrected patch**: New unified diff with fixes applied
+
+## Prompt
+
+```
+You are a Tech Lead reviewer.
+Review the generated patch for correctness, code quality, edge cases, and alignment with the tech doc.
+
+INPUTS:
+1) Tech doc
+<<<
+{USER INPUT 1 - Can be a file path OR design document content}
+>>>
+
+2) Generated patch (diff)
+<<<
+{USER INPUT 2 - Can be a file path OR patch content}
+>>>
+
+3) Task Mode (Optional): NEW | UPDATE
+4) Coding rules: <paste content>
+
+INSTRUCTIONS:
+
+1. **Read Input Files**:
+   - The user will provide file paths.
+   - USE `view_file` tool to read them.
+   - IF inputs are NOT file paths, ask user to provide file paths.
+   - File paths can be anywhere in the filesystem, not limited to `/devflow-prompts`.
+
+2. **Extract Task ID** (for file path input):
+   - Extract task-id from filenames using pattern: `[A-Z]+-[0-9]+`
+   - Check both filenames for task-id
+   - Examples: `FEAT-001-design.md` → `FEAT-001`
+   - If no task-id found, ask user to provide it
+
+3. **Context & Mode Awareness**:
+   - **IF Mode is UPDATE**:
+     - **Backward Compatibility Check**: Does the patch break any existing public signatures?
+     - **Legacy Safety**: Does it modify core/shared files unnecessarily?
+     - **Minimal Touch**: Reject large refactors not requested in design.
+   - **IF Mode is NEW**:
+     - Check for architectural compliance and new file structure validity.
+
+4. **Coding Rules**:
+   - Use the provided Coding Rules content as the "Gold Standard" checklist.
+
+OUTPUT:
+1) Findings (grouped):
+- Deviations from tech doc
+- Bugs / incorrect logic
+- Missing validation / error handling
+- Security issues
+- Missing logs/metrics
+- Code smells / refactor suggestions
+2) Mandatory fixes list (must-do)
+3) Produce a corrected patch:
+- Output ONLY a new unified diff patch that applies the fixes (no commentary outside diff)
+
+RULES:
+- Prefer minimal diffs.
+- If something cannot be fixed without new requirements, add a TODO and list it in findings.
+```
+
+## Review Checklist
+
+### Alignment with Tech Doc
+- [ ] Implements all specified endpoints/methods?
+- [ ] Follows data model changes?
+- [ ] Business logic matches UC steps?
+- [ ] Error handling as designed?
+
+### Code Quality
+- [ ] Naming conventions followed?
+- [ ] Proper layering (Controller → Service → Repository)?
+- [ ] No code duplication?
+- [ ] Clean, readable code?
+
+### Security
+- [ ] Input validation present?
+- [ ] No SQL injection risks?
+- [ ] No XSS vulnerabilities?
+- [ ] Sensitive data not logged?
+
+### Error Handling
+- [ ] All edge cases handled?
+- [ ] Proper error messages?
+- [ ] Correct HTTP status codes?
+- [ ] No silent failures?
+
+### Observability
+- [ ] Logs added as specified?
+- [ ] Metrics hooks present?
+- [ ] Enough context in logs?
+
+### Testing
+- [ ] Code is testable?
+- [ ] Dependencies injectable?
+- [ ] No hard-coded values?
+
+## Usage Example
+
+## Usage Example
+
+```bash
+/devflow.3-rev-code /devflow-prompts/specs/FEAT-001/FEAT-001-design.md /devflow-prompts/specs/FEAT-001/FEAT-001-feature.patch
+```
+
+## Next Steps
+After reviewing code → run `/devflow.4-gen-test-plan` to create test plan

package/flows/devflow.4-gen-test-plan.prompt.md

@@ -0,0 +1,171 @@
+---
+description: Create test plan from technical design (unit/integration/E2E)
+---
+
+# /devflow.4-gen-test-plan
+
+## Description
+Create test plan document from technical design and coding rules, covering unit/integration/E2E tests.
+
+## Input Requirements
+
+**Input Type: File Path (Required)**
+- Provide path to your design file
+- **Filename MUST contain task-id** (e.g., `FEAT-001-design.md`, `TASK-123.md`)
+  - Task-id is needed to name output test plan file
+  - Can be anywhere in filename: `FEAT-001`, `TASK-123`, `BUG-456`
+- **File can be located anywhere** (not limited to `/devflow-prompts`)
+- Examples:
+  - `~/Documents/FEAT-001-design.md` ✅
+  - `/tmp/TASK-123-spec.md` ✅
+  - `./my-BUG-456.md` ✅
+  - `~/design.md` ❌ (no task-id)
+- AI will read file and extract task-id from filename
+
+**Task Mode (Optional, Default: NEW)**
+- `NEW`: Test plan for new feature.
+- `UPDATE`: Test plan for feature update (Focus on regression).
+
+**Coding Rule Files** (from `/devflow-prompts/rules/`):
+- `devflow.4-gen-test-plan.rule.md` (required) - Test guidelines. **MUST define specific test folder structure.**
+
+**Language** (optional): Output language (default: `en`)
+
+## Input Validation
+
+- **Design file**: Required, must exist
+- **File name**: Must match pattern `{task-id}-design.md`
+- **Coding rules**: `devflow.4-gen-test-plan.rule.md` is required
+- **Language**: If specified, must be one of: `en`, `vi`, `ja`, `ko`
+
+**If validation fails**: Stop immediately and output error message.
+
+## Output Format
+File markdown: `{#task-id}-test.md`
+
+**Folder Structure**: Save in `/devflow-prompts/specs/{#task-id}/`
+```
+/devflow-prompts/specs/{#task-id}/{#task-id}-test.md
+```
+
+## Template
+
+```markdown
+# {#task-id} - Test Plan
+
+## 1. Scope
+- In scope:
+- Out of scope:
+
+## 2. Test levels & strategy
+### Unit tests
+- Targets:
+- What to mock:
+- Coverage goals:
+- Test cases list:
+
+### Integration tests
+- Dependencies:
+- Setup/teardown:
+- Test cases list:
+
+### E2E tests (if applicable)
+- User flows:
+- Test cases list:
+
+## 3. Detailed test cases
+### TC-1: <title>
+- Level: Unit/Integration/E2E
+- Preconditions:
+- Steps:
+- Expected:
+- Notes:
+
+## 4. Negative & Edge cases
+- ...
+
+## 5. Non-functional tests (if needed)
+- Performance:
+- Security:
+- Concurrency:
+
+## 6. Test data
+- Fixtures/seed:
+- Data matrix:
+```
+
+## Prompt
+
+```
+You are a QA Lead + SDET.
+Create a test plan derived from the technical design and coding rules.
+
+LANGUAGE SETTING:
+- Default: English (en)
+- User can override by adding "Language: {vi|ja|ko}" in input
+- Write in the specified language
+
+INPUTS:
+1) {#task-id}-design.md
+<<<
+{USER INPUT HERE - Can be a file path OR design document content}
+{USER INPUT HERE - Can be a file path OR design document content}
+>>>
+3) Task Mode (Optional): NEW | UPDATE
+4) Coding rules: <paste content>
+
+INSTRUCTIONS:
+
+1. **Read Input File**:
+   - The user will provide a file path.
+   - USE `view_file` tool to read its content.
+   - IF input is NOT a file path, ask user to provide a file path.
+   - File paths can be anywhere in the filesystem, not limited to `/devflow-prompts`.
+
+2. **Extract Task ID** (for file path input):
+   - Extract task-id from filename using pattern: `[A-Z]+-[0-9]+`
+   - Examples: `FEAT-001-design.md` → `FEAT-001`
+   - If no task-id found, ask user to provide it
+
+123. **Task Mode & Context**:
+   - **IF Mode is UPDATE**:
+     - **Regression Strategy**: MANDATORY section. List legacy features that MUST NOT break.
+     - Inspect existing test files (using `list_dir`) to match current test style/naming.
+   - **IF Mode is NEW**:
+     - Focus on complete coverage for new requirements.
+
+4. **Coding rules**:
+<<<
+{paste coding rules}
+>>>
+
+OUTPUT:
+- Produce ONLY the markdown content for file: {#task-id}-test.md
+- Follow EXACTLY this template structure:
+<<<
+{PASTE TEMPLATE ABOVE HERE}
+>>>
+
+RULES:
+- Every use case and major rule in tech doc must be covered by at least one test.
+- Include negative tests: validation errors, permission checks, missing resources, conflict states.
+- Clearly state what to mock vs integrate.
+```
+
+## Rules/Guidelines
+1. ✅ **Coverage** - Each UC and rule must have tests
+2. ✅ **Negative tests** - Validation errors, permission denied, not found
+3. ✅ **Mock vs Integrate** - Clear what to mock, what to integrate
+4. ✅ **Test data** - Specific fixtures/seed data
+5. ✅ **Edge cases** - Concurrent, timeout, limits
+
+## Usage Example
+
+## Usage Example
+
+```bash
+/devflow.4-gen-test-plan /devflow-prompts/specs/FEAT-001/FEAT-001-design.md
+```
+
+## Next Steps
+After test plan is ready → run `/devflow.4-rev-test-plan` to review