メニュー
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.
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.
Maintains Architectural Decision Records (ADRs) for this project. Creates, updates, lists, and supersedes ADRs in the /adr/ directory.
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.
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 | cause-effect-dev |
| description | 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. |
| user_invocable | false |
For consumer projects that use @zeix/cause-effect as a dependency, use the cause-effect skill instead.
<essential_principles> Read before writing. Always read the relevant source file(s) before proposing or making changes.
The signal type set is complete. Check REQUIREMENTS.md before proposing anything new — new signal types are explicitly out of scope.
T extends {} — all signal generics exclude null and undefined. Use wrapper types or sentinel values to represent absence.
Run bun test after every change.
</essential_principles>
Wait for response before proceeding.
| Response | Workflow | |---|---| | 1, "implement", "add", "extend", "build" | workflows/implement-feature.md | | 2, "fix", "bug", "debug", "broken", "wrong" | workflows/fix-bug.md | | 3, "test", "spec", "coverage" | workflows/write-tests.md | | 4, "question", "explain", "how", "why", "what" | workflows/answer-question.md |Intent-based routing (if user provides clear context without selecting):
After identifying the workflow, read it and follow it exactly.
<reference_index>
Shared references (from ../shared/references/):
| File | Contents |
|---|---|
| ../shared/references/api-facts.md | Key API constraints and callback patterns |
| ../shared/references/non-obvious-behaviors.md | Counterintuitive behaviors with examples |
| ../shared/references/error-classes.md | Error classes and when they are thrown |
Skill-specific references (in references/):
| File | Contents |
|---|---|
| source-map.md | Authoritative documents + signal source file locations |
| internal-types.md | Node shapes and global pointers |
| </reference_index> |
<workflows_index>
All in workflows/:
| Workflow | Purpose |
|---|---|
| implement-feature.md | Add or extend library functionality |
| fix-bug.md | Diagnose and fix unexpected behavior |
| write-tests.md | Write or update tests for a signal type or behavior |
| answer-question.md | Answer questions about the API, internals, or design |
| </workflows_index> |
