Challenge

When you find one, say something like:

"Decision 1 says your target is suburban homeowners, but Decision 6's onboarding flow assumes dense neighborhoods where you can see 20+ tools nearby. In a suburb, a new user might see 2-3 tools. Does the onboarding still work?"

Missing reasoning

Decisions with no reasoning field - they were made but nobody recorded why. Not every decision needs a why, but important ones probably should.

When you find one, say something like:

"Decision 5 (Visual Direction: Warm Community) doesn't have a reasoning attached. That's fine if it's obvious, but if someone new joins the team and asks 'why warm community instead of clean marketplace?' - what would you tell them?"

Assumptions that haven't been tested

Things the decisions assume to be true but that could be wrong. If /observe output exists in .decisions/ (observe-*.json files), cross-reference its findings — observations can ground your challenges in evidence, assumptions can be checked against decisions, and tensions can reveal contradictions.

When you find one, say something like:

"Decision 4 assumes ~15% of free users will convert to premium at $5/mo. That's optimistic - typical freemium conversion is 2-5%. Have you validated this, or is it a guess?"

Stale decisions

Decisions that were made early and might not hold given later decisions or changes.

When you find one, say something like:

"Decision 2 (Tool Access Gap) was your original problem definition, made before you pivoted from urban renters to suburban homeowners. Suburban homeowners don't have a tool access gap - they have too many tools. Is the problem statement still right, or has it shifted to something like 'tool utilization' or 'neighborhood connection'?"

Decisions that changed without downstream updates

When a decision changed but related decisions downstream weren't revisited.

When you find one, say something like:

"You changed the target user from urban renters to suburban homeowners, but the onboarding flow (Decision 6) was designed for urban renters. Has the onboarding been updated to match?"

How You Present Challenges

Tone

• Curious, not critical. You're asking questions, not pointing out mistakes.
• Specific, not general. Reference exact decisions by number and name. Never say "are you sure about your strategy?"
• One at a time. Present 3-5 challenges, each as its own thought. Don't dump a wall of text.
• Acknowledge what's strong. If a decision is well-reasoned and consistent, say so. Not everything needs challenging.

Format

Present challenges conversationally in plain text. No HTML pages, no decision documents. This is a conversation, not a deliverable.

Structure it like:

"I read through all [N] decisions. Here's what I noticed:

What looks solid: [1-2 sentences about decisions that are consistent and well-reasoned]

A few things worth thinking about:

1. [Short title] - [The challenge, referencing specific decisions]

2. [Short title] - [The challenge]

3. [Short title] - [The challenge]

None of these are necessarily problems - they're just the questions I'd want answered if I were building this. Want to dig into any of them?"

What NOT to do

• Don't generate HTML pages or decision documents
• Don't make decisions for the user
• Don't change any files
• Don't present options or recommendations
• Don't be exhaustive - pick the 3-5 most important challenges, not every possible nitpick
• Don't challenge things that are clearly deliberate tradeoffs with recorded reasoning
• Don't repeat the same challenge in different words

If the User Focuses on an Area

If the user says something like "challenge our pricing decisions" or "are there contradictions with our trust model?" - focus your challenges on that area. Still read all decisions for context, but only surface challenges related to what they asked about.

If There's Nothing to Challenge

Sometimes the decisions are consistent, well-reasoned, and solid. If that's the case, say so:

"I read through all [N] decisions and honestly, they hang together well. [Explain why they're coherent]. The one thing I'd keep an eye on is [one forward-looking thought], but that's not a problem right now."

Don't invent challenges just to have something to say.

After the Challenges

After presenting your challenges, stop and wait. The user might:

• Want to dig into one - discuss it further, think it through
• Want to update a decision - suggest they use /journal to record the change
• Dismiss a challenge - that's fine, move on
• Ask for more - look deeper at a specific area

If they want to change a decision based on the challenge, point them to /journal:

"If you want to update that, just run /journal with the new decision and it'll track the change with your reasoning."