brier

name

brier

description

Use when the user wants advice or a decision analysis rather than pure implementation, especially for prompts like "should I", "should we", "which is better", "is it worth it", or "what would you do" about architecture, product, hiring, strategy, or career choices. Reframe the decision as explicit KPIs, expanded options, reference classes, disconfirming evidence, numeric forecasts, and a review date. Do not use for straightforward debugging, factual explanation, or routine coding tasks.

Brier

Use this skill to turn vague decisions into forecastable choices.

Prefer the brier MCP server when available. It gives you persistent tools, resources, and prompts for the workflow.

Trigger Conditions

Use this skill when the user is asking for advice or a decision recommendation, especially in forms like:

• "Should I..." / "Should we..."
• "Which is better..."
• "Is it worth..."
• "What would you do..."
• "Do you recommend..."

Strong fits:

• architecture tradeoffs
• build vs buy
• refactor vs defer
• hiring or org choices
• startup, product, or strategy decisions
• career choices

Do not use it for:

• debugging questions
• pure knowledge/explanation requests
• direct implementation tasks with no decision component

Workflow

1. If there is no stored decision yet, call create_decision.
2. Use brier://framework if you need the canonical sequence.
3. Structure the analysis around:
   • KPI definition
   • KPI resolution metadata
   • option expansion
   • reference class / outside view
   • mechanism or decomposition
   • disconfirming evidence
   • numeric forecasts with 80% confidence intervals
   • a compact forecast summary table
   • review date
4. Persist the result with save_analysis.
   • kpis must be a list of objects shaped like: {"name": "...", "description": "...", "unit": "%|$|days|...", "target": 80, "weight": 1.0, "outcome_type": "binary|count|continuous|percent|currency|score", "resolution_date": "2026-06-30", "resolution_rule": "...", "data_source": "..."}
   • options must be a list of objects shaped like: {"name": "...", "description": "...", "forecasts": [{"kpi_name": "...", "point_estimate": 75, "ci_low": 60, "ci_high": 86, "confidence_level": 0.8, "reasoning": "...", "assumptions": ["..."], "base_rate": 68, "base_rate_source": "...", "inside_view_adjustment": "..."}]}
   • Do not pass KPI or option names as bare strings.
5. If the user is revisiting the decision, use get_decision and review_decision.
6. If outcomes are now known, call score_decision to update calibration.
7. If the user wants to externalize a forecast into a prediction market, draft it first:
   • Use brier forecast-draft <decision-id> --output forecast-pack.json for stored decisions.
   • Use brier forecast-draft "<forecast question>" --initial-prob <1-99> --resolution-date YYYY-MM-DD --output forecast-pack.json for standalone policy questions.
   • Treat forecast drafts as review artifacts only; do not publish questions or place bets unless the user explicitly asks.

Working Rules

• Do not give a vague recommendation before the KPIs and forecasts are explicit.
• In the first answer, show the forecast results without waiting to be asked again. Include a compact table or bullet summary of each option on the decisive KPIs.
• After the forecast summary, explain how those forecast differences drive the recommendation or prioritization.
• Prefer KPIs that can actually resolve later; avoid labels like fit or quality unless the resolution rule makes them numeric and scoreable.
• Keep the option set broader than the user's first framing.
• Treat disconfirming evidence as first-class, not a footnote.
• Prefer one or two decisive KPIs over a long laundry list.
• Use the MCP tools for persistence; do not leave the analysis only in chat if the user intends to track it.

Fallback

If the brier MCP server is not connected, tell the user to add it with:

brier setup codex

Then continue with the same workflow once the server is available.