|
| 1 | +# AI Agent Workflow Rules |
| 2 | + |
| 3 | +Whenever you are given a task to modify, refactor, or create code, you MUST strictly follow this 2-step process. Do not skip steps. |
| 4 | + |
| 5 | +## STEP 1: Planning and Documentation |
| 6 | + |
| 7 | +1. Before writing or modifying any project code, create or update a file named `change.md` in the root directory. |
| 8 | +2. In `change.md`, clearly outline: |
| 9 | + - The goal of the task. |
| 10 | + - The files that will be modified or created. |
| 11 | + - A step-by-step technical plan of the exact changes you intend to make. |
| 12 | +3. **CRITICAL INSTRUCTION:** Once you have saved `change.md`, you must **STOP**. Do not write any code. Ask the user: *"I have outlined the plan in change.md. Please review it. Reply with 'APPROVED' to proceed, or let me know what needs to be changed."* |
| 13 | +4. Wait for the user's explicit approval. |
| 14 | + |
| 15 | +## STEP 2: Implementation |
| 16 | + |
| 17 | +1. ONLY after the user explicitly types "APPROVED" (or a clear affirmative), you may begin implementing the steps exactly as outlined in `change.md`. |
| 18 | +2. Do not deviate from the approved plan without asking for permission first. |
| 19 | +3. **Before completing implementation, follow the Review Checklist below**. |
| 20 | + |
| 21 | +### Review Checklist |
| 22 | + |
| 23 | +**IMPORTANT**: This checklist MUST be followed: |
| 24 | +- When implementing changes (after coding, before committing) |
| 25 | +- When performing standalone code reviews (when asked to review code without implementing) |
| 26 | + |
| 27 | +#### Documentation Review |
| 28 | + |
| 29 | +Check if changes require updates to `docs/` files: |
| 30 | +- New features, tasks, or commands |
| 31 | +- Modified behavior or configuration |
| 32 | +- New dependencies or build requirements |
| 33 | +- Changed workflows or processes |
| 34 | +- Update relevant documentation files before proceeding |
| 35 | +- If unsure whether docs need updating, ask the user |
| 36 | + |
| 37 | +#### Manifest Regeneration Review |
| 38 | + |
| 39 | +Check if changes require regenerating YAML manifests: |
| 40 | +- **NEVER hand-edit files in `release/`** (see [YAML Generation](yaml-generation.md)) |
| 41 | +- Run `make generate-yaml-tasks` if changes affect: |
| 42 | + - Files in `templates/` directory |
| 43 | + - Files in `configs/` (Ansible variable files) |
| 44 | + - Task parameters or behavior |
| 45 | + - RBAC requirements in task definitions |
| 46 | +- Run `make generate-pipelines` if changes affect: |
| 47 | + - Files in `templates-pipelines/` directory |
| 48 | + - Pipeline definitions or structure |
| 49 | +- Run `make test-yaml-consistency` to verify YAML is in sync |
| 50 | +- Commit any regenerated YAML files along with code changes |
| 51 | + |
| 52 | +#### Code Quality Review |
| 53 | + |
| 54 | +Verify code meets project standards: |
| 55 | +- Run `make lint` to check code formatting and style |
| 56 | +- Fix any linter issues with `make lint-fix` |
| 57 | +- Ensure all linter checks pass before committing |
| 58 | +- Run `make test` to verify unit tests still pass |
| 59 | +- Address any test failures before proceeding |
| 60 | + |
| 61 | +### After Implementation |
| 62 | + |
| 63 | +Once implementation and the review checklist are complete, **ask the user** if they would like to proceed with committing and pushing the changes to GitHub (STEP 3). Do not automatically proceed to STEP 3 without user confirmation. |
| 64 | + |
| 65 | +## STEP 3: Git Workflow |
| 66 | + |
| 67 | +After successfully implementing the changes: |
| 68 | + |
| 69 | +1. **Create a new branch** with a descriptive name: |
| 70 | + ```bash |
| 71 | + git checkout -b feature/descriptive-name |
| 72 | + # or |
| 73 | + git checkout -b fix/issue-description |
| 74 | + ``` |
| 75 | + |
| 76 | +2. **Commit changes** following the commit message guidelines: |
| 77 | + - **Format**: `type(scope): description` |
| 78 | + - **Types**: `feat`, `fix`, `docs`, `test`, `build`, `refactor` |
| 79 | + - **Subject line**: Imperative mood, max 72 chars, capitalized, no period |
| 80 | + - **Body**: Wrap at 72 chars, explain what and why |
| 81 | + - **DCO**: Always use `--signoff` |
| 82 | + |
| 83 | + Example: |
| 84 | + ```bash |
| 85 | + git add <files> |
| 86 | + git commit --signoff -m "feat(execute-in-vm): Add support for custom SSH timeout |
| 87 | +
|
| 88 | + Implements configurable SSH timeout parameter to handle slow VM boots. |
| 89 | + Default timeout remains 5 minutes for backwards compatibility." |
| 90 | + ``` |
| 91 | + |
| 92 | +3. **Push to origin**: |
| 93 | + ```bash |
| 94 | + git push origin feature/descriptive-name |
| 95 | + ``` |
| 96 | + |
| 97 | +4. **Inform the user** that the branch has been pushed and provide the branch name for PR creation. |
| 98 | + |
| 99 | +## Why This Process? |
| 100 | + |
| 101 | +- **Prevents mistakes**: Plan is reviewed before implementation |
| 102 | +- **Saves time**: Avoids implementing wrong solutions |
| 103 | +- **Builds trust**: User has full visibility and control |
| 104 | +- **Improves quality**: Thoughtful planning leads to better code |
| 105 | + |
| 106 | +## Example Workflow |
| 107 | + |
| 108 | +``` |
| 109 | +User: "Add a new Tekton task for disk snapshot" |
| 110 | +
|
| 111 | +AI: [Creates change.md with detailed plan] |
| 112 | +AI: "I have outlined the plan in change.md. Please review it. |
| 113 | + Reply with 'APPROVED' to proceed, or let me know what needs |
| 114 | + to be changed." |
| 115 | +
|
| 116 | +User: [Reviews change.md, suggests modifications] |
| 117 | +
|
| 118 | +AI: [Updates change.md based on feedback] |
| 119 | +
|
| 120 | +User: "APPROVED" |
| 121 | +
|
| 122 | +AI: [Implements the plan step by step] |
| 123 | +AI: [Creates branch, commits with DCO sign-off, pushes to origin] |
| 124 | +AI: "Changes have been pushed to branch 'feature/disk-snapshot-task'. |
| 125 | + You can now create a PR on GitHub." |
| 126 | +``` |
0 commit comments