Decision Discipline Framework

Decision Discipline

by HoangNguyen0403 · MIT license · ★ 569 on GitHub

Decision Discipline cover

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,…

---
name: common-decision-discipline
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.
guardrail: true
metadata:
  triggers:
    files: []
    keywords:
      - decision brief
      - delivery contract
      - compare approaches
      - evidence ledger
      - approval state
      - option trade-offs
      - shape a direction
---

# Decision Discipline

Overview

Trustworthy decisions are sized to the work, grounded in evidence, and approved on the record.

Manual install (npx, ZIP)
Claude Codenpx skills add HoangNguyen0403/agent-skills-standard --skill common-decision-discipline -g -a claude-code
Claude Code (degit)npx degit HoangNguyen0403/agent-skills-standard/skills/common/common-decision-discipline#develop ~/.claude/skills/common-decision-discipline
Claude.ai / desktopZip the folder and upload it under Settings → Capabilities → Skills.
Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

  • SKILL.md4.0 KB
Read SKILL.md here
HoangNguyen0403/develop1 file shown
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, or unknown.
  • Read the smallest useful set of code, tests, docs, and existing docs/brd|prd|srs before 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-autonomous and continue; tier=high still 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 approval is incomplete.
  • No reopened decisions: settled facts are carried forward, not re-asked.

References

1---
2name: common-decision-discipline
3description: 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.
4guardrail: true
5metadata:
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 
22Trustworthy 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 
76Stop 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](references/contract-template.md)
88- [Evidence Ledger](references/evidence-ledger.md)
89- [Option Card](references/option-card.md)
90 
View all files on GitHub →

Details

License
MIT
Stars on the repo
★ 569
Checked
Source
HoangNguyen0403/agent-skills-standard ↗
Creator
HoangNguyen0403 · 21 listings
View creator

Similar skills

See all →
SkillImplement Specmattpocock/skills · by mattpocockImplement the result of /to-spec and /to-tickets in code.★ 267k GitHub starsSkillAcademy Guideanthropics/skills · by anthropicsStop 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.★ 178k GitHub starsSkillFeature Request Prioritizerphuryn/pm-skills · by phurynAnalyze 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.★ 26.6k GitHub starsSkillAdvocacy Program Designeraaron-he-zhu/aaron-marketing-skills · by aaron-he-zhuUse 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分享/内部分享计划/披露合规★ 2.9k GitHub starsSkillModel-Driven App Buildermicrosoft/power-platform-skills · by microsoftBuilds 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.★ 954 GitHub starsSkillCinetic Motion EngineLeonxlnx/cinetic · by LeonxlnxDirect, build and render premium cinematic motion design from code — launch films, product and feature videos, looping feature animations for landing pages and social, logo stings and reveals, UI walkthroughs, app demos, kinetic type, teasers, trailers, intros and promo clips. Use this whenever the user wants any video, animation, motion graphic or animated demo made with Remotion, HyperFrames, HTML/GSAP or React, or asks to storyboard, time, score, render, polish or critique one — even if they only say "make a video about X", "animate this feature" or "we need a launch clip". It supplies concept and copy discipline, type and colour taste that defers to a supplied brand, a beat-locked timeline that drives both picture and a code-made soundtrack, choreography and transition craft, real product UI in motion, film-grade finishing (true motion blur, no banding, BT.709, sync-checked mux) and a measured self-critique loop on contact sheets and renders.★ 347 GitHub stars

More from HoangNguyen0403

SkillAndroid Test WriterHoangNguyen0403/agent-skills-standard · by HoangNguyen0403Write Android unit, Compose UI, and Hilt-integrated tests. Use when designing test behavior with MockK or coroutine test utilities; defer database/WorkManager-specific recipes to the owning feature skill.★ 569 GitHub starsSkillArchitecture Diagram DesignerHoangNguyen0403/agent-skills-standard · by HoangNguyen0403Draws architecture diagrams as editable draw.io files with a fixed house style, C4 levels, evidence-tagged shapes, and optional multi-view identity checks. Use when producing a system context, container, component, deployment, data flow, sequence, state, or ERD, or redrawing an ASCII or Mermaid one.★ 569 GitHub starsSkillCode Review ExpertHoangNguyen0403/agent-skills-standard · by HoangNguyen0403Conduct high-quality, persona-driven code reviews. Use when reviewing PRs, critiquing code quality, or analyzing changes for team feedback.★ 569 GitHub starsSkillCybersecurity Framework MapperHoangNguyen0403/agent-skills-standard · by HoangNguyen0403Maintains sparse, reviewable cybersecurity framework edges with versioned IDs, relation, rationale, source, and review status. Use when mapping exercise observations or procedures to NIST, ATT&CK, or another named framework.★ 569 GitHub starsSkillFlutter Robot Pattern TestsHoangNguyen0403/agent-skills-standard · by HoangNguyen0403Write unit, widget, and integration tests with robot patterns, widget keys, and Patrol in Flutter. Use when implementing test behavior; defer CI-only configuration without test changes.★ 569 GitHub starsSkillGo Unit Test BuilderHoangNguyen0403/agent-skills-standard · by HoangNguyen0403Write unit tests with table-driven patterns and interface mocking in Go. Use when writing Go unit tests, table-driven tests, or using mock interfaces.★ 569 GitHub stars