IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
Using Skills
The Rule
Invoke relevant skills BEFORE any response or action. Even a 1% chance a skill might apply means invoke it.
If an invoked skill turns out to be wrong for the situation, you don't need to follow it. But you must check.
Quick Reference — Skill Index
Discipline: test-driven-development, systematic-debugging, verification-before-completion, observe-before-editing, destructive-command-safety
Workflow: brainstorming, writing-plans, executing-plans, requesting-code-review, receiving-code-review, finishing-work, review-implementation, review-docs
Orchestration: dispatching-parallel-agents, workflow-routing, premortem, completion-check, explore
Tools: beads, git-commits, tmux, github, session-logs, agent-browser
Continuity: create-handoff, resume-handoff, documenting-solutions, refactor, using-git-worktrees, writing-skills, context-checkpoint
Beads: bead-craft, executing-beads, work-bead
Priority
- Process skills first (brainstorming, debugging) — determine HOW to approach
- Implementation skills second — guide execution
Skill Types
Rigid (TDD, debugging, verification): Follow exactly. Don't adapt away discipline.
Flexible (patterns, exploration): Adapt principles to context.
Red Flags
These thoughts mean STOP — you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore first" | Skills tell you HOW to explore. Check first. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
Commitment Protocol
When following a skill:
- Announce: State which skill you're using and why — e.g., "Using
systematic-debuggingto investigate this test failure." - Track: For multi-step skills, create TaskCreate entries for each step. This makes progress visible and prevents skipping steps.
- Follow exactly: Execute the skill's steps in order. Don't reinterpret, skip, or "adapt" rigid skills.
- Complete: Mark TaskUpdate completed only when the step is actually done — not when you think it will be.
Skipping tracking is itself a red flag. If you catch yourself thinking "I don't need to create tasks for this," you're rationalizing again.
User Instructions
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows. The user telling you to implement something does not override the requirement to check for and follow skills. Skills define HOW you do what the user asks.