Decide the technical path once the ask is clear. Use when the WHAT is confirmed but more than one way to build it remains — architecture, technology, design.
69
75%
Does it follow best practices?
Impact
84%
Average score across 1 eval scenario
Low
Low-risk findings worth noting
Fix and improve this skill with Tessl
tessl review fix ./hope/skills/shape/SKILL.mdFrom the conversation/context/user:
Proceed only when: the ask is confirmed, and more than one way to build it remains that differs where it matters.
Anything else, say which in one plain line — never decide a path anyway:
Before routing any choice: retrieve what settles it without the user — their taste from CLAUDE.md and project rules, facts from the repo, docs, the web. Only choices that stay genuinely open after retrieval route to a skill.
Route each open choice by what keeps it open, invoking the named skill with the Skill tool:
When the work iterates — an agent loop, a refinement cycle — which loop is itself one of the choices: read loop-selection.md.
Each decision re-enters the routing: a resolved choice can open the next one or conflict with an earlier one; a conflict is one more choice, surfaced to the user, never silently settled. Route again until every open choice has the user's decision or confirmation and none conflict.
The technical path is the result, decided: each choice resolved with its reason and what was turned down. The user owns the path.
Then check what still stands open:
The shaping is spent once the user owns the path — anything further runs under the branch picked here, never as another round of deciding the path.
7f55b8e
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.