c3f43d8b61
- Add 60 new agents across all 10 categories (75 -> 135) - Add 95 new plugins with command files (25 -> 120) - Update all agents to use model: opus - Update README with complete plugin/agent tables - Update marketplace.json with all 120 plugins
1.4 KiB
1.4 KiB
Write an Architecture Decision Record documenting a significant technical decision.
Steps
- Ask for or infer the decision topic from the argument (e.g., "use PostgreSQL over MongoDB").
- Scan the codebase for existing ADRs in
docs/adr/,docs/decisions/, oradr/directories. - Determine the next ADR number by counting existing records.
- Research the current codebase to gather context:
- What technologies are currently used.
- What constraints exist (team size, performance requirements, existing integrations).
- Draft the ADR with all required sections.
- Create the file as
docs/adr/NNNN-<slug>.md. - If a
docs/adr/README.mdindex exists, add an entry for the new ADR.
Format
# ADR-NNNN: <Title>
## Status
Proposed | Accepted | Deprecated | Superseded by ADR-XXXX
## Context
What is the issue that we are seeing that motivates this decision?
## Decision
What is the change that we are proposing and/or doing?
## Consequences
What becomes easier or harder as a result of this decision?
### Positive
- Benefit 1
### Negative
- Tradeoff 1
### Risks
- Risk 1 with mitigation strategy
Rules
- ADRs are immutable once accepted; create a new ADR to supersede an old one.
- Keep the context section factual and free of opinion.
- List at least one positive, one negative, and one risk consequence.
- Use the project's existing ADR format if one already exists.
- Date the ADR with the current date in the status section.