think
by tw93think is a decision-support skill for turning rough ideas into approved, decision-complete plans before coding. Use it for feature design, architecture choices, tradeoff analysis, and should-we-do-this questions where the goal is judgment, not implementation. It fits think for Decision Support, think guide, and think usage needs in repo-first workflows.
This skill scores 78/100, which means it is a solid listing candidate for directory users: it has clear trigger conditions, a sizable workflow-oriented body, and enough decision guidance to reduce guesswork versus a generic prompt. Users should expect a useful planning/validation skill, though some adoption friction remains because the repo lacks companion assets and includes placeholder markers.
- Clear triggerability: the frontmatter names specific use cases (e.g. 出方案, 怎么设计, whether to keep a feature) and excludes bug-fix use cases.
- Substantial operational content: the SKILL.md body is large, with multiple workflow and constraint sections that suggest real execution guidance rather than a stub.
- Good agent leverage: it explicitly tells the agent to turn rough ideas into approved plans, state a position, and wait for approval before implementing.
- No install command or support files are provided, so users only get the skill document itself and may need more setup guidance.
- Placeholder markers ('todo', 'tbd') appear in the content, which weakens trustworthiness and suggests some incomplete sections.
Overview of think skill
What think skill does
think is a decision-support skill for turning a rough idea into a clear, approved plan before anyone writes code. It is best for feature design, architecture choices, tradeoff analysis, and “should we do this?” questions where the main need is judgment, not implementation.
Who should install it
Install the think skill if you often need help with product decisions, technical direction, or scoped planning in a repo-first workflow. It is especially useful when a request starts with “plan this,” “what’s the best approach,” “should we keep this,” or similar value judgments.
What makes it different
The skill is opinionated: it pushes for a concrete recommendation, highlights what evidence would change the recommendation, and avoids premature code. That makes think for Decision Support stronger than a generic brainstorming prompt when you need a decision-ready output.
How to Use think skill
Install and trigger it
Install with npx skills add tw93/Waza --skill think. Then use it when the task is about choosing, shaping, or validating a direction rather than fixing a known defect. The think install step is simple, but the quality depends on giving it a real decision context.
Give the right input shape
A strong think usage prompt should include the goal, constraints, audience, and what choice is actually open. For example: “We need a faster onboarding flow for SMB admins; we can change UI only, cannot add backend work this sprint, and we need a recommendation with tradeoffs.”
Read the right file first
Start with SKILL.md, since the repo is intentionally minimal and there are no supporting rules/, references/, or resources/ folders. The main practical guidance comes from the skill body itself: lightweight mode, evaluation mode, and the rule to stay out of implementation until approval.
Use the workflow as a decision funnel
A good think guide flow is: state the decision, list constraints, ask for the best path, then request a plan with risks and alternatives only if needed. If you are unsure whether to use lightweight mode or full mode, describe whether the problem is already defined; that single detail changes the output substantially.
think skill FAQ
Is think only for new features?
No. It is also useful for architecture decisions, product value judgments, refactors with real tradeoffs, and “is this worth doing?” questions. It is not the best fit for simple bug fixes or tiny edits where the answer is already obvious.
How is this different from a normal prompt?
A normal prompt often produces vague options. The think skill is designed to force a decision: one recommended path, explicit tradeoffs, and a clear boundary against coding before approval. That makes it better when you need a plan that can be reviewed by a teammate or stakeholder.
Is think beginner-friendly?
Yes, if the user can describe the goal in plain language. Beginners get the most value when they provide the problem, the constraints, and the desired outcome, even if they do not know the technical terms.
When should I not use think?
Do not use it when you already know the fix and just need execution, or when the task is narrow enough that a direct edit is faster than analysis. It also adds less value if you have no real decision to make and only need a quick rewrite.
How to Improve think skill
Provide decision-grade context
The best think skill inputs include the current state, the target state, non-negotiable constraints, and what success looks like. For example, “We need to reduce setup time from 10 minutes to 2 minutes, keep the current backend, and avoid new dependencies” produces better advice than “improve onboarding.”
Ask for the decision, not just ideas
If you want better think usage, ask for a recommendation with a rationale, not a list of possibilities. Good: “Choose one approach and explain why it wins under these constraints.” Weak: “Give me some ideas.”
Surface the tradeoffs you care about
Tell the skill what matters most: speed, maintainability, cost, UX, risk, or team capacity. This helps think for Decision Support produce a plan that matches your priorities instead of a generic best-practice answer.
Iterate with sharper constraints
If the first result is too broad, narrow it with one follow-up: add a deadline, a prohibited dependency, a target user, or a must-keep component. The fastest way to improve output is to turn hidden assumptions into explicit constraints before asking for the next plan.