# AIDA Development Workflow

This file contains only:
- the mandatory workflow, and
- which MCP tools to use in each phase.

Do not duplicate detailed “how to” guidance here. Always rely on MCP tool descriptions and `get_rules(...)`.

## Editing this file (template-driven)

This file is generated by `aida-mcp init` from templates shipped in the `aida-mcp` package.

- **Do not hand-edit** `.cursor/rules/aida.mdc` or `.claude/CLAUDE.md` in a repo.
- To change the content, **update the templates in the `aida-mcp` package** and then rerun `aida-mcp init` in the repo.

## Post-init check

- After `aida-mcp init`, if MCP tools like `get_rules` or `validate` are missing, run `aida-mcp doctor`.

## Workflow (mandatory)

### 1) Get rules

- At the start of every task (and again on scope change), call `get_rules(query="...")`.
- Follow the rules returned by `get_rules` for the task.

### 2) Implement

- Make the requested change(s) following repository rules returned by `get_rules`.

### 3) Validate (blocking)

- If you changed code, you must validate before responding about code changes.
- Prefer the narrowest validation that is still correct (use `test_filter` when appropriate).
- Use the MCP validation tool `validate` (prefer this over raw `./gradlew` / `make`).
- If you changed `.proto` files, do not run proto regeneration manually; `validate` will run it when needed.
- If unsure what validation to run, call `get_rules(query="validation workflow")` and follow the returned guidance.

### 4) Commit / PR (if asked)

- Ask for the JIRA ticket if unknown.
- Before committing or creating a PR, call `get_rules(query="git")` and follow the returned guidance.
- For commit creation, use `aida-mcp commit` (do not use raw `git commit`).

## When to create/update rules

If any of these happen, propose updates to repo rules/config by following `get_rules(query="rules authoring")`:
- repeated friction (“how do I … in this repo?” keeps coming up)
- user dissatisfaction (“wrong”, “not what I meant”, “stop doing that”)
- recurring validation failures of the same kind
- large/risky cross-cutting changes

Before creating/updating files under `.aida/` (including `.aida/rules/**` and `.aida/*.yaml`), ask the user for explicit permission and proceed only after approval.

