Decision Discipline skill
Right-size, ground, and gate SDLC decisions with SNC-sized depth, said-vs-assumed write-back, an evidence ledger, honest option cards, recorded approval, and self-review.
by HoangNguyen0403·MIT license·★ 569 Stars on the repo·GitHub ↗
Use now
npx degit HoangNguyen0403/agent-skills-standard/skills/common/common-decision-discipline#develop ~/.claude/skills/common-decision-disciplineChecked ·commit develop
Files of Decision Discipline
SKILL.md
Show the full text90 lines
Decision Discipline
Priority: P0 (CRITICAL)
Trustworthy decisions are sized to the work, grounded in evidence, and approved on the record.
1. Size The Work
| SNC tier | Depth | Artifact |
|---|---|---|
tier=low (0-2) |
Quick | Contract in chat, no file; approval in the Handoff Payload |
tier=medium (3-4) |
Standard | Core brief file |
tier=high (5-6) |
Deep | Full brief; decompose multi-subsystem ideas first; optional specialist-architecture-guard review |
- Score with
common-task-complexity-routing; label as inference until scouted. The tier only rises once work starts. - A symptom without a root cause routes to
dev-fix; never compare fixes for an undiagnosed bug.
2. Shared Understanding
- Draft first, then write back two lists: You said and I assumed. Allow one correction round.
- Skip the write-back when outcome, constraints, non-goals, and acceptance criteria are already stated; confirm in one line.
- Reuse an accepted contract; never reopen it.
3. Evidence Ledger
- Tag every feasibility, AS-IS, or current-behavior claim:
confirmed(<path>),assumed, orunknown. - Read the smallest useful set of code, tests, docs, and existing
docs/brd|prd|srsbefore calling an option feasible. - Resolve what evidence can settle; label only what stays unknowable. Format:
references/evidence-ledger.md.
4. Questions
- Ask only when the answer changes the result, safety boundary, or public contract.
- Max 3 per round, each with a recommended default and 2-3 options.
- Never re-ask a settled fact. Never ask the operator to re-authorize approved work.
- For
operator_profile=business, every question is answerable by "go with your suggestion".
5. Options
- 0-3 options, only when a real choice exists. A single viable path is stated as the path, not padded.
- Each option card names its load-bearing assumption, first failure condition, worst plausible case, and cost to abandon (
references/option-card.md). - Recommend the smallest option that satisfies the contract. When a critical assumption is unresolved, recommend the option cheapest to abandon.
- Cut unrequested scope; keep all requested scope.
6. Approval State
approval: pending | approved(<who>, <YYYY-MM-DD>) | assumed-autonomous.- Interactive: end with "Reply ok or corrections". An ok approves only the artifact presented.
- Autonomous or channel mode without an interactive reply channel: set
assumed-autonomousand continue;tier=highstill blocks pending explicit human sign-off.
7. Self-Review Before Handoff
- Placeholders: TBD, TODO, empty sections.
- Contradictions between sections.
- Scope: one plan, or needs splitting.
- Ambiguity: a requirement with two readings; pick one and state it.
Red Flags
Stop when thinking: "too simple to need a brief", "they said implement, so skip intake", "it's a bug, pick a fix", "list three options to look thorough", "ask again to be safe", "they approved the idea, so the plan is approved". Each is a rationalization, not a reason.
Anti-Patterns
- No unlabeled claims: every AS-IS or feasibility statement carries an evidence tag.
- No padded options: never invent alternatives to reach three.
- No silent approval: a brief without
approvalis incomplete. - No reopened decisions: settled facts are carried forward, not re-asked.
References
| 1 | |
| 2 | name common-decision-discipline |
| 3 | description Right-size, ground, and gate SDLC decisions with SNC-sized depth, said-vs-assumed write-back, an evidence ledger, honest option cards, recorded approval, and self-review. Use when running brainstorm-feature, plan-feature, design-solution, or system-design-session. |
| 4 | guardrail true |
| 5 | metadata |
| 6 | triggers |
| 7 | files [] |
| 8 | keywords |
| 9 | - decision brief |
| 10 | - delivery contract |
| 11 | - compare approaches |
| 12 | - evidence ledger |
| 13 | - approval state |
| 14 | - option trade-offs |
| 15 | - shape a direction |
| 16 | |
| 17 | |
| 18 | # Decision Discipline |
| 19 | |
| 20 | ## **Priority: P0 (CRITICAL)** |
| 21 | |
| 22 | Trustworthy decisions are sized to the work, grounded in evidence, and approved on the record. |
| 23 | |
| 24 | ## 1. Size The Work |
| 25 | |
| 26 | | SNC tier | Depth | Artifact | |
| 27 | | --- | --- | --- | |
| 28 | | `tier=low` (0-2) | Quick | Contract in chat, no file; `approval` in the Handoff Payload | |
| 29 | | `tier=medium` (3-4) | Standard | Core brief file | |
| 30 | | `tier=high` (5-6) | Deep | Full brief; decompose multi-subsystem ideas first; optional `specialist-architecture-guard` review | |
| 31 | |
| 32 | Score with `common-task-complexity-routing`; label as inference until scouted. The tier only rises once work starts. |
| 33 | A symptom without a root cause routes to `dev-fix`; never compare fixes for an undiagnosed bug. |
| 34 | |
| 35 | ## 2. Shared Understanding |
| 36 | |
| 37 | Draft first, then write back two lists: **You said** and **I assumed**. Allow one correction round. |
| 38 | Skip the write-back when outcome, constraints, non-goals, and acceptance criteria are already stated; confirm in one line. |
| 39 | Reuse an accepted contract; never reopen it. |
| 40 | |
| 41 | ## 3. Evidence Ledger |
| 42 | |
| 43 | Tag every feasibility, AS-IS, or current-behavior claim: `confirmed(<path>)`, `assumed`, or `unknown`. |
| 44 | Read the smallest useful set of code, tests, docs, and existing `docs/brd|prd|srs` before calling an option feasible. |
| 45 | Resolve what evidence can settle; label only what stays unknowable. Format: `references/evidence-ledger.md`. |
| 46 | |
| 47 | ## 4. Questions |
| 48 | |
| 49 | Ask only when the answer changes the result, safety boundary, or public contract. |
| 50 | Max 3 per round, each with a recommended default and 2-3 options. |
| 51 | Never re-ask a settled fact. Never ask the operator to re-authorize approved work. |
| 52 | For `operator_profile=business`, every question is answerable by "go with your suggestion". |
| 53 | |
| 54 | ## 5. Options |
| 55 | |
| 56 | 0-3 options, only when a real choice exists. A single viable path is stated as the path, not padded. |
| 57 | Each option card names its load-bearing assumption, first failure condition, worst plausible case, and cost to abandon (`references/option-card.md`). |
| 58 | Recommend the smallest option that satisfies the contract. When a critical assumption is unresolved, recommend the option cheapest to abandon. |
| 59 | Cut unrequested scope; keep all requested scope. |
| 60 | |
| 61 | ## 6. Approval State |
| 62 | |
| 63 | `approval: pending | approved(<who>, <YYYY-MM-DD>) | assumed-autonomous`. |
| 64 | Interactive: end with "Reply ok or corrections". An ok approves only the artifact presented. |
| 65 | Autonomous or channel mode without an interactive reply channel: set `assumed-autonomous` and continue; `tier=high` still blocks pending explicit human sign-off. |
| 66 | |
| 67 | ## 7. Self-Review Before Handoff |
| 68 | |
| 69 | Placeholders: TBD, TODO, empty sections. |
| 70 | Contradictions between sections. |
| 71 | Scope: one plan, or needs splitting. |
| 72 | Ambiguity: a requirement with two readings; pick one and state it. |
| 73 | |
| 74 | ## Red Flags |
| 75 | |
| 76 | Stop when thinking: "too simple to need a brief", "they said implement, so skip intake", "it's a bug, pick a fix", "list three options to look thorough", "ask again to be safe", "they approved the idea, so the plan is approved". Each is a rationalization, not a reason. |
| 77 | |
| 78 | ## Anti-Patterns |
| 79 | |
| 80 | **No unlabeled claims**: every AS-IS or feasibility statement carries an evidence tag. |
| 81 | **No padded options**: never invent alternatives to reach three. |
| 82 | **No silent approval**: a brief without `approval` is incomplete. |
| 83 | **No reopened decisions**: settled facts are carried forward, not re-asked. |
| 84 | |
| 85 | ## References |
| 86 | |
| 87 | [Contract Templates] |
| 88 | [Evidence Ledger] |
| 89 | [Option Card] |
| 90 |
Discussion
Alternatives
Academy guideStop and check this skill before finishing any reply to a question about how to use Claude or a Claude product — it recommends matching courses, tutorials, and use cases from Claude Academy (academy.claude.com), Anthropic's learning hub. Trigger on: "how do I", "how can I", "getting started with", "what can Claude do", "teach me", "learn to use"; questions about artifacts, projects, skills, plugins, connectors, MCP; requests about rolling Claude out to a team, class, or organization; and any ask for training materials, onboarding content, or learning resources. Use it when the user is learning how to use a feature or product — not when they are mid-task and just want the task done. This skill composes with other skills: after consulting product documentation to answer how a Claude feature works, also check here for a matching course or tutorial — a docs-grounded answer and an Academy recommendation belong together. Only recommend on a strong match; never invent Academy content.
Analyze feature requestsAnalyze and prioritize a list of feature requests by theme, strategic alignment, impact, effort, and risk. Use when reviewing customer feature requests, triaging a backlog, or making prioritization decisions.
Advocacy program designerUse when the user asks to "design an employee advocacy program", "set up founder-led sharing", or "build a share kit for the team"; produces an advocacy program blueprint in two modes — participation-driven opt-in (default) or top-down assigned with its coercion and authenticity risks flagged — with a voluntary opt-in roster spec submitted as channel-registry proposal events, share kits with mandatory per-person variation, staggered human posting windows plus anti-pod guardrails (no coordinated identical reshares, no engagement rings), per-person material-connection disclosure lines per FTC and 《互联网广告管理办法》, and a Slack/Teams distribution spec. Not for paid creator campaigns — use campaign-planner. 员工倡导/创始人IP分享/内部分享计划/披露合规app-builder — intent → model-driven appBuilds and edits a model-driven Power Apps app from a natural-language intent — tables, columns, relationships, adaptive forms with sub-grids, views, Choice-column charts, business rules, business process flows, generative page intents for overview/dashboard surfaces (page `.tsx` generated in generate-pages after plan approval), and an app module + sitemap — via the headless cds-maker-sdk. Runs an interactive, multi-turn authoring flow (env selection, jobs-to-be-done first, then design-only App Spec authoring across confirmed levels, guardrail lint, plan-mode approval, generate-pages, full build) and a narrated build, and can download a deployed app back into an editable spec to change it. Use when the user says "build an app for X", "create a model-driven app", "make me an app to manage Y", "add a business process flow", or "edit/add to my app". This skill stands alone and does not require /genpage — but for a standalone generative page added to an app that already exists, use /genpage instead.Browse more free Claude skills or everything in Product.