메뉴
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> |
