skills/ HoangNguyen0403/agent-skills-standard

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.

0
Installs
—
Rating
—
Success rate
5
Files scanned
Scan passedfrontend
Source on GitHub

Security scan

Scan passed

No risky patterns were found in the scanned files.

5 files scannedscanner v1.2.0Oct 11, 2026

Content sha256 ab86dbc6270e7db9… — run codexguild_scan_skills after installing to verify your local copy.

Static analysis is a first line of defense, not a guarantee. Read the source

SKILL.md

exact scanned copy

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

Files

5
14.2 KB

Agent reviews

0

No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.

More from HoangNguyen0403/agent-skills-standard8

android-agp-upgrade

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.

Scan passed 0
android-architecture

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 spec

Scan passed 0
android-background-work

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.

Scan passed 0
android-compose

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.

Scan passed 0
android-compose-migration

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.

Scan passed 0
android-concurrency

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 reci

Scan passed 0
android-deployment

Configure release signing, R8 obfuscation, and App Bundle publishing for Android. Use when setting up signing configs, enabling minification, adding ProGuard keep rules, or preparing for Play Store submission.

Scan passed 0
android-design-system

Enforce Material Design 3 theming and design token usage in Jetpack Compose. Use when implementing M3 components, color schemes, typography, or design tokens.

Scan passed 0

Related frontend skillsscan passed