Add mandatory development workflow to AGENTS.md
- Enforce Understand → Plan → Wait for Approval → Implement → Validate → Review. - Require agents to read code, load skills, and produce a plan before changing files. - Add explicit STOP after presenting the plan until user approval. - Define minimum validation commands and self-review checklist. - Allow trivial fixes to skip directly to implementation, but still require validation.
This commit is contained in:
@@ -15,6 +15,67 @@ Available project skills:
|
|||||||
|
|
||||||
If the requested change touches more than one skill, load all of them. If a task is ambiguous or conflicts with the local-only / privacy constraint, stop and consult the user before proceeding.
|
If the requested change touches more than one skill, load all of them. If a task is ambiguous or conflicts with the local-only / privacy constraint, stop and consult the user before proceeding.
|
||||||
|
|
||||||
|
## Mandatory Development Workflow
|
||||||
|
|
||||||
|
All non-trivial implementation tasks follow this workflow. Trivial tasks (e.g., a single typo fix or one-line import correction) may skip straight to implementation, but they still require validation.
|
||||||
|
|
||||||
|
### 1. Understand
|
||||||
|
|
||||||
|
Before changing anything:
|
||||||
|
|
||||||
|
- Read the relevant parts of the codebase.
|
||||||
|
- Load all applicable skills from `.agents/skills/`.
|
||||||
|
- Identify the schemas, modules, tests, and config that the change will touch.
|
||||||
|
- Confirm the goal and constraints with the user if anything is unclear.
|
||||||
|
|
||||||
|
**Do not modify files during this phase.**
|
||||||
|
|
||||||
|
### 2. Plan
|
||||||
|
|
||||||
|
Produce a concise implementation plan that includes:
|
||||||
|
|
||||||
|
- What files will be created, modified, deleted, or renamed.
|
||||||
|
- Which schemas or public interfaces change.
|
||||||
|
- How the change fits existing tests and what new tests are needed.
|
||||||
|
- Any risks, assumptions, or open questions.
|
||||||
|
|
||||||
|
### 3. Wait for Approval
|
||||||
|
|
||||||
|
**STOP after presenting the plan.**
|
||||||
|
|
||||||
|
Do not create, modify, delete, or rename files until the user explicitly approves the plan.
|
||||||
|
|
||||||
|
Questions and clarification are allowed during this phase.
|
||||||
|
|
||||||
|
### 4. Implement
|
||||||
|
|
||||||
|
Once the plan is approved:
|
||||||
|
|
||||||
|
- Make the smallest changes that satisfy the approved plan.
|
||||||
|
- Follow project conventions (schemas first, type hints, error handling, logging).
|
||||||
|
- If implementation reveals that the approved plan is materially wrong or incomplete, **stop and explain the discrepancy** rather than silently expanding scope.
|
||||||
|
|
||||||
|
### 5. Validate
|
||||||
|
|
||||||
|
Run appropriate tests and checks. At minimum:
|
||||||
|
|
||||||
|
- `python -m pytest tests/`
|
||||||
|
- `ruff check src tests`
|
||||||
|
- `mypy src/odoo_ocr --ignore-missing-imports --strict` (if feasible for the change)
|
||||||
|
|
||||||
|
Fix issues caused by the change. Report any pre-existing failures clearly.
|
||||||
|
|
||||||
|
### 6. Review
|
||||||
|
|
||||||
|
Before finishing, review your own changes:
|
||||||
|
|
||||||
|
- Does the code match the approved plan?
|
||||||
|
- Are there unintended changes or debug code left behind?
|
||||||
|
- Are tests meaningful and not just mocks of themselves?
|
||||||
|
- Would the next agent understand what you did?
|
||||||
|
|
||||||
|
Load the `review` skill and use its checklist for any non-trivial change.
|
||||||
|
|
||||||
## Project Goal
|
## Project Goal
|
||||||
|
|
||||||
Build a Python application that:
|
Build a Python application that:
|
||||||
|
|||||||
Reference in New Issue
Block a user