Menu
Write Architecture Decision Records when making significant technical choices. Use when selecting tools, patterns, frameworks, or making structural changes that future developers need to understand.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Dispatch Codex to review all unreviewed repository work, then verify its correlated findings ticket or clean result. Use when requesting an independent Codex review, auditing all changes, checking work since the last review, or waiting for Codex findings. Trigger: dispatch codex review, independent review, review all changes, check codex findings, run review agent.
Always-on: when a project has tickets, work the frontier (first unblocked open ticket), mark done, update plan status.
Incremental and full-history repository review with resumable adoption batches. Use when reviewing new work, initializing review tracking, reviewing all work to date, resuming historical review, inspecting unreviewed commits, or reviewing changed tickets. Trigger: review new work, adopt repository, review all history, resume review, review marker, unreviewed commits.
End-of-session handoff that captures current state for the next session. Use when ending a work session, switching context, or before a long break.
Consolidate project artifacts — promote scratch to memory, deduplicate memory, process decisions, organize scripts, update steering/skills accuracy. Use periodically or when the project feels cluttered.
Run and interpret crew-research evals — run.sh flags, scores.jsonl fields, activation TPR/FPR verdicts, resuming interrupted runs. Use when running evals, reading eval results, diagnosing a failing definition, or resuming a dead run. Trigger: run the evals, eval results, scores.jsonl, activation test, TPR, delta threshold, resume the run, skip-completed, known gap.
| name | adr-authoring |
| description | Write Architecture Decision Records when making significant technical choices. Use when selecting tools, patterns, frameworks, or making structural changes that future developers need to understand. |
| metadata | {"type":"process","invocation":"both","practice":null} |
Record decisions so future-you (and future-teammates) know WHY, not just WHAT.
Do NOT write ADRs for: trivial choices, temporary experiments, or decisions that are easily reversed.
If archwright skills are available and the decision resolves a named force tension, also consider archwright-formalize — a pattern with a mechanical check outlives an ADR's prose.
# ADR-NNNN: [Decision Title]
**Status:** proposed | accepted | deprecated | superseded by ADR-XXXX
**Date:** YYYY-MM-DD
**Deciders:** [who was involved]
## Context
What is the issue? What forces are at play? Why does this decision need to be made now?
## Decision
What did we decide? State it clearly in one sentence, then elaborate.
## Consequences
### Positive
- [What becomes easier or better]
### Negative
- [What becomes harder or what we give up]
### Neutral
- [Side effects that aren't clearly good or bad]
## Alternatives Considered
### [Alternative 1]
- Pros: ...
- Cons: ...
- Why rejected: ...
## References
- [Research artifact that informed this] (link to docs/research/ if applicable)
- [Related ADRs]
.memory/adr/NNNN-slug.md.memory/CONTEXT.md if discoverability mattersIf a research artifact (grill session, research report, spike result) informed this decision, link it:
## References
- [Research: JWT vs Session Auth](../grill/auth/Q03-jwt-vs-session.md) — informed this decision
The research artifact should back-link: Consumed by: ADR-0003