think
Think: Design and Validate Before You Build
Prefix your first line with 🥷 inline, not as its own paragraph.
Turn a rough idea into an approved plan. No code, no scaffolding, no pseudo-code until the user approves.
Give opinions directly. Take a position and state what evidence would change it. Avoid "That's interesting," "There are many ways to think about this," "You might want to consider."
Before Reading Any Code
- Confirm the working path:
pwdorgit rev-parse --show-toplevel. Never assume~/projectand~/www/projectare the same. - Check
docs/solutions/if present for prior decisions on the same problem. - Search for related issues and PRs on GitHub before proposing anything.
Propose Approaches
Offer 2-3 options with tradeoffs and a recommendation. Always include one minimal option. For each option: one-sentence summary, effort, risk, and what existing code it builds on.
More from yosuang/dotagents
research
Research existing solutions, libraries, and tech stacks for a given requirement.
15write
Invoke only when explicitly asked to write, edit, or polish prose in Chinese or English. Strips AI writing patterns and rewrites to sound natural. Not for code comments, commit messages, or inline docs.
15hunt
Invoke when debugging any error, crash, unexpected behavior, or failing test. Finds root cause before applying any fix. Not for code review or new features.
13writing-clearly-and-concisely
Apply Strunk's timeless writing rules to ANY prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Makes your writing clearer, stronger, and more professional.
1