devflow-prompts 1.0.0

package/flows/devflow.1-gen-requirement.prompt.md

@@ -0,0 +1,279 @@
+---
+description: Convert raw customer request to structured requirement document
+---
+
+# /devflow.1-gen-requirement
+
+## Description
+
+Convert raw customer request into a structured, clear, and testable requirement document. Supports input via direct text or a file path.
+
+## Input Requirements
+
+**Input Type: File Path (Required)**
+- Provides path to a text file containing Task ID, Language, and Raw Request.
+- **File can be located anywhere** (e.g., `~/Desktop/request.txt`, `/tmp/my-task.txt`).
+- **Filename**: Flexible naming, but meaningful names recommended (e.g., `FEAT-001-request.txt`).
+- Format inside file:
+  ```text
+  Task ID: ...
+  Language: ...
+  Raw Request: ...
+  ```
+- AI will automatically read the file.
+
+**Task Mode (Optional, Default: NEW)**
+- `NEW`: New feature request.
+- `UPDATE`: Request to update/refactor existing functionality.
+
+**Existing Logic/Code (Required for UPDATE)**
+- If Mode is `UPDATE`, provide current business rules or code snippets to be modified.
+
+**Rule File** (optional but recommended):
+- `devflow.1-gen-requirement.rule.md` from `/devflow-prompts/rules/` - Guidelines for generating requirements
+
+## Input Validation
+
+- **Task ID**: Required, cannot be empty
+- **Raw Request**: Required, cannot be empty
+- **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}-requirement.md`
+
+**Folder Structure**: All feature artifacts must be stored in:
+
+```
+/devflow-prompts/specs/{#task-id}/
+├── {#task-id}-requirement.md
+├── {#task-id}-design.md
+├── {#task-id}-test.md
+├── {#task-id}-feature.patch
+└── {#task-id}-test.patch
+```
+
+Example: `/devflow-prompts/specs/FEAT-001/FEAT-001-requirement.md`
+
+## Template
+
+```markdown
+# {#task-id} - Requirement
+
+## 0. Raw Request (Original)
+
+**Source**: {Email/Meeting/Ticket/etc.}
+**Date**: {YYYY-MM-DD}
+**From**: {Customer/Stakeholder name}
+```
+{Paste exact original request here - keep verbatim}
+
+```
+
+---
+
+## 1. Overview
+- Goal:
+- Background:
+- Stakeholders:
+
+## 2. Scope
+### In scope
+- ...
+
+### Out of scope
+- ...
+
+## 3. User stories
+- US-1:
+- US-2:
+
+## 4. Functional requirements
+### FR-1: <title>
+- Description:
+- Acceptance Criteria:
+  - [ ] AC-1 ...
+  - [ ] AC-2 ...
+- Error/Edge cases:
+  - ...
+
+## 5. Non-functional requirements
+- Performance:
+- Security:
+- Reliability:
+- Observability:
+
+## 6. Data & Business rules
+- Entities:
+- Rules/Validation:
+- Permissions:
+
+## 7. UI/UX (if applicable)
+- Screens/Flows:
+- Empty states:
+
+## 8. Integration (if applicable)
+- External systems:
+- Constraints:
+
+## 9. Assumptions
+- ...
+
+## 10. Open questions (ask customer)
+- Q1:
+- Q2:
+
+## 11. Examples
+- Example scenarios:
+- Example inputs/outputs:
+```
+
+## Prompt
+
+```
+You are a Senior Business Analyst.
+Convert the raw customer request into a clear requirement document.
+
+INPUT:
+<<<
+{USER INPUT HERE - File path}
+>>>
+
+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`.
+
+   **Behave based on Mode (if specified in file or prompt)**:
+   - **IF Mode is UPDATE**:
+     - Check if "Existing Logic" is provided.
+     - Focus on "What changes" vs "What remains".
+     - In "Scope", explicitly list what is preserved.
+   - **IF Mode is NEW**:
+     - Focus on complete new feature definition.
+
+2. **Parse Information**:
+   - Extract **Task ID**.
+   - Extract **Language** (default `en` if missing).
+   - Extract **Raw Request** (the core message).
+
+3. **Output Generation**:
+   - Produce ONLY the markdown content for file: `{Task ID}-requirement.md`.
+   - Follow EXACTLY the template below.
+   - Keep technical terms in English (API, HTTP, JWT, etc.).
+   - Write professionally in the identified language.
+
+TEMPLATE:
+<<<
+{PASTE TEMPLATE ABOVE HERE}
+>>>
+
+RULES:
+- Do NOT invent missing information. Put missing items into "Open questions".
+- Acceptance criteria must be checkbox items.
+- Include error/edge cases for each functional requirement.
+- If a section (e.g., UI/UX, Integration) is not applicable, explicitly write "Not applicable" (do not remove the section).
+```
+
+## Rules/Guidelines
+
+1. ✅ **No invention** - Missing info → put in "Open questions"
+2. ✅ **Acceptance Criteria** - Must be checkbox format, testable
+3. ✅ **Error/Edge cases** - Each FR must have error cases
+4. ✅ **Language flexibility** - Default English, can override
+5. ✅ **Examples** - Must have concrete input/output examples
+
+## Usage Example
+
+```bash
+/devflow.1-gen-requirement ~/Desktop/FEAT-001-request.txt
+```
+
+## Common Mistakes to Avoid
+
+### ❌ Inventing Information
+
+```markdown
+# BAD
+
+- Password must be at least 8 characters
+  (Customer didn't mention password requirements)
+```
+
+```markdown
+# GOOD
+
+## 10. Open questions
+
+- Q1: What are the password requirements (length, complexity)?
+```
+
+### ❌ Vague Acceptance Criteria
+
+```markdown
+# BAD
+
+- [ ] AC-1: Login works correctly
+```
+
+```markdown
+# GOOD
+
+- [ ] AC-1: User enters correct email/password → redirect to dashboard
+- [ ] AC-2: User enters wrong password → show error "Invalid credentials"
+- [ ] AC-3: Session token created and stored in cookie (httpOnly, secure)
+```
+
+### ❌ Missing Edge Cases
+
+```markdown
+# BAD
+
+### FR-1: Login
+
+- Description: User logs in
+```
+
+```markdown
+# GOOD
+
+### FR-1: Login
+
+- Description: User logs in with email/password
+- Error/Edge cases:
+  - Email doesn't exist
+  - Wrong password
+  - Account locked
+  - Empty email/password
+```
+
+## Language Override Examples
+
+### Example 1: Vietnamese output
+
+```bash
+Task ID: FEAT-001
+Language: vi
+Raw request: "Tôi muốn user đăng nhập bằng email/password"
+
+# → Output will be in Vietnamese
+```
+
+### Example 2: Japanese output
+
+```bash
+Task ID: FEAT-001
+Language: ja
+Raw request: "メール/パスワードでログインできるようにしたい"
+
+# → Output will be in Japanese
+```
+
+## Next Steps
+
+After requirement is ready → run `/devflow.1-rev-requirement` to review

package/flows/devflow.1-rev-requirement.prompt.md

@@ -0,0 +1,206 @@
+---
+description: Review requirement document for completeness and clarity
+---
+
+# /devflow.1-rev-requirement
+
+## Description
+Review requirement document to detect gaps, ambiguities, contradictions, and suggest improvements.
+
+## Input Requirements
+
+**Input Type: File Path (Required)**
+- Provide path to your requirement file
+- **Filename MUST contain task-id** (e.g., `FEAT-001-requirement.md`, `FEAT-001.md`, `my-FEAT-001-spec.md`)
+  - Task-id is needed to name output files
+  - Can be anywhere in filename, any format: `TASK-123`, `FEAT-001`, `BUG-456`
+- **File can be located anywhere** (not limited to `/devflow-prompts`)
+- Examples:
+  - `~/Desktop/FEAT-001-requirement.md` ✅
+  - `/tmp/TASK-123-spec.md` ✅
+  - `./my-FEAT-001-notes.txt` ✅
+  - `~/requirement.md` ❌ (no task-id)
+- AI will automatically read file and extract task-id from filename
+
+**Rule File** (optional but recommended):
+- `devflow.1-rev-requirement.rule.md` from `/devflow-prompts/rules/` (for quality checklist)
+
+
+
+## Input Validation
+
+- **Requirement file**: Required, must exist
+- **File format**: Must be valid markdown
+- **Task ID**: Must be extractable from filename (e.g., `FEAT-001`, `TASK-123`, `BUG-456`)
+  - Pattern: Uppercase letters + dash + numbers (e.g., `FEAT-001`, `TASK-123`)
+  - If not found in filename, AI should ask user to provide task-id
+
+**If validation fails**: Stop immediately and output error message.
+
+## Output Format
+1. **Issues list** (grouped):
+   - Missing info
+   - Ambiguities
+   - Conflicts/contradictions
+   - Unclear acceptance criteria
+   - Missing edge/error cases
+2. **Proposed fixes** (bullet points)
+3. **Revised version**: Full updated markdown for `{#task-id}-requirement.md`
+
+## Prompt
+
+```
+You are a Product Owner + QA reviewer.
+Review the requirement document for completeness, ambiguity, contradictions, and testability.
+
+INPUT:
+<<<
+{USER INPUT HERE - File path}
+>>>
+
+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-requirement.md` → task-id: `FEAT-001`
+     - `/tmp/TASK-123-spec.md` → task-id: `TASK-123`
+     - `my-BUG-456-notes.txt` → task-id: `BUG-456`
+   - If no task-id found in filename, ask user to provide it
+
+3. **Review the Requirement**:
+   - Analyze for completeness, ambiguity, contradictions, testability
+   - Check against quality checklist
+
+OUTPUT:
+1) Issues list (grouped):
+- Missing info
+- Ambiguities
+- Conflicts/contradictions
+- Unclear acceptance criteria
+- Missing edge/error cases
+2) Proposed fixes (bullet points)
+3) Produce a revised version:
+- Output ONLY the full updated markdown for {#task-id}-requirement.md (same template)
+
+RULES:
+- Keep the template headings unchanged.
+- If something cannot be resolved, keep it as an "Open question" but rewrite the question to be specific.
+```
+
+## Rules/Guidelines
+1. ✅ **Completeness** - Are all sections fully filled?
+2. ✅ **Ambiguity** - Any unclear parts that can be interpreted multiple ways?
+3. ✅ **Contradictions** - Any conflicts between requirements?
+4. ✅ **Testability** - Can acceptance criteria be tested?
+5. ✅ **Edge cases** - Are all error/edge cases covered?
+
+## Review Checklist
+
+### Completeness Check
+- [ ] Overview has Goal, Background, Stakeholders?
+- [ ] Scope clearly defines In/Out scope?
+- [ ] Has User Stories?
+- [ ] Each FR has Description, AC, Error cases?
+- [ ] NFR covers Performance, Security, Reliability?
+- [ ] Data & Business rules are clear?
+- [ ] Has concrete Examples?
+
+### Ambiguity Check
+- [ ] Acceptance Criteria specific enough?
+- [ ] Validation rules clear (not using "appropriate", "reasonable")?
+- [ ] Error messages defined?
+- [ ] UI/UX flows clear?
+
+### Contradiction Check
+- [ ] FRs don't conflict with each other?
+- [ ] NFRs don't conflict with FRs?
+- [ ] Business rules consistent?
+
+### Testability Check
+- [ ] Each AC can be verified?
+- [ ] Expected behavior clear?
+- [ ] Test data can be prepared?
+
+### Edge Cases Check
+- [ ] Empty/null inputs?
+- [ ] Invalid formats?
+- [ ] Permission denied?
+- [ ] Resource not found?
+- [ ] Concurrent access?
+- [ ] Timeout scenarios?
+
+## Usage Example
+
+## Usage Example
+
+```bash
+/devflow.1-rev-requirement /devflow-prompts/specs/FEAT-001/FEAT-001-requirement.md
+```
+
+## Common Issues Found
+
+### Missing Info
+```markdown
+# Issue
+FR-1 doesn't specify session timeout duration
+
+# Fix
+→ Add to Open questions: "Q: What is the session timeout? (suggest: 2h)"
+```
+
+### Ambiguity
+```markdown
+# Issue
+AC: "User is notified when error occurs"
+→ How to notify? Toast? Email? SMS?
+
+# Fix
+AC: "User sees red error message at top of form"
+```
+
+### Contradiction
+```markdown
+# Issue
+FR-1: "User must verify email before login"
+FR-2: "User can login immediately after register"
+→ Contradiction!
+
+# Fix
+Clarify: User can login but has limited features until email verified
+```
+
+### Unclear AC
+```markdown
+# Issue
+AC: "Login works correctly"
+→ Too vague!
+
+# Fix
+AC-1: User enters correct credentials → redirect to /dashboard
+AC-2: User enters wrong password → show error, stay on login page
+AC-3: Session token stored in cookie with httpOnly=true, secure=true
+```
+
+### Missing Edge Cases
+```markdown
+# Issue
+FR-1: Login
+→ No error cases
+
+# Fix
+Error/Edge cases:
+- Email doesn't exist → show "Invalid credentials"
+- Wrong password → show "Invalid credentials"
+- Account locked → show "Account locked. Try again in X minutes"
+- Empty email/password → show validation errors
+```
+
+## Next Steps
+After clarifying → run `/devflow.2-gen-design` to create technical design

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

@@ -0,0 +1,217 @@
+---
+description: Create technical design from requirement (architecture, API, data model)
+---
+# /devflow.2-gen-design
+
+## Description
+
+Create technical design document from requirement and coding rules, including architecture, API, data model, security, observability.
+
+## Input Requirements
+
+**Input Type: File Path (Required)**
+- Provide path to your requirement file
+- **Filename MUST contain task-id** (e.g., `FEAT-001-requirement.md`, `TASK-123.md`)
+  - Task-id is needed to name output design 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-requirement.md` ✅
+  - `/tmp/TASK-123-spec.md` ✅
+  - `./BUG-456-notes.txt` ✅
+  - `~/requirement.md` ❌ (no task-id)
+- AI will automatically read the file.
+
+**Task Mode (Optional, Default: NEW)**
+- `NEW`: Designing a new feature.
+- `UPDATE`: Modifying existing design/code. **Requires strict impact analysis.**
+
+**Coding Rule Files** (from `/devflow-prompts/rules/`):
+- `devflow.2-gen-design.rule.md` (required) - Architecture, API, Security guidelines. 
+**MUST define project structure/roots.**
+- `devflow.3-gen-code.rule.md` (optional) - For implementation context
+
+**Language** (optional): Output language (default: `en`)
+
+## Input Validation
+
+- **Requirement file**: Required, must exist
+- **File name**: MUST contain task-id pattern `[A-Z]+-[0-9]+` (e.g., `FEAT-001-req.md`, `TASK-123.md`)
+- **Coding rules**: `devflow.2-gen-design.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}-design.md`
+
+**Folder Structure**: Save in `/devflow-prompts/specs/{#task-id}/`
+
+```
+/devflow-prompts/specs/{#task-id}/{#task-id}-design.md
+```
+
+## Template
+
+```markdown
+# {#task-id} - Technical Design
+
+## 1. Summary
+- What we build:
+- Why:
+- Non-goals:
+
+## 2. Assumptions & Constraints
+- Assumptions:
+- Constraints (tech/product/legal):
+
+## 3. Architecture / Approach
+- High-level approach:
+- Components/modules:
+- Data flow:
+
+## 4. API / Contracts
+### Endpoints / RPC
+- <METHOD> <PATH>
+  - Request:
+  - Response:
+  - Auth:
+  - Errors:
+    - Status code:
+    - Error code:
+    - Message:
+
+### Events / Jobs (if any)
+- ...
+
+## 5. Data model
+- Tables/Collections changes:
+- Migrations:
+- Indexing:
+
+## 6. Detailed business logic
+### UC-1: <use case name>
+- Steps:
+- Validation:
+- Permission checks:
+- Edge cases:
+- Idempotency (if needed):
+
+## 7. Security
+- AuthN/AuthZ:
+- Input validation:
+- Rate limit:
+- Data privacy:
+
+## 8. Observability
+- Logs:
+- Metrics:
+- Tracing:
+
+## 9. Rollout & Backward compatibility
+- Feature flag:
+- Migration/compatibility:
+- Deployment steps:
+- Rollback plan:
+
+## 10. Test strategy (high level)
+- Unit:
+- Integration:
+- E2E:
+
+## 11. Task breakdown
+- [ ] Backend:
+- [ ] Frontend:
+- [ ] Migration:
+- [ ] Docs:
+
+## 12. Risks / Open questions
+- ...
+```
+
+## Prompt
+
+```
+You are a Staff Software Engineer.
+Write an implementable technical design based on the requirement 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) Requirement file: <file path containing task-id>
+{USER INPUT HERE - MUST be a file path}
+>>>
+3) Task Mode (Optional): NEW | UPDATE
+4) Coding rules: <paste content>
+
+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-requirement.md` → `FEAT-001`, `TASK-123.md` → `TASK-123`
+   - If no task-id found, ask user to provide it
+
+3. **Existing System Awareness & Mode**:
+   - **IF Mode is UPDATE**:
+     - **MANDATORY**: Inspect the existing codebase using the structure defined in the **Coding Rules**.
+     - Use `list_dir` and `view_file` to analyze relevant files in the current workspace.
+     - **Impact Analysis**: Fill section 3.5 carefully. Identify ALL touched components with exact file paths if possible.
+     - **Backward Compatibility**: Explicitly state how old clients/data are supported.
+     - **Constraint Check**: Verify if changes violate any architectural boundary defined in Rules.
+   - **IF Mode is NEW**:
+     - Follow the architecture defined in **Coding Rules**.
+     - Align with the existing project structure (do not invent a new architecture unless the project is empty).
+
+   - **System Context**:
+     - Rely on the **Coding Rules** to understand the project structure (e.g., where `services`, `controllers` are located).
+     - Do not ask user for paths if they are standard/defined in rules.
+
+4. **Coding rules**:
+<<<
+{paste coding rules - Architecture, BE, FE, Test, Security}
+>>>
+
+OUTPUT:
+- Produce ONLY the markdown content for file: {#task-id}-design.md
+- Follow EXACTLY this template structure:
+<<<
+{PASTE TEMPLATE ABOVE HERE}
+>>>
+
+RULES:
+- Do not change requirements. If requirement is unclear, list it in "Risks / Open questions".
+- Make concrete decisions: endpoints, validation rules, status/error codes, data model changes.
+- Ensure compliance with coding rules (layering, naming, patterns).
+- When making major design decisions, briefly state the rationale or trade-off.
+```
+
+## Rules/Guidelines
+
+1. ✅ **Don't change requirements** - Unclear → "Risks/Open questions"
+2. ✅ **Concrete decisions** - Endpoints, validation, error codes must be specific
+3. ✅ **Follow coding rules** - Layering, naming, patterns
+4. ✅ **Implementable** - Detailed enough for dev to implement immediately
+5. ✅ **Testable** - Clear test strategy
+
+## Usage Example
+
+## Usage Example
+
+```bash
+/devflow.2-gen-design /devflow-prompts/specs/FEAT-001/FEAT-001-requirement.md
+```
+
+## Next Steps
+
+After tech design is ready → run `/devflow.2-rev-design` to review