devflow-prompts 1.0.0

package/bin/cli.js

@@ -0,0 +1,100 @@
+#!/usr/bin/env node
+
+const fs = require('fs');
+const path = require('path');
+
+const args = process.argv.slice(2);
+const command = args[0];
+const force = args.includes('--force');
+
+if (command !== 'init' && command !== 'publish') {
+  console.log('Usage: npx devflow-prompts init [--force]');
+  console.log('       npx devflow-prompts publish [--force]');
+  process.exit(1);
+}
+
+const sourceRoot = path.join(__dirname, '..');
+const targetRoot = path.join(process.cwd(), 'devflow-prompts');
+
+const itemsToCopy = ['flows', 'rules', 'scripts', 'templates', 'README.md', 'gen-chat.sh'];
+
+console.log(`\n🚀 Initializing DevFlow Prompts...`);
+console.log(`Source: ${sourceRoot}`);
+console.log(`Target: ${targetRoot}\n`);
+
+if (!fs.existsSync(targetRoot)) {
+  fs.mkdirSync(targetRoot, { recursive: true });
+}
+
+async function copyFile(src, dest) {
+  try {
+    const srcContent = fs.readFileSync(src);
+    
+    if (fs.existsSync(dest)) {
+      if (force) {
+        fs.writeFileSync(dest, srcContent);
+        console.log(`  [OVERWRITE] ${path.relative(process.cwd(), dest)}`);
+      } else {
+        const destContent = fs.readFileSync(dest);
+        if (srcContent.equals(destContent)) {
+             // Identical, do nothing or log verbose
+             // console.log(`  [SKIP] ${path.relative(process.cwd(), dest)} (Identical)`);
+        } else {
+          const newDest = dest + '.new';
+          fs.writeFileSync(newDest, srcContent);
+          console.log(`  [CONFLICT] ${path.relative(process.cwd(), dest)} exists with different content.`);
+          console.log(`      -> Created ${path.relative(process.cwd(), newDest)}`);
+        }
+      }
+    } else {
+      fs.writeFileSync(dest, srcContent);
+      console.log(`  [CREATE] ${path.relative(process.cwd(), dest)}`);
+    }
+  } catch (err) {
+    console.error(`  [ERROR] Failed to copy ${src}: ${err.message}`);
+  }
+}
+
+async function copyDir(src, dest) {
+  if (!fs.existsSync(dest)) {
+    fs.mkdirSync(dest, { recursive: true });
+  }
+  
+  const entries = fs.readdirSync(src, { withFileTypes: true });
+  
+  for (const entry of entries) {
+    const srcPath = path.join(src, entry.name);
+    const destPath = path.join(dest, entry.name);
+    
+    // Ignore node_modules and hidden files (except specific ones if needed)
+    if (entry.name === 'node_modules' || entry.name === '.git' || entry.name === 'package.json' || entry.name === 'bin') {
+        continue;
+    }
+
+    if (entry.isDirectory()) {
+      await copyDir(srcPath, destPath);
+    } else {
+      await copyFile(srcPath, destPath);
+    }
+  }
+}
+
+(async () => {
+    for (const item of itemsToCopy) {
+        const srcPath = path.join(sourceRoot, item);
+        const destPath = path.join(targetRoot, item);
+
+        if (!fs.existsSync(srcPath)) {
+            console.warn(`  [WARN] Source item not found: ${item}`);
+            continue;
+        }
+
+        const stats = fs.statSync(srcPath);
+        if (stats.isDirectory()) {
+            await copyDir(srcPath, destPath);
+        } else {
+            await copyFile(srcPath, destPath);
+        }
+    }
+    console.log(`\n✅ Done! Run 'cd devflow-prompts' to check the files.`);
+})();

package/flows/devflow.0-gen-rules.prompt.md

@@ -0,0 +1,335 @@
+---
+description: Initialize workflow rules for project (requirement, design, code, test)
+---
+
+# /devflow.0-gen-rules
+
+## Description
+Create workflow rules for all SDLC steps. Each step has 2 rules: gen-rule (for generation) and rev-rule (for review).
+
+**Steps covered:**
+- Step 1: Requirement (how to write & review requirements)
+- Step 2: Design (how to write & review technical designs)
+- Step 3: Code (how to write & review code)
+- Step 4: Test Plan (how to write & review test plans)
+- Step 5: Test Code (how to write & review test code)
+
+## Input Requirements
+
+**Input Type: File Path (Required)**
+- Provides path to a text file containing Step, Stack, Architecture, etc.
+- **File can be located anywhere** (not limited to `/devflow-prompts`)
+- Template file available at: `/devflow-prompts/templates/gen-rule-template.txt`
+- Format inside file:
+  ```text
+  Step: ...
+  Stack: ...
+  Architecture: ...
+  Team: ...
+  Constraints: ...
+  Language: ...
+  ```
+- AI will automatically read the file.
+
+## Input Validation
+
+- **Step**:
+  - Must be `1`, `2`, `3`, `4`, `5` (generates gen + rev)
+  - OR `all` (generates 10 files)
+  - OR specific suffix: `1-gen`, `1-rev`, `2-gen`, etc.
+- **Stack**: Required field, cannot be empty
+- **Architecture**: Required field, cannot be empty
+- **Language**:
+  - If specified, MUST be one of: `en`, `vi`, `ja`, `ko`.
+  - If invalid language provided -> Validation FAILS.
+
+**If validation fails**: Stop immediately and output error message.
+
+## Output Format
+
+### Output Location:
+- **Base directory**: `<repo_root>/devflow-prompts/rules/`
+- **Auto-creation**: Directory will be created automatically if it doesn't exist
+- **File handling**: Existing files will be overwritten. **Review carefully before running.**
+
+### Rules Structure:
+```
+/devflow-prompts/rules/
+├── devflow.1-gen-requirement.rule.md
+├── devflow.1-rev-requirement.rule.md
+├── devflow.2-gen-design.rule.md
+├── devflow.2-rev-design.rule.md
+├── devflow.3-gen-code.rule.md
+├── devflow.3-rev-code.rule.md
+├── devflow.4-gen-test-plan.rule.md
+├── devflow.4-rev-test-plan.rule.md
+├── devflow.5-gen-test-code.rule.md
+└── devflow.5-rev-test-code.rule.md
+```
+
+### Rule Content by Step:
+
+**Step 1 (Requirement):**
+- `devflow.1-gen-requirement.rule.md`: Guidelines for converting raw request → requirement document
+  - What to include, what to avoid
+  - Template structure requirements
+  - Acceptance criteria format
+  - Edge case documentation
+- `devflow.1-rev-requirement.rule.md`: Checklist for reviewing requirement documents
+  - Completeness checks
+  - Clarity verification
+  - Testability assessment
+  - Common mistakes to catch
+
+**Step 2 (Design):**
+- `devflow.2-gen-design.rule.md`: Guidelines for creating tech design from requirement
+  - Architecture principles (Clean Architecture, etc.)
+  - Security requirements
+  - API specification format
+  - Data model design rules
+- `devflow.2-rev-design.rule.md`: Checklist for reviewing tech design
+  - Architecture compliance
+  - Security verification
+  - API completeness
+  - Implementation feasibility
+
+**Step 3 (Code):**
+- `devflow.3-gen-code.rule.md`: Coding standards and conventions
+  - Backend/Frontend coding rules
+  - Layer separation
+  - Error handling patterns
+  - Security implementation
+- `devflow.3-rev-code.rule.md`: Code review checklist
+  - Code quality checks
+  - Security verification
+  - Performance considerations
+  - Test coverage requirements
+
+**Step 4 (Test Plan):**
+- `devflow.4-gen-test-plan.rule.md`: Guidelines for creating test plans
+  - Test level strategy (unit/integration/E2E)
+  - Coverage requirements
+  - Test case format
+  - Mock/stub guidelines
+- `devflow.4-rev-test-plan.rule.md`: Test plan review checklist
+  - Coverage verification
+  - Test case quality
+  - Edge case inclusion
+  - Feasibility assessment
+
+**Step 5 (Test Code):**
+- `devflow.5-gen-test-code.rule.md`: Test code writing standards
+  - Test structure conventions
+  - Assertion best practices
+  - Test data management
+  - Deterministic test requirements
+- `devflow.5-rev-test-code.rule.md`: Test code review checklist
+  - Test quality verification
+  - Coverage confirmation
+  - Reliability checks
+  - Maintainability assessment
+
+## Prompt
+
+```
+You are my engineering standards writer.
+
+LANGUAGE SETTING:
+- Default: English (en)
+- User can override by adding "Language: {vi|ja|ko}" in input
+- Write in the specified language
+
+INPUT:
+<<<
+{USER INPUT HERE - Can be a file path OR direct input with Step, Stack, Architecture, etc.}
+>>>
+
+INSTRUCTIONS:
+
+1. **Read Input File**:
+   - The user will provide a file path.
+   - USE `view_file` tool to read its content.
+   - **Fallback**: If the tool is unavailable or fails, ask the user to paste the file content directly.
+   - File paths can be anywhere in the filesystem, not limited to `/devflow-prompts`.
+
+2. **Parse Information**:
+   - Extract **Step** (required): Which step/rule to generate
+   - Extract **Stack** (required): Technology stack
+   - Extract **Architecture** (required): Architecture pattern
+   - Extract **Team** (optional): Team context
+   - Extract **Constraints** (optional): Project constraints
+   - Extract **Language** (optional): Output language (default: en)
+
+TASK:
+Generate gen-rule and rev-rule files based on STEP parameter:
+- If Step = `1`, `2`,... → Generate BOTH gen-rule and rev-rule for that step.
+- If Step = `all` → Generate ALL 10 files.
+- If Step = `X-gen` → Generate ONLY `devflow.X-gen-....rule.md`.
+- If Step = `X-rev` → Generate ONLY `devflow.X-rev-....rule.md`.
+
+Follow the 9-section template structure defined below.
+
+STYLE RULES:
+- Use imperative tone (e.g., "Do this", not "You should do this")
+- Use bullet points, not paragraphs, for rules
+- Avoid marketing language; be technical and precise
+
+COMMON REQUIREMENTS (apply to ALL steps):
+
+**Every gen-rule file MUST include:**
+1. Principles: What makes a good {artifact} (MUST/SHOULD/SHOULD NOT)
+2. Specific guidelines and conventions tailored to Stack & Architecture
+3. Examples (Good vs Bad) with real code/content
+4. Common mistakes to avoid
+5. **CRITICAL**: In Section 3 (Project Structure), you MUST document the explicit paths to key directories (e.g., `src/`, `app/`, `tests/`). This allows future AI steps to find files automatically.
+6. Follow the template EXACTLY: Principles → Architecture & Boundaries → Project Structure → 
+   Implementation Rules → Error Handling & Logging → Testing Rules → Security → 
+   PR Checklist → Examples
+
+**Every rev-rule file MUST include:**
+1. Completeness checklist (all sections present?)
+2. Quality standards (specific, actionable criteria)
+3. Common issues to look for
+4. Review questions to ask
+5. Sign-off criteria (when to approve/reject)
+
+**General rules:**
+- Make rules practical, testable, and enforceable in PR review
+- Tailor to the specified Stack and Architecture
+- Use concrete examples, not abstract theory
+- **Template Consistency**: Keep all 9 sections. If a section is not applicable, explicitly write "Not applicable for this step." (DO NOT remove the header).
+
+STEP-SPECIFIC FOCUS (only the delta for each step):
+
+**Step 1 (Requirement) - Files: devflow.1-gen-requirement.rule.md, devflow.1-rev-requirement.rule.md**
+- gen: Acceptance criteria format, edge case documentation, error scenarios, what to avoid (inventing requirements, vague criteria)
+- rev: Testability assessment, ambiguity checks, contradiction detection
+
+**Step 2 (Design) - Files: devflow.2-gen-design.rule.md, devflow.2-rev-design.rule.md**
+- gen: Architecture principles (based on specified approach), security patterns, API specs (endpoints, request/response, errors), data model (migrations, indexes), observability (logs, metrics, tracing)
+- rev: Architecture compliance, security verification, API completeness, data model safety, implementation feasibility
+
+**Step 3 (Code) - Files: devflow.3-gen-code.rule.md, devflow.3-rev-code.rule.md**
+- gen: Layer separation (domain/application/infrastructure), naming conventions (classes, functions, variables), error handling patterns, security implementation, performance best practices
+- rev: Code quality (readability, maintainability), architecture compliance, security vulnerabilities, performance considerations, test coverage, code smells
+
+**Step 4 (Test Plan) - Files: devflow.4-gen-test-plan.rule.md, devflow.4-rev-test-plan.rule.md**
+- gen: Test strategy (unit/integration/E2E), coverage requirements, test case format, mock/stub guidelines, test data requirements
+- rev: Coverage verification (all use cases covered?), test case quality, edge case inclusion, feasibility
+
+**Step 5 (Test Code) - Files: devflow.5-gen-test-code.rule.md, devflow.5-rev-test-code.rule.md**
+- gen: Test structure (AAA pattern), assertion best practices, test data management, deterministic tests (no flaky tests), mocking guidelines
+- rev: Test quality, coverage confirmation, reliability (no flaky tests), maintainability
+
+**Step 'all':**
+- Generate ALL 10 files (5 steps × 2 rules each)
+
+OUTPUT FORMAT:
+- Return file contents in separate sections with exact filenames as headings
+- Each file should be production-ready and immediately usable
+
+STRICT OUTPUT RULE:
+- Output ONLY file contents
+- No intro/outro text
+- No explanations
+- No summaries
+- No notes
+
+SELF-CHECK BEFORE OUTPUT:
+1. Verify all required files for the Step are generated.
+2. Verify filenames match exactly (e.g., `devflow.1-gen-requirement.rule.md`).
+3. Verify all 9 sections are present in every file.
+```
+
+## Template for each *-rule.md
+
+```markdown
+# {Rule Name}
+
+## 1) Principles
+- MUST:
+- SHOULD:
+- SHOULD NOT:
+
+## 2) Architecture & Boundaries
+- Allowed dependencies:
+- Forbidden dependencies:
+
+## 3) Project Structure
+- **Root Directories** (CRITICAL: Must specify absolute or relative paths from repo root):
+- Folders structure:
+- Naming conventions:
+
+## 4) Implementation Rules
+- Patterns:
+- Anti-patterns:
+
+## 5) Error Handling & Logging
+- Rules:
+- Examples:
+
+## 6) Testing Rules
+- Unit:
+- Integration:
+- E2E:
+
+## 7) Security (if applicable)
+- Rules:
+- Examples:
+
+## 8) PR Checklist
+- [ ] ...
+- [ ] ...
+
+## 9) Examples
+### Good
+```txt
+...
+```
+
+### Bad
+```txt
+...
+```
+```
+
+## Rules/Guidelines
+1. ✅ Rules must be **practical** - can be applied immediately
+2. ✅ Rules must be **testable** - can be checked in PR/CI
+3. ✅ Rules must be **enforceable** - clear, not ambiguous
+4. ❌ Avoid overly idealistic rules that are impractical
+5. ✅ Each rule must have Good vs Bad examples
+
+## Usage Example
+
+### Example 1: Generate all rules
+```bash
+/devflow.0-gen-rules /path/to/my-project-rules.txt
+# → Generates all 10 files in /devflow-prompts/rules/ (step1-5, each with gen + rev)
+```
+
+⚠️ **Warning**: This will overwrite existing rule files. Commit your changes first!
+
+### Example 2: Generate only step 1 rules (Requirement)
+```bash
+# In your input file: Step: 1
+/devflow.0-gen-rules /path/to/step1-rules.txt
+# → Generates: devflow.1-gen-requirement.rule.md, devflow.1-rev-requirement.rule.md
+```
+
+### Example 3: Generate step 2 rules (Design)
+```bash
+# In your input file: Step: 2
+/devflow.0-gen-rules /path/to/step2-rules.txt
+# → Generates: devflow.2-gen-design.rule.md, devflow.2-rev-design.rule.md
+```
+
+### Example 4: Generate step 3 rules (Code) in Vietnamese
+```bash
+# In your input file: Language: vi
+/devflow.0-gen-rules /path/to/step3-vi-rules.txt
+# → Generates: devflow.3-gen-code.rule.md, devflow.3-rev-code.rule.md (in Vietnamese)
+```
+
+## Next Steps
+After generating workflow rules → run `/devflow.0-rev-rules` to review and improve

package/flows/devflow.0-rev-rules.prompt.md

@@ -0,0 +1,156 @@
+---
+description: Review and improve workflow rules for consistency
+---
+
+# /devflow.0-rev-rules
+
+## Description
+Review and improve workflow rules for all SDLC steps. Detect contradictions, gaps, and suggest improvements.
+
+**Steps covered:**
+- Step 1: Requirement rules (gen + rev)
+- Step 2: Design rules (gen + rev)
+- Step 3: Code rules (gen + rev)
+- Step 4: Test Plan rules (gen + rev)
+- Step 5: Test Code rules (gen + rev)
+
+## Input Requirements
+
+**Input Type: File Path OR Directory Path (Required)**
+- **File Path**: Reviews that specific rule file.
+- **Directory Path**: Reviews ALL rule files (`*.rule.md`) in that directory.
+- **Files/Dirs can be located anywhere** (not limited to `/devflow-prompts`)
+- Example File: `/path/to/devflow.1-gen-requirement.rule.md`
+- Example Dir: `/path/to/devflow-prompts/rules/`
+- AI will automatically read the files
+
+## Input Validation
+
+- **Input Path**: Must be a valid file or directory path.
+- **Rule Content**:
+  - If Directory: Must contain valid `.rule.md` files.
+  - If File: Must be a valid `.rule.md` file (or text file with rule definitions).
+- **Step Identification**: AI must be able to infer the Step ID (1-5) from the filename (e.g., `devflow.1-...`) or content.
+
+**If validation fails**: Stop immediately and output error message.
+
+## Output Format
+1. **Issues list** (grouped by priority P0/P1/P2)
+2. **Patched versions** of the files (full updated content)
+
+## Prompt
+
+```
+You are a senior staff engineer reviewing workflow rules.
+
+INPUT:
+<<<
+{USER INPUT HERE - Can be file paths OR rule file contents}
+>>>
+
+INSTRUCTIONS:
+
+1. **Read Input**:
+   - IF input is a **Directory**:
+     - USE `list_dir` or `find_by_name` to find all files ending in `.rule.md`.
+     - **Fallback**: If directory listing tools are unavailable, ask user to provide file paths explicitly.
+     - USE `view_file` to read ALL found rule files.
+   - IF input is a **File**:
+     - USE `view_file` to read the file directly.
+   - IF input is NOT a path, ask user to provide a path.
+
+2. **Identify Step**:
+   - Determine which step(s) to review from filenames or user specification
+   - Step: {STEP NUMBER - 1, 2, 3, 4, 5, or 'all'}
+
+
+
+REVIEW TASKS:
+1. **Detect contradictions**: Find conflicts between gen-rule and rev-rule
+2. **Identify missing enforcement**: What can be checked in PR/CI?
+3. **Add concrete examples**: Replace vague rules with specific examples
+4. **Ensure realistic**: Rules must be practical, not overly idealistic
+5. **Check rev-rule checklists**: Must be comprehensive and actionable
+6. **Verify gen-rule guidelines**: Must be clear and implementable
+7. **Cross-step consistency**: Ensure rules don't conflict across steps
+
+INTENT PRESERVATION RULE:
+- Do not change the original intent of rules unless resolving a P0 contradiction.
+
+OUTPUT FORMAT:
+1. **Issues List** (grouped by priority):
+   - P0 (Critical - Must fix): Contradictions, missing critical rules
+   - P1 (Important - Should fix): Missing enforcement, vague rules
+   - P2 (Nice-to-have): Formatting, additional examples
+
+2. **Patched Files**: Full updated content for each file
+   - Include all fixes from P0 and P1
+   - Mark changes with brief inline comments ONLY for non-obvious fixes
+   - Ensure production-ready quality
+
+STRICT OUTPUT RULE:
+- Output ONLY:
+  1) Issues List
+  2) Patched Files
+- No explanations outside these sections
+- No summaries
+- No meta commentary
+```
+
+## Rules/Guidelines
+1. ✅ Detect **contradictions** - conflicts between rules
+2. ✅ Identify **enforcement points** - what can be auto-checked
+3. ✅ Add **concrete examples** - for vague rules
+4. ✅ Ensure **realistic** - rules must be practical, not overly idealistic
+5. ✅ Prioritize fixes: P0 (critical) → P1 (important) → P2 (nice-to-have)
+
+## Priority Levels
+
+### P0 (Critical - Must fix)
+- Contradictions between rules
+- Missing critical security/safety rules
+- Rules that cannot be enforced
+
+### P1 (Important - Should fix)
+- Missing enforcement points
+- Vague rules needing examples
+- Incomplete checklists
+
+### P2 (Nice-to-have - Can fix later)
+- Formatting improvements
+- Additional examples
+- Documentation enhancements
+
+## Usage Example
+
+### Option 1: Review Single File
+```bash
+/devflow.0-rev-rules /path/to/devflow.1-gen-requirement.rule.md
+```
+
+### Option 2: Review Directory (All Rules)
+```bash
+/devflow.0-rev-rules /path/to/devflow-prompts/rules/
+# → Finds and reviews all *.rule.md files in that folder
+```
+
+## Common Issues to Look For
+
+### Contradictions
+- Architecture rule requires X but BE rule forbids X
+- Test rule conflicts with Implementation rule
+
+### Missing Enforcement
+- Rule says "should be clean" but doesn't define "clean"
+- No checklist to verify rule is followed
+
+### Vague Rules
+- "Code should be maintainable" → need to define metrics
+- "Use appropriate patterns" → need to list specific patterns
+
+### Unrealistic Rules
+- "100% test coverage" → may not be practical
+- "Never use if-else" → too extreme
+
+## Next Steps
+After reviewing and improving workflow rules → Start using them with `/devflow.1-gen-requirement`