メニュー
Maintains Architectural Decision Records (ADRs) for this project. Creates, updates, lists, and supersedes ADRs in the /adr/ directory.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Shared reference knowledge base for @zeix/cause-effect agent skills. Contains common reference files used by multiple skills to avoid duplication.
Expert guidance for using the @zeix/cause-effect reactive signals library in any project. Use when implementing reactive patterns, debugging unexpected behavior, or answering questions about the public API, signal types, or design decisions. Works in any project that depends on @zeix/cause-effect — all knowledge is embedded, no library source required.
Sparring partner for design and planning. Asks critical questions, researches feasibility, weighs tradeoffs, and produces or updates REQUIREMENTS.md, ARCHITECTURE.md, and TODO.md. Also triages GitHub issues and bug reports into actionable tasks.
Expert developer for the @zeix/cause-effect reactive signals library. Use when implementing features, fixing bugs, writing tests, or answering questions about the library's internals, public API, or design decisions.
Keep developer-facing documents up to date with the @zeix/cause-effect source code: README.md, GUIDE.md, ARCHITECTURE.md, REQUIREMENTS.md, AGENTS.md, .github/copilot-instructions.md, and JSDoc in src/. Use after code changes, to verify consistency, or to update a specific document.
Maintain CHANGELOG.md for the @zeix/cause-effect library. Use after meaningful code changes, when asked to add release notes, or to prepare a release.
| name | adr-keeper |
| description | Maintains Architectural Decision Records (ADRs) for this project. Creates, updates, lists, and supersedes ADRs in the /adr/ directory. |
| user_invocable | true |
In scope: All files in /adr/ directory (at project root)
Out of scope: REQUIREMENTS.md, ARCHITECTURE.md (use architect skill)
ADR directory: This skill assumes ADRs are stored in /adr/ at the project root. If your
project uses a different location (e.g., /docs/adr/), the workflows will need to be adjusted
accordingly.
<essential_principles> ADRs are immutable. Once accepted, an ADR is never modified. Updates create new ADRs that supersede old ones.
Trace to requirements. Every ADR must reference relevant sections from REQUIREMENTS.md (e.g., M1, S3, X1).
Sequential numbering. ADRs use 4-digit sequential numbers (0001, 0002, ...).
Status is explicit. Each ADR must have a clear status: Proposed, Accepted, Rejected, Superseded.
Concise over comprehensive. Focus on the decision, context, and consequences. Avoid unnecessary detail. </essential_principles>
What would you like to do with ADRs?Wait for response before proceeding.
| Response | Workflow | |---|---| | 1, "create", "new", "add" | workflows/create-adr.md | | 2, "update", "edit", "modify" | workflows/update-adr.md | | 3, "list", "show all", "index" | workflows/list-adr.md | | 4, "supersede", "replace", "deprecate" | workflows/supersede-adr.md | | 5, "search", "find", "grep" | workflows/list-adr.md (with filter) |Intent-based routing:
<reference_index>
All in references/:
| File | Contents |
|---|---|
| adr-template.md | The template for new ADRs |
| adr-index.md | Index of all ADRs with status |
| </reference_index> |
<workflows_index>
All in workflows/:
| Workflow | Purpose |
|---|---|
| create-adr.md | Create a new ADR from the template |
| update-adr.md | Update a Proposed ADR (immutable after Accepted) |
| list-adr.md | List all ADRs, optionally filtered by keyword |
| supersede-adr.md | Create a new ADR that supersedes an existing one |
| </workflows_index> |
