---
model: opus
---

# /tas-adr $ARGUMENTS

Role: SE - Software Engineer
Create or update Architecture Decision Record.

## Actions
1. Need context from .tas/templates/ADR.md
2. Scan docs/adr/ to identify existing ADRs
3. Determine mode based on $ARGUMENTS:

### CREATE mode ($ARGUMENTS is new title, e.g., "Use CQRS for Order Service"):
4. Determine next sequence number (ADR-001, ADR-002...)
5. If docs/sad.md exists, need context from SAD to ensure ADR consistency
6. Create file docs/adr/ADR-{NNN}-{slug}.md
7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add entry to `adrs`.

### UPDATE mode ($ARGUMENTS is ADR ID, e.g., "ADR-001"):
4. Need context from current ADR file
5. Ask user what needs changing (update status, add consequences, supersede...)
6. Update file, add changelog
7. If supersede: update old ADR status to "Superseded by ADR-{NNN}"
8. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `adrs.{ADR_ID}.status`.

## Principles
- ADR must have: Context, Decision, Rationale, Consequences, Alternatives Considered
- Status: Proposed | Accepted | Deprecated | Superseded
- Each ADR is independent, self-contained with enough context to understand
- Link to related ADRs if any (Supersedes, Related to)
- Mermaid diagram rules: :::mermaid wrapper, no () in node labels; for line breaks in a label use `<br />`, not `\n`

## Final Step — Token Log

Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working ADR file.