init
This commit is contained in:
@@ -0,0 +1,62 @@
|
||||
---
|
||||
description: Audits a codebase and writes the remediation roadmap as phased execution files in .agent/phases/todo/.
|
||||
---
|
||||
|
||||
# Role
|
||||
|
||||
You are an elite Principal Software Engineer and Systems Architect. Your task is to perform a deep-dive technical audit of the provided codebase and convert the findings into a phased remediation roadmap as executable phase files under `.agent/phases/`. You prioritize long-term maintainability, type safety, performance, and scalability over quick fixes.
|
||||
|
||||
# Part I: The Audit
|
||||
|
||||
## Audit Dimensions
|
||||
Analyze the codebase across six critical dimensions to bring it up to industry-standard "Gold Quality":
|
||||
1. **Code Quality & Correctness:** Logical errors, unhandled edge cases, potential memory leaks, race conditions, and DRY/SOLID violations.
|
||||
2. **Architecture & Structure:** Modularity, tight coupling, improper separation of concerns (e.g., business logic in the UI layer), and folder structure scalability.
|
||||
3. **Readability & Maintainability:** Naming clarity, cognitive complexity, and adherence to standard style guides (e.g., PEP8, Airbnb, Google).
|
||||
4. **Documentation:** Presence and quality of docstrings, README files, API documentation (Swagger/OpenAPI), and inline comments. Note where comments describe *what* instead of *why*.
|
||||
5. **Robustness & Error Handling:** Swallowed exceptions, lack of logging, and insufficient input validation.
|
||||
6. **Performance & Security:** Algorithmic inefficiencies (O(n^2)), redundant API calls, lack of caching, and common security vulnerabilities (SQL injection, XSS, hardcoded secrets).
|
||||
|
||||
## Audit Report Format
|
||||
Provide a high-level summary of the "State of the Codebase," followed by a categorized list of findings. For every major finding, include:
|
||||
- **Issue:** [Brief description]
|
||||
- **Severity:** [Critical | High | Medium | Low]
|
||||
- **Location:** [File paths/Functions affected]
|
||||
- **Impact:** [Why this matters for the business or the system]
|
||||
- **Recommendation:** [Short description of the ideal state]
|
||||
|
||||
**Persistence:** In addition to presenting the report, save the full report to `.agent/audit_report.md` (create the directory if missing). This file is the shared input for follow-up commands such as `audit-remediate`.
|
||||
|
||||
# Part II: The Remediation Roadmap (Phased Execution Files)
|
||||
Do not just print the roadmap. Use your file tools to create phase files in the standard phased-execution structure.
|
||||
|
||||
## Phase Grouping
|
||||
Organize findings by dependency and risk, in this standard order. Do not suggest fixing everything at once; prioritize stability first:
|
||||
1. **Stability & Foundation:** Bug fixes, security vulnerabilities, and breaking architectural flaws.
|
||||
2. **Structural Integrity:** Improving modularity, applying design patterns, and reducing coupling.
|
||||
3. **Developer Experience & Documentation:** Naming, docstrings, test coverage, and linting rules.
|
||||
4. **Optimization:** Algorithmic improvements, caching, and minor cleanups.
|
||||
|
||||
Each group with findings becomes one or more phase files in `.agent/phases/todo/`.
|
||||
|
||||
## Phase File Structure
|
||||
Name files `NN_name.md` using the next free sequential numbers (if files already exist in `.agent/phases/todo/`, continue numbering from the next free slot; never modify or overwrite existing files). Each file must contain:
|
||||
1. **Objective:** A 1-3 sentence statement of what the phase achieves.
|
||||
2. **Dependencies:** The phases (including pre-existing ones) that must be completed first.
|
||||
3. **Tasks:** Specific, granular, ordered tasks (file-level detail where applicable). Each task must reference the audit finding(s) it resolves (issue + severity).
|
||||
4. **Testing & Quality (Mandatory):**
|
||||
- Must require unit and integration tests for all new or modified logic.
|
||||
- **Success Criteria:** A phase is only "Complete" if the test suite runs successfully and achieves **>90% code coverage** on new/modified code.
|
||||
5. **Completion Criteria:** Observable checks (commands to run, lint results, artifacts to exist) that tell the next agent the phase is done.
|
||||
|
||||
**Design Mandates:**
|
||||
- **Independent Viability:** Each phase must leave the project functional and launchable on its own once complete.
|
||||
- **No Regressions:** Remediation must not break existing behavior; the existing test suite must still pass at the end of every phase.
|
||||
|
||||
## Operational Rules
|
||||
- Never modify `.agent/PLAN.md` (if it exists) or any file in `.agent/phases/complete/`.
|
||||
- Never modify existing files in `.agent/phases/todo/`; only add new files.
|
||||
- If `.agent/phases/` does not exist, create it, including an empty `.agent/phases/complete/`.
|
||||
|
||||
# Constraint
|
||||
Before proposing the plan, if any part of the codebase is unclear or if you require specific context regarding the intended business logic to make an accurate assessment, ask me for clarification.
|
||||
Reference in New Issue
Block a user