|
1 | 1 | { |
2 | | - "version": 14, |
| 2 | + "version": 2, |
3 | 3 | "ignore_patterns": [ |
4 | 4 | ".dump_config.json", |
5 | 5 | ".git", |
|
21 | 21 | ], |
22 | 22 | "profiles": { |
23 | 23 | "readme": { |
24 | | - "description": "Generate or Update README.md based on actual code logic", |
| 24 | + "description": "Generate a professional, architect-level README.md for the current project", |
25 | 25 | "pre": [ |
26 | | - "Act as a Senior Technical Writer. Analyze the codebase structure and logic to write a comprehensive README.md.", |
| 26 | + "Act as a Senior Technical Writer and System Architect.", |
| 27 | + "Your task is to analyze the provided codebase and generate a high-impact, professional README.md that captures both the 'How' and the 'Why' of the project.", |
27 | 28 | "", |
28 | | - "Your goal is to accurately document:", |
29 | | - "1. The Project Title & Description (One-liner).", |
30 | | - "2. Key Features (Derived from actual function/class capabilities).", |
31 | | - "3. Installation Instructions (Detect requirements.txt, pyproject.toml, etc).", |
32 | | - "4. Usage Examples (Based on CLI arguments or main entry points).", |
33 | | - "5. Configuration Options (Explain .dump_config.json structure).", |
| 29 | + "CRITICAL PHILOSOPHY:", |
| 30 | + "A README is not just a CLI reference; it is the project's manifesto. Do NOT sacrifice the narrative 'Why' or the 'Workflow' sections for brevity. If the code implements a specific way of working (e.g., PLAN.md, spec-driven development), that must be the centerpiece of the documentation.", |
34 | 31 | "", |
35 | | - "Do not hallucinate features. Only document what is present in the code." |
| 32 | + "ANALYSIS GUIDELINES:", |
| 33 | + "1. **Architecture & Philosophy**: Identify the project's core design pattern. If it uses a structured input/output flow (e.g., 'Sandwich Architecture'), explain WHY this exists (e.g., grounding LLMs, preventing hallucinations).", |
| 34 | + "2. **Technical Features**: Document advanced implementations found in the code:", |
| 35 | + " - Smart content handling (truncation of large files, binary detection, specific encoding support).", |
| 36 | + " - Environment awareness (Git integration, terminal-specific escape sequences like OSC52, or remote-work optimizations).", |
| 37 | + " - Diagnostic integration (ingesting external tool/linter output).", |
| 38 | + "3. **The 'Spec-Driven' Workflow**: Analyze CLI flags like --new-plan, --architect, or logic handling PLAN.md. Document the intended iterative development loop (Dump -> Discuss -> Plan -> Implement).", |
| 39 | + "4. **Configuration**: Explain the .dump_config.json schema, versioning, and how users can customize profiles.", |
| 40 | + "", |
| 41 | + "README STRUCTURE:", |
| 42 | + "- **Identity**: Project name and a high-impact one-liner.", |
| 43 | + "- **The Philosophy**: Explain the logical flow (e.g., The Sandwich) and the problem it solves.", |
| 44 | + "- **The Workflow**: A prominent, step-by-step guide on the intended project development lifecycle using the tool's specific features (like PLAN.md syncing).", |
| 45 | + "- **Feature Highlights**: A list of technically-backed features.", |
| 46 | + "- **Installation & Requirements**: Detect dependencies from setup files.", |
| 47 | + "- **Usage & CLI Reference**: A clean table or list of commands.", |
| 48 | + "", |
| 49 | + "TONE & STYLE:", |
| 50 | + "- Tone: Happy, developer-centric, and authoritative.", |
| 51 | + "- Style: Use structured Markdown, tables for references, and syntax-highlighted code blocks.", |
| 52 | + "- Accuracy: Only document what is present in the code. Do not invent capabilities." |
36 | 53 | ], |
37 | | - "post": "Output the result in raw Markdown format suitable for direct copy-pasting into README.md." |
| 54 | + "post": "Output the result in raw Markdown format. Ensure the 'Workflow' and 'Philosophy' sections are the most detailed parts of the document." |
38 | 55 | }, |
39 | 56 | "cleanup": { |
40 | | - "description": "Clean code: formatting, docstrings, unused imports", |
| 57 | + "description": "Clean code: formatting, docstrings, unused imports (Runs ruff & mypy)", |
| 58 | + "run_commands": [ |
| 59 | + "ruff check . --output-format=full", |
| 60 | + "mypy ." |
| 61 | + ], |
41 | 62 | "pre": [ |
42 | | - "Act as a Senior Python Developer and Code Reviewer. Your task is to perform a 'Spring Cleaning' on the codebase.", |
| 63 | + "Act as a Senior Python Developer and Code Reviewer.", |
| 64 | + "Your task is to perform a 'Spring Cleaning' on the codebase.", |
43 | 65 | "", |
44 | | - "Your goal is strict technical correctness, NOT subjective preference.", |
45 | | - "1. Remove unused imports and dead code (commented-out blocks).", |
46 | | - "2. Remove trivial comments (e.g., '# increments i').", |
47 | | - "3. Fix objective PEP 8 layout violations (indentation, spacing).", |
48 | | - "4. Add MISSING docstrings. Do NOT rewrite existing docstrings unless they are factually incorrect.", |
| 66 | + "INPUT DATA:", |
| 67 | + "1. The source code in <files>.", |
| 68 | + "2. The Linter Reports in <execution> (Ruff and Mypy).", |
49 | 69 | "", |
50 | | - "CRITICAL: Be conservative. If a file is already clean, do NOT make trivial changes just to generate a diff. If no objective errors exist, state 'No changes needed'." |
| 70 | + "HANDLING MISSING TOOLS:", |
| 71 | + "If the <execution> log shows 'command not found' or similar execution errors, IGNORE the missing tool and proceed with a manual review based on standard Python best practices.", |
| 72 | + "", |
| 73 | + "PRIORITIES:", |
| 74 | + "1. **Linter Fixes**: You MUST fix every error reported in the <execution> tag. If Ruff complains about imports, remove them. If Mypy complains about types, fix the annotation.", |
| 75 | + "2. **Standard Cleanup**: Even if no linter errors exist, look for:", |
| 76 | + " - Dead code (commented-out blocks).", |
| 77 | + " - Trivial comments (e.g., '# increments i').", |
| 78 | + " - MISSING docstrings (add them if missing).", |
| 79 | + "", |
| 80 | + "CRITICAL: Be conservative. If a file is clean and passes linters, state 'No changes needed'." |
51 | 81 | ], |
52 | | - "post": "Provide the changes in unified diff format for each file. If a file requires no changes, state 'No changes needed for [filename]'. Summarize the number of docstrings added and PEP 8 violations fixed per file. Format the output as a developer specification in Markdown with clear sections for each file." |
| 82 | + "post": "Provide the changes in unified diff format or full file rewrites where necessary. Explicitly mention which Linter errors were resolved." |
53 | 83 | }, |
54 | 84 | "optimize": { |
55 | 85 | "description": "Identify bottlenecks and suggest performance improvements", |
|
116 | 146 | "3. If the current implementation is simple, effective, and maintainable, explicitly state 'No architectural changes needed'." |
117 | 147 | ], |
118 | 148 | "post": "Provide a list of recommended refactors, ranked by impact (High/Medium/Low). Include specific code snippets or patterns for the most critical changes." |
| 149 | + }, |
| 150 | + "coverage": { |
| 151 | + "description": "Run coverage report and plan tests for missing lines", |
| 152 | + "run_commands": [ |
| 153 | + "pytest --cov=src/dumpcode --cov-report=term-missing" |
| 154 | + ], |
| 155 | + "pre": [ |
| 156 | + "Act as a Senior QA Engineer.", |
| 157 | + "Review the codebase and the <execution> report.", |
| 158 | + "", |
| 159 | + "GOAL: Create a plan to reach >95% coverage.", |
| 160 | + "1. Analyze lines marked 'Missing' in the report.", |
| 161 | + "2. Determine which missing lines are critical logic vs. trivial boilerplate.", |
| 162 | + "3. If coverage is already high (>95%) and no critical logic is missing, DO NOT generate a plan.", |
| 163 | + "4. If gaps exist, outline exactly which tests need to be written." |
| 164 | + ], |
| 165 | + "post": [ |
| 166 | + "If the project is healthy (High Coverage), output ONLY: **\u2705 Coverage is healthy. No actions needed.**", |
| 167 | + "", |
| 168 | + "Otherwise, output a file named `COVERAGE_PLAN.md` containing:", |
| 169 | + "# Coverage Improvement Plan", |
| 170 | + "## Missing Critical Paths", |
| 171 | + "- `file.py`: Lines X-Y (Description of logic)", |
| 172 | + "", |
| 173 | + "## Proposed Tests", |
| 174 | + "- [ ] `test_new_feature`: [Description of what to test]" |
| 175 | + ] |
| 176 | + }, |
| 177 | + "test-fixer": { |
| 178 | + "description": "Run tests (verbose) and plan fixes for failures", |
| 179 | + "run_commands": [ |
| 180 | + "pytest -v" |
| 181 | + ], |
| 182 | + "pre": [ |
| 183 | + "Act as a CI/CD Reliability Engineer.", |
| 184 | + "Analyze the <execution> report for failures and stability issues.", |
| 185 | + "", |
| 186 | + "PRIORITY:", |
| 187 | + "1. FAILURES: Any non-zero exit code or 'FAILED' tests.", |
| 188 | + "2. ERRORS: Any runtime errors in the log.", |
| 189 | + "", |
| 190 | + "STOPPING CONDITION:", |
| 191 | + "If the Exit Code is 0 and all tests passed, DO NOT invent work. Output: **\u2705 All tests passed. System is stable.**" |
| 192 | + ], |
| 193 | + "post": [ |
| 194 | + "If tests failed, output a file named `FIX_PLAN.md` containing:", |
| 195 | + "# Test Repair Plan", |
| 196 | + "## Diagnosis", |
| 197 | + "- **Failure**: `test_name`", |
| 198 | + "- **Error**: [Brief error content]", |
| 199 | + "- **Root Cause**: [Analysis based on code + log]", |
| 200 | + "", |
| 201 | + "## Action Items", |
| 202 | + "1. [Step-by-step fix instructions]", |
| 203 | + "", |
| 204 | + "## Verification", |
| 205 | + "- Command to verify the fix" |
| 206 | + ] |
119 | 207 | } |
120 | 208 | }, |
121 | 209 | "use_xml": true |
|
0 commit comments