Terma

Entry point for planning work — routes to the skills that own the substance. Use when the user asks to plan, sequence, or scope something and it is not yet clear which kind of planning is needed.

Use when thinking needs to open rather than close — generating possibilities, breaking out of a stuck frame, reading the state of a creative process, or noticing that a session has gone flat, cynical, or circular. A deck of moves for the infinite game of ideation, where good thinking is playing the right card at the right time. Trigger on brainstorming, exploring possibilities, being stuck, or when the current framing has stopped producing anything. Do NOT use when converging on a decision or executing something already chosen.

Use when arriving in an unfamiliar codebase, or returning to one after long enough that its shape has been forgotten. Concerns building a working model of what the system is and where its decisions live, before touching anything. Trigger at the start of work in a new repository, or when a change is about to be made somewhere not yet understood. Do NOT use for a codebase already held in mind, or for answering one specific question — that is research.

Use when a specific question must be answered before work can sensibly proceed — how something currently works, whether an approach is viable, what already exists, what a change would touch. Concerns answering the question that was actually asked, at a confidence level stated honestly. Trigger on investigation requests and on discovering that a decision rests on something unverified. Do NOT use for building a general model of an unfamiliar codebase — that is orient.

Use when carrying out a change that is already decided — building the thing rather than choosing it. Concerns staying oriented while the code is in motion — knowing how far from the last checkpoint, noticing when the plan has stopped matching what is being found, and stopping rather than compensating. Trigger on executing a plan or building a defined feature. Do NOT use for deciding what to build, or for restructuring code that already works.

Use when reviewing written code — your own or someone else's. Concerns finding what the code will cost later rather than what it violates now, and saying it in a way that can be acted on. Trigger on requests to review, critique, or give feedback on an implementation, and before handing off work you wrote. Do NOT use for debugging behaviour or for deciding what to build.

Use when writing or restructuring code in any language. Concerns the shape of the code itself — what is data and what is function, where effects live, what the names say, when a module has stopped having one subject. Trigger on any implementation task, and on review of code that works but reads badly. Do NOT use for choosing what to build, planning sequence, or debugging behaviour.

Use when deciding where the boundaries in a system go — what becomes a module, a service, a process, a package; what gets extracted, merged, or left duplicated. Concerns which cut isolates change rather than which cut looks tidy. Trigger on refactors, restructuring, "this file is too big", extracting shared code, and designing the shape of something new. Do NOT use for local code style, or for naming and modelling the domain itself.

Explore a problem space before committing to a direction. Use this whenever the user is circling an idea rather than executing one — thinking out loud, asking "what's interesting here", "I've been wondering about X", "is this worth doing", "how should I think about this", or describing an itch without a plan. Also use when a request arrives already framed as a task but the framing looks inherited or unexamined. The output is a map of the space with terminology joined to prior art, NOT a plan. Concluding that the user should not proceed is a success condition, not a failure.

Use during any implementation, design, refactor, or debugging task, in any language or codebase. Before changing anything that touches an existing domain concept, rule, type, or invariant, find what the change collides with and name the routes through it — instead of letting the first workable route settle the question silently. Trigger on any request to build, change, model, extend, or restructure, including small changes and including when the user says nothing about design. Do NOT use for purely additive isolated code, pure explanation, or review with no change proposed.

Use at a checkpoint after real friction — a task where something was repeatedly confusing, a skill misfired or failed to fire, or a workaround was invented that should not have been needed. Concerns turning friction into a change to the skills themselves, and knowing when the right change is to cut rather than add. Trigger at session end after substantial work, or when the same problem has now happened more than once. Do NOT use reflexively after routine tasks, or mid-task.

Use when deciding what the concepts in a system are and what they are called — the types, the boundaries between contexts, the vocabulary. Concerns whether the model tells the truth about the problem and reads as a story a human can follow. Trigger on designing or changing types, naming things, modelling a business domain, or when the code's words and the problem's words have drifted apart. Do NOT use for local implementation style or for planning work.

Use when writing, revising, or judging a skill. A skill is a packet of wisdom that changes how a situation is seen, not a procedure to follow — dense, composable, and worth loading. Trigger on creating a new skill, editing an existing one, deciding whether something should be a skill at all, or reviewing a set of skills for bloat and overlap. Do NOT use for the mechanics of the skill file format, or for ordinary documentation.

Create, update, and manage Claude Code skills. Use when working with SKILL.md files, slash commands, or extending Claude's capabilities.

Use when work is about to be split across multiple agents, or when deciding whether it should be. Concurrency is a property of the change, not a scheduling decision — what can proceed at once is determined by what the pieces have to agree on. Trigger on any request to parallelise, fan out, delegate to subagents, or run work concurrently, and whenever a plan has more than one independent-looking piece. Do NOT use for single-threaded work, or for splitting purely to appear fast.

Use when an idea needs to become something buildable, or needs to die honestly before anything is built. Concerns the alternation between opening a possibility up and closing it down, and finding the fastest thing that would settle whether it is worth doing. Trigger when someone arrives with a concept rather than a specification, or on requests to explore, pitch, spec, or prototype. Do NOT use when what to build is already settled and only the plan remains.

Use when something is wrong and the cause is not yet known — failures, regressions, flaky behaviour, performance problems, incidents, or a user report that does not match what the code appears to do. Concerns holding the difference between what is observed and what is believed, and spending each action on the question that most divides the possibilities. Trigger on any debugging or investigation where the answer is not already obvious. Do NOT use when the cause is already known and only the fix remains.

Use when planning any multi-step change, or when a plan already exists and is about to be executed. A plan is a sequence of ambiguity collapses, not a list of tasks — each step must end at a state that can be checked, and the checks must be capable of failing. Trigger on requests to plan, sequence, break down, stage, or scope work, and on any plan that reads as a list of things to do. Do NOT use for single-step changes, or where the outcome is already known and only the typing remains.