think

Name: think
Author: tw93

6.6kstars384forks

How to install think?

tw93/waza/think

$npx -y skills add tw93/Waza --skill think

Installs into the current project.

Summary

Turns rough ideas into approved, decision-complete plans with validated structure before coding. Use when users ask in any language for planning, architecture, design direction, feasibility, value judgment, or whether a feature is worth doing before implementation. Not for bug fi

Files · 1

View on GitHub

SKILL.md

1	# Think: Design and Validate Before You Build
2
3	Prefix your first line with 🥷 inline, not as its own paragraph.
4
5	Update check (non-blocking). Once per conversation, run `bash <skill-base-dir>/scripts/check-update.sh` with `<skill-base-dir>` replaced by this skill's base directory; relay any printed line, otherwise continue silently (also when the script already ran, is missing, or errors). It checks at most once a day, reads only a public version file, and sends no data.
6
7	Turn a rough idea into an approved plan. No code, no scaffolding, no pseudo-code until the user approves.
8
9	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."
10
11	## Outcome Contract
12
13	- Outcome: a rough idea becomes a decision-complete recommendation or implementation plan.
14	- Done when: the goal, success criteria, constraints, chosen approach, rejected tradeoffs, tests, and handoff steps are concrete enough to execute without re-deciding.
15	- Evidence: current repo state, project docs, live external docs when relevant, prior decisions, constraints, and explicit user preferences.
16	- Output: one recommended direction or a handoff plan with assumptions and verification steps.
17
18	## Durable Context Preflight
19
20	See [references/durable-context.md](references/durable-context.md) for when to read durable context, the read-order budget, and the memory-type mapping (planning constraints, reusable patterns, facts that need re-verification against current state).
21
22	For `/think`: current repo state and live docs override memory. Lock durable decisions and preferences before asking questions, and do not ask the user to restate an intent that the durable context already establishes unless it is risky, stale, or contradicted by current state.
23
24	Before outputting any plan, scan the project's `AGENTS.md`, `CLAUDE.md`, `.claude/rules/*.md`, and any local agent-memory summary if the user pointed at one. If the proposed plan contradicts a "hard rule", "never X", "must Y", or "prefer Z" stated in those files, surface the contradiction in the plan output (one sentence: which rule, which step contradicts it, recommended resolution). Do not silently override the rule. If the rule blocks the plan, stop and ask before continuing.
25
26	## Lightweight Mode
27
28	Activate when the user wants to fix something rather than build something, the problem is already defined, and the only open question is "how to fix it."
29
30	Give one recommended fix in 2-3 sentences: what changes, where (file:line if known), and why. Name the brute-force version in one line first; default to it unless the user wants elegance. List involved files, flag explicitly if more than 5. State one risk. Wait for approval before implementing.
31
32	Upgrade to full mode if you find 3 or more genuinely different approaches with meaningful tradeoffs.
33
34	## Evaluation Mode
35
36	Activate when the user wants to judge whether something should exist, be kept, exposed, or removed. Typical triggers: "判断一下", "有没有必要", "值不值得", "should we keep this", "is this worth it", "我不想做", "商业前景", "有没有必要继续".
37
38	State the evaluation target and what kind of judgment is needed (value, risk, or tradeoff). Take a current-state snapshot: what it does, who uses it, what depends on it; grep and read before opining.
39
40	For product pivot, commercialization, or business-direction requests, frame the market, user, distribution, willingness-to-pay, and maintenance burden before proposing technology. Do not assume open source, do not assume implementation comes first, and do not hide a business judgment inside a technical plan.
41
42	Commercial readiness gate. When the judgment is whether a product, paid feature, launch, or version is chargeable, evaluate chargeability before implementation. Check delivery and update path, first-run activation/onboarding, payment/license/trial boundary, privacy and network promises, headline-feature reliability and honest degradation, support/refund triggers, competitor wedge, and solo-maintainer maintenance burden. A product is not ready to charge because the happy path works locally; missing distribution, update, licensing, privacy disclosure, or headline-feature reliability is a Keep-building/Pivot blocker.
43
44	Output format (Kill/Keep/Pivot):
45
46	Line 1: one of Kill / Keep / Pivot as the verdict. No preamble.
47
48	Then three reasons,

People who liked this also viewed

6 picks

Type

think

6.6kstars384forks

View on GitHub

How to install think?

tw93/waza/think

$npx -y skills add tw93/Waza --skill think

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Think: Design and Validate Before You Build
2
3	Prefix your first line with 🥷 inline, not as its own paragraph.
4
5	Update check (non-blocking). Once per conversation, run `bash <skill-base-dir>/scripts/check-update.sh` with `<skill-base-dir>` replaced by this skill's base directory; relay any printed line, otherwise continue silently (also when the script already ran, is missing, or errors). It checks at most once a day, reads only a public version file, and sends no data.
6
7	Turn a rough idea into an approved plan. No code, no scaffolding, no pseudo-code until the user approves.
8
9	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."
10
11	## Outcome Contract
12
13	- Outcome: a rough idea becomes a decision-complete recommendation or implementation plan.
14	- Done when: the goal, success criteria, constraints, chosen approach, rejected tradeoffs, tests, and handoff steps are concrete enough to execute without re-deciding.
15	- Evidence: current repo state, project docs, live external docs when relevant, prior decisions, constraints, and explicit user preferences.
16	- Output: one recommended direction or a handoff plan with assumptions and verification steps.
17
18	## Durable Context Preflight
19
20	See [references/durable-context.md](references/durable-context.md) for when to read durable context, the read-order budget, and the memory-type mapping (planning constraints, reusable patterns, facts that need re-verification against current state).
21
22	For `/think`: current repo state and live docs override memory. Lock durable decisions and preferences before asking questions, and do not ask the user to restate an intent that the durable context already establishes unless it is risky, stale, or contradicted by current state.
23
24	Before outputting any plan, scan the project's `AGENTS.md`, `CLAUDE.md`, `.claude/rules/*.md`, and any local agent-memory summary if the user pointed at one. If the proposed plan contradicts a "hard rule", "never X", "must Y", or "prefer Z" stated in those files, surface the contradiction in the plan output (one sentence: which rule, which step contradicts it, recommended resolution). Do not silently override the rule. If the rule blocks the plan, stop and ask before continuing.
25
26	## Lightweight Mode
27
28	Activate when the user wants to fix something rather than build something, the problem is already defined, and the only open question is "how to fix it."
29
30	Give one recommended fix in 2-3 sentences: what changes, where (file:line if known), and why. Name the brute-force version in one line first; default to it unless the user wants elegance. List involved files, flag explicitly if more than 5. State one risk. Wait for approval before implementing.
31
32	Upgrade to full mode if you find 3 or more genuinely different approaches with meaningful tradeoffs.
33
34	## Evaluation Mode
35
36	Activate when the user wants to judge whether something should exist, be kept, exposed, or removed. Typical triggers: "判断一下", "有没有必要", "值不值得", "should we keep this", "is this worth it", "我不想做", "商业前景", "有没有必要继续".
37
38	State the evaluation target and what kind of judgment is needed (value, risk, or tradeoff). Take a current-state snapshot: what it does, who uses it, what depends on it; grep and read before opining.
39
40	For product pivot, commercialization, or business-direction requests, frame the market, user, distribution, willingness-to-pay, and maintenance burden before proposing technology. Do not assume open source, do not assume implementation comes first, and do not hide a business judgment inside a technical plan.
41
42	Commercial readiness gate. When the judgment is whether a product, paid feature, launch, or version is chargeable, evaluate chargeability before implementation. Check delivery and update path, first-run activation/onboarding, payment/license/trial boundary, privacy and network promises, headline-feature reliability and honest degradation, support/refund triggers, competitor wedge, and solo-maintainer maintenance burden. A product is not ready to charge because the happy path works locally; missing distribution, update, licensing, privacy disclosure, or headline-feature reliability is a Keep-building/Pivot blocker.
43
44	Output format (Kill/Keep/Pivot):
45
46	Line 1: one of Kill / Keep / Pivot as the verdict. No preamble.
47
48	Then three reasons,

People who liked this also viewed

6 picks

Type