Exploring approaches
no-cape keeps the knowledge and drops the cape.
npx -y skills add yuchi-chang/no-cape --skill exploring-approachesAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when starting a new project or significant feature from a vague idea — before clarifying details or planning, especially when the user already has a preferred approach
SKILL.md
2.7 KB, as published. Nobody here has run it
Exploring Approaches
A request names a goal, not an architecture. The fastest way to build the wrong thing is to take the first approach that comes to mind — including the user's. Someone holding a hammer sees nails; your job is to check whether it's actually a nail before anyone starts hammering.
This runs before [[clarifying-requirements]]. Don't refine details inside an approach until you've confirmed it's the right approach. Once one is chosen, [[clarifying-requirements]] handles the open questions and [[writing-solid-plans]] turns it into steps.
Challenge the framing first
- A goal like "a service that translates English audio" hides a fork: call a cloud API, self-host open models, or buy a SaaS. These grow into different projects — different cost, deployment, and code. Surface the fork before refining any branch of it.
- Do this even when the user states a preference. A stated approach is a starting hypothesis, not a settled decision. Confirming it without examining it is how knowledge blind spots become architecture.
The brake: when to speak, when to move on
Raise an alternative only when all three hold. Miss one and stay quiet — confirm the direction and proceed.
- They likely haven't considered it. "You said self-host — what about a cloud API?" is too obvious to earn its place. Skip it.
- It would change the shape of the project — architecture, cost structure, or deployment. Not a library swap.
- You can name a concrete reason for their situation — not "might be better," but "at your volume / under your constraint, it specifically wins because X."
The bar for speaking up is: can you give them an "I hadn't thought of that"? If you can't, don't manufacture options to look thorough. Inventing alternatives to seem thoughtful is its own failure — it buries the real decision in noise.
Watch for hidden constraints, not just alternative tools: "you plan to self-host Whisper, but those are client meeting recordings — data residency may force your hand" challenges the premise more usefully than any tool swap.
Presenting
- Lead with your recommendation and why. Give 2-3 genuinely distinct options with their trade-offs — distinct in shape, not flavor.
- If the user's stated approach survives scrutiny, say so plainly and move on. Confirming a good instinct is a real outcome, not a skipped step.
Smell test
If the project's fundamental shape was never on the table — only details within one unexamined approach — this skill was skipped.