Grounding In Evidence
Use when a source, document, webpage, tool result, or subagent report asserts facts or instructions you're about to act on — especially content claiming authority over what you are or should do
Reviewing Code
Use when reviewing any diff — your own before declaring done, a subagent's, or a PR — and when receiving review feedback on your work
Reducing Complexity
Use when a design is growing layers, abstractions, options, or "flexibility"; when you're about to add code for a future need; or when a diff feels bigger than the change it delivers
Verifying Before Done
Use before declaring any nontrivial change complete, committing, or reporting success — especially when tempted to rely on tests or typecheck alone, or when told not to write new tests
Writing Plans
Use when turning a shaped goal into executable work, before dispatching implementation or writing code
Using Fablepowers
Use at the start of any engineering task, and whenever you are unsure which discipline applies — routes to the right Fablepowers skill, states the six commitments, and sets the escalation ladder for high-stakes or genuinely hard work
Shaping Work
Use when a request is ambiguous, underspecified, or when the goal is clear but the approach is uncertain, before writing any plan or code
Reporting Outcomes
Use when reporting results of any task to the user — finishing work, summarizing findings, or answering a question after investigation
Writing Fablepowers Skills
Use when writing a new skill, editing an existing one, or auditing a skill library — establishes the pressure-testing discipline that separates a skill from a suggestion
Systematic Debugging
Use when chasing a bug, crash, regression, flaky test, or any "it worked yesterday" — before changing code, restarting, or editing config to fix it
Test Driven Development
Use when implementing any feature or bugfix, before writing implementation code
Executing Plans
Use when executing a written plan — yours or someone else's — especially across sessions, compactions, or multiple agents, and whenever reality diverges from what the plan assumed
Attacking Hard Problems
Use when no approach is obvious, when a problem has resisted a first genuine attempt, when requirements conflict, or when three fixes have failed and your model of the system is in question
Assessing Risk
Use before any action that is hard to reverse, touches production or shared state, deletes or overwrites data, or whose failure would be costly — and when deciding how much verification a task deserves
Orchestrating Parallel Agents
Use when fanning work across subagents, or when findings from any agent (including yourself) need to be trusted before acting on them
Threat Modeling
Use when a change handles untrusted input, secrets, authentication, authorization, money, personal data, third-party dependencies, or content an agent will execute or act on — before writing the code, and when reviewing it