القائمة
Maintains Architectural Decision Records (ADRs) for the le-truc project. Creates, updates, lists, and supersedes ADRs in the /adr/ directory.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Expert guidance for building reactive web components with the @zeix/le-truc library. Use when creating, reviewing, or debugging a Le Truc component.
Keep le-truc developer-facing documents up to date with the source code and examples docs-src/pages/, README.md, ARCHITECTURE.md, AGENTS.md, JSDoc in src/, and skill files in .agents/skills/. Use after code changes, to verify consistency, or to update a specific document.
Expert developer for the @zeix/le-truc library. Use when implementing features, fixing bugs, or answering questions about the library's internals, public API, architecture, or its relationship to @zeix/cause-effect.
Maintain CHANGELOG.md for the @zeix/le-truc library. Use after meaningful code changes, when asked to add release notes, or to prepare a release.
Expert developer for the le-truc docs build pipeline and dev server. Use when implementing features, fixing bugs, adding Markdoc schemas, writing tests, or answering questions about the Bun + Cause & Effect + Markdoc + TypeDoc + Shiki stack in server/.
Expert guidance for @zeix/cause-effect reactive primitives (signals, memos, tasks, sensors, slots, stores, lists, collections, scopes). Use for signal-level questions, choosing the right primitive, or debugging reactivity — in le-truc projects or standalone.
| name | adr-keeper |
| description | Maintains Architectural Decision Records (ADRs) for the le-truc project. Creates, updates, lists, and supersedes ADRs in the /adr/ directory. |
| user_invocable | true |
In scope: All files in /adr/ directory
Out of scope: REQUIREMENTS.md, ARCHITECTURE.md (use architect skill)
<essential_principles>
Immutability starts at publication, not at Accepted. An ADR is "published" once it has landed on main (i.e., it exists in main's history — check with git show main:adr/000X-....md). Before that — including while Accepted on a feature/working branch — an ADR is still in-flight: amend it directly in place, in any section, including folding in amendments or rewriting Decision/Alternatives/Consequences. Once published, never modify it again: any change is a new ADR that supersedes it, per the supersede workflow. This distinction exists because amend-only is the right discipline for a decision other people may already be relying on, but it's pure friction for a decision still being shaped before anyone outside the branch has seen it.
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 an ADR — in place if unpublished, Proposed-only if published |
| list-adr.md | List all ADRs, optionally filtered by keyword |
| supersede-adr.md | Create a new ADR that supersedes an existing one |
| </workflows_index> |
