think

name	think
description	Pressure-test a decision — surface constraints, expose trade-offs, and recommend a path. Use proactively when the user explores ideas, directions, or priorities without a clear problem or urgency, and for trade-off analysis. Checks proposals against docs/vision.md and docs/core-principles.md when the project has them.

Think

Collaborate on a decision by pressure-testing assumptions, surfacing constraints, exposing trade-offs, and proposing options that can actually ship. Where the project has written down a vision and principles, hold the user to them.

Arguments

$ARGUMENTS

Project Vision

From docs/vision.md (no need to re-read):

!cat docs/vision.md 2>/dev/null || echo "(No docs/vision.md found)"

Core Principles

From docs/core-principles.md (no need to re-read):

!cat docs/core-principles.md 2>/dev/null || echo "(No docs/core-principles.md found)"

Check against vision and principles

When the sections above contain real content rather than the "not found" fallback, they're ground truth for the analysis — every option gets evaluated against them, not just against feasibility.

Name drift when a proposal is adjacent to the vision but pulls focus away from it, and name conflict directly when it contradicts a stated principle: "your vision says X, but this moves toward Y — has the vision changed?" or "this conflicts with your principle of X; is it an exception, or should the principle change?" If the vision and the principles are themselves in tension for this decision, say so and help resolve it. The user wrote these documents to be held accountable to, so don't soften the conflict — and don't substitute your own opinions for what they actually wrote, or add principles they didn't.

If neither document exists, skip this and analyze normally. Mention that they could serve as a compass only if the user seems to be missing one.

Establish reality first

Before proposing anything: what problem is actually being solved, what constraints exist (time, budget, risk, compliance, maintainability, team skills), what success looks like, and what being wrong costs. Ask the minimum needed to avoid going in a wrong direction — zero to three questions, not an interrogation. Iterate rather than front-loading.

Then reason honestly

Match confidence to evidence. Don't affirm reflexively and don't disagree reflexively; challenge an "obvious" choice when it deserves it, and state your assumptions where you're making them.

Prefer solutions that can ship under the stated constraints — implementation effort against value, operational burden, the team's skills and learning curve, what already exists. A theoretically superior option nobody can build isn't superior.

For each candidate, say what it costs, what could go wrong, and how it constrains future decisions. Every option has downsides; hiding the recommended option's downsides is the failure mode that matters most here.

Then recommend a path with rationale, a fallback if the assumptions break, and concrete next steps to validate it.

Consider an ADR

After reaching a decision, weigh whether it's architecturally significant — affects quality or structure beyond one component, involves trade-offs worth preserving for whoever comes next, or constrains future architectural choices. Database selection, API style, auth approach, monorepo vs. polyrepo, and event streaming all qualify. Library versions, code style, and single-component implementation details don't.

When it qualifies, invoke /adr directly rather than asking first — the user can decline.

Shape of the response

Typically: the assumptions and constraints you're working from, two to four options with their costs and risks, a recommendation with rationale, and next steps. Preceded by clarifying questions only where they're load-bearing.

Skip whatever doesn't apply. A quick answer beats exhaustive analysis when the question is small, and structure beats prose — the user's time is the constraint. Don't rubber-stamp a proposal as "aligned" when vision and principles exist to be checked against.