一键导入
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 页面并帮你完成安装。
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.
基于 SOC 职业分类
| 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 |