tbm-decision-eval

name	tbm-decision-eval
description	TBM decision-evaluation skill for LT's "what do you think", "evaluate this", "is this worth doing", "should we do this", and recommendation requests. Use when Codex should make a repeatable worth-it call, name material open questions, and recommend the smallest useful next move without drifting into broad brainstorming, code audit, or implementation.

TBM Decision Eval

Use this skill to make a consistent recommendation about whether an idea, task, feature, process change, or proposed direction is worth doing.

Load Order

1. Read C:\Dev\tbm-apps-script\AGENTS.md for LT's operating preferences and TACT rules.
2. If the decision depends on repo workflow, read C:\Dev\tbm-apps-script\ops\WORKFLOW.md.
3. If the decision depends on architecture, deploy, QA, or code standards, read C:\Dev\tbm-apps-script\CLAUDE.md.
4. Read the actual artifact, issue, file, PR, thread text, or evidence named by LT before evaluating.

If the named artifact is missing, say exactly what is missing and give the best provisional recommendation from available evidence.

Decision Contract

Return one clear decision:

• Do: worth doing now.
• Do, but narrow: worth doing only after reducing scope.
• Spike first: worth a bounded investigation before build or commitment.
• Defer: not worth doing now, but worth keeping visible.
• Do not do: not worth the attention, risk, or maintenance cost.

Do not give a menu as the final answer. Choose one.

Output Shape

Use this structure unless LT asks for a different format:

**Decision:** Do / Do, but narrow / Spike first / Defer / Do not do
**Recommendation:** One plain-English sentence.

**Why**
- Strongest reason 1
- Strongest reason 2

**Cost**
- Time, complexity, maintenance, attention, or coordination cost.

**Risk**
- What could go wrong or what would become harder later.

**Open Questions**
- Only questions that could materially change the decision.

**Next Move**
- The smallest concrete action that advances or closes the decision.

**Confidence:** High / Medium / Low

Keep it short by default. Expand only when the decision is high-risk, cross-project, or governance-affecting.

Evaluation Rules

• Evidence first: inspect named files, issues, PRs, docs, logs, or memory before asserting facts.
• Open questions do not block a recommendation by default. Recommend what to do now, then name which answers could reverse the call.
• Separate worth from feasibility: something can be feasible and still not worth doing.
• Separate taste from operating value: prefer user value, system reliability, maintenance reduction, and decision clarity over polish or novelty.
• Count attention as a real cost. LT time, future agent confusion, and process drag matter.
• Prefer the smallest reversible move when the upside is plausible but evidence is thin.
• Escalate to tbm-audit when the real question is correctness, regression risk, or proof.
• Escalate to tbm-adversarial-review when LT explicitly wants the idea attacked.
• Escalate to build lane only when LT asks to implement after the decision.

Confidence Rules

• High: direct evidence is available, tradeoffs are clear, and no material unknown could flip the recommendation.
• Medium: enough evidence exists to recommend, but one or two open questions could change scope or timing.
• Low: the recommendation is provisional because core facts are missing.

Boundary

This skill is for recommendation quality. It is not a code review, PR audit, deploy gate, market-research report, or brainstorming session unless LT explicitly asks for that mode.