本文へ移動
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(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

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-standard5732026年10月12日 更新

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-standard5732026年10月12日 更新

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-standard5732026年10月12日 更新

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-standard5732026年10月12日 更新

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-standard5732026年10月12日 更新

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-standard5732026年10月12日 更新

HoangNguyen0403 のスキルをすべて見る

このスキルの問題を報告する