ワンクリックで
adr
Keep track of architectural decisions in a structured format using Architecture Decision Records (ADRs).
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Keep track of architectural decisions in a structured format using Architecture Decision Records (ADRs).
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when designing, implementing, reviewing, debugging, or documenting Chatto event-sourced domain behavior, including EVT subjects, aggregate boundaries, Services, projections, optimistic concurrency control, read-your-writes, live/reconnect delivery, replay compatibility, migration safety, and rollback/deployment implications.
Create or update Chatto docs website release pages by comparing release-please state, tags, commits, changelog entries, and PRs
Run a full review of all Architecture Decision Records for implementation drift, contradictions, stale decisions, missing supersession notes, weak rationale, and missing cross-references. Use when the user asks for an ADR review, ADR audit, stale ADR check, architecture decision consistency check, or wants to verify ADRs against the current codebase, feature/design records, architecture docs, glossary, or public API state.
Update docs/ARCHITECTURE.md to reflect the current state of the codebase by examining code and documentation.
Run a documentation-focused maintenance checkup of the Chatto codebase. Fans out to /fdr, /adr, and /chatto-architecture, then compiles a single consolidated report. Always propose-only — no changes applied without explicit user approval. At the end, points the human at other maintenance skills (/update-project-dependencies, /chatto-security-review) they may want to run themselves.
Production debugging tools for NATS streams, KV buckets, and protobuf events. Covers nats CLI commands, stream inspection, protobuf decoding, and message iteration.
| name | adr |
| description | Keep track of architectural decisions in a structured format using Architecture Decision Records (ADRs). |
Manage architectural decisions as structured markdown documents in docs/adr/.
docs/adr/
├── INDEX.md # Index with TOC (read this first)
├── ADR-001-nats-jetstream-instead-of-kafka.md # Individual ADR
├── ADR-002-embedded-nats-server.md
└── ...
docs/adr/INDEX.md to see the current index of all ADRsdocs/adr/INDEX.md to determine the next available numberdocs/adr/INDEX.md to add the new entry to the TOCdocs/fdr/INDEX.md for features whose design now relates to this ADR. Update those FDRs to cite the new ADR in their Related → ADRs line. (ADRs themselves don't carry a Related FDRs section — citations flow FDR → ADR only.)docs/adr/INDEX.md to find the ADRdocs/adr/INDEX.md if the title changedADR-{NNN}-{kebab-case-slug}.md
NNN: Zero-padded three-digit number, sequential# ADR-{NNN}: {Title}
**Date:** {YYYY-MM-DD}
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?
Each entry in the TOC should be a markdown table row:
| # | Decision | Date |
|---|----------|------|
| [ADR-001](ADR-001-slug.md) | Title of the decision | 2026-03-01 |