跳到正文
cccskills
免费在 GitHub 公开

common-decision-discipline

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.

中文简介正在准备中。当前显示原文说明。

实测评分 未实测

查看安装方法

包含的文件(5)

  • SKILL.md5.6 KB
  • evals/evals.json6.8 KB
  • references/contract-template.md754 B
  • references/evidence-ledger.md639 B
  • references/option-card.md532 B

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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 tierDepthArtifact
tier=low (0-2)QuickContract in chat, no file; approval in the Handoff Payload
tier=medium (3-4)StandardCore brief file
tier=high (5-6)DeepFull brief; decompose multi-subsystem ideas first; optional specialist-architecture-guard review
  • Score with common-task-complexity-routing; label as inference until scouted.
  • Downward complexity reassessment requires documented new evidence (e.g., scouted blast radius proves isolated scope), never to bypass unresolved risk, required approvals, or the sensitive-change risk floor.
  • Sensitive-Change Risk Floor: Auth, money, data integrity, or trust boundaries enforce minimum tier=medium regardless of arithmetic SNC total; non-zero novelty or spread (S≥1 or N≥1 with C=2) escalates to tier=high.
  • Low-Risk Maintenance: Sufficiently specified routine fixes or maintenance may use an in-chat contract rather than creating BRD/PRD/SRS files. Preserve full traceability for governed or high-risk delivery.
  • Downstream specialist workers execute against their assigned briefs; do not reload or repeat parent intake in specialists.
  • 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. Publication vs Activation

  • Record repository_status and activation_status separately; use not_required when activation is outside the contract.
  • Do not require an external VM/runtime artifact for approved repository-only publication unless the contract requires it.
  • After approval, continue through the accepted deliverable; do not ask to continue at each phase boundary.
  • Publication approval never grants merge, deploy, or runtime-change authority. Gate consequential actions on explicit matching approval and scope.

8. Self-Review Before Handoff

  • Check placeholders (TBD, TODO), contradictions, multi-plan scope, and two-reading ambiguities.

Red Flags

Stop when thinking: "too simple to need a brief", "they said implement, so skip intake", "list three options to look thorough", "approval to publish means deploy". 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.
  • No scope transfer: publication approval does not authorize merge, deployment, or runtime activation.

References

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Upgrade an Android project to Android Gradle Plugin (AGP) 9. Use when migrating to AGP 9, updating Gradle build files, migrating to built-in Kotlin, or adopting the new AGP DSL.

中文简介正在准备中。当前显示原文说明。

HoangNguyen0403/agent-skills-standard5812026年10月24日 更新

Apply Clean Architecture layering, modularization, and Unidirectional Data Flow in Android projects. Use when setting up project structure, placing code in layers, configuring feature/core modules, or implementing UDF patterns; defer Compose state and ViewModel/StateFlow implementation to their specific skills.

中文简介正在准备中。当前显示原文说明。

HoangNguyen0403/agent-skills-standard5812026年10月24日 更新

Implement WorkManager and background processing correctly on Android. Use when creating Worker classes, scheduling tasks, choosing between WorkManager and Foreground Services, or setting up Hilt in workers; defer FCM and notification delivery to android-notifications.

中文简介正在准备中。当前显示原文说明。

HoangNguyen0403/agent-skills-standard5812026年10月24日 更新

Build high-performance declarative UI with Jetpack Compose. Use when writing Composable functions, optimizing recomposition, hoisting state, or working with LazyColumn and side effects; defer deep-link and navigation routing to android-navigation.

中文简介正在准备中。当前显示原文说明。

HoangNguyen0403/agent-skills-standard5812026年10月24日 更新

Migrate an Android XML View to Jetpack Compose following a structured 10-step workflow. Use when converting XML layouts to Compose, setting up Compose in an existing View-based project, or incrementally adopting Compose.

中文简介正在准备中。当前显示原文说明。

HoangNguyen0403/agent-skills-standard5812026年10月24日 更新

Write correct coroutine scopes, lifecycle collection, and dispatcher injection in Android production code. Use for suspend functions, coroutine scopes, and dispatcher mechanics; defer ViewModel StateFlow/LiveData architecture, Fragment lifecycle recipes, persistence/notifications, and unit-test recipes to their specific skills.

中文简介正在准备中。当前显示原文说明。

HoangNguyen0403/agent-skills-standard5812026年10月24日 更新

查看 HoangNguyen0403 的全部技能

报告此技能的问题