AgentSkillsCN

assumptions

创建并维护假设总账——一份持续记录假设、其置信度及验证状态的文件。适用于开始新阶段、在新的上下文窗口中恢复工作或当隐含假设可能引发偏差时使用。跟踪需求、架构及实施假设。

SKILL.md
--- frontmatter
name: assumptions
description: Create and maintain an Assumption Ledger — a persistent record of assumptions, their confidence, and validation status. Use when starting a new slice, resuming work in a new context window, or when implicit assumptions risk causing drift. Tracks requirements, architecture, and implementation assumptions.
argument-hint: "[create|update|review] [paste a card/spike verdict/slice summary or describe what changed]"

Assumption Ledger

Maintain a project-wide Assumption Ledger — durable memory of what was assumed, how sure we were, and how it was proved or disproved. Supports fresh context per slice without losing epistemic continuity.

Input

Mode + context: $ARGUMENTS

Modes:

  • •create — initialize a new ledger
  • •update — add/update assumptions from a card, spike verdict, or slice result
  • •review — summarize current ledger and recommend what to validate next

Ledger location

Default: docs/assumptions.md. If it exists, update — don't duplicate.

Ledger schema

Each entry MUST include:

  • •ID: A-### (stable identifier)
  • •Statement: one sentence, falsifiable if possible
  • •Type: Requirement | Architecture | Implementation
  • •Confidence: 0-100%
  • •Status: Proposed | Validated | Invalidated | Obsolete
  • •Introduced by: (card / spike / slice / commit)
  • •Validated by: (test name, command, spike evidence) — required for Validated/Invalidated
  • •Last reviewed: YYYY-MM-DD

Graduation Protocol

Assumptions track uncertainty and confidence. They are not permanent authority. When assumptions stabilize, promote them to their canonical home:

  • •Capsule promotion: durable semantic law or glossary boundary → docs/capsule.md or docs/capsule-<feature>.md
  • •Roadmap/decision promotion: strategic initiative choice with reversibility/rationale → docs/roadmap.md (and/or decisions log)
  • •Milestone promotion: temporary phase sequencing or deferment → docs/milestone.md
  • •Contract promotion: enforceable invariant now ready for code-level checks → /pragma:contract + tests

When promoted, keep the assumption entry for history and add a "Promoted to" reference with path/anchor.

Procedure

Mode: create

Create docs/assumptions.md with sections: Active (Proposed), Validated, Invalidated/Obsolete, Open Questions. Seed with 3-10 initial assumptions if obvious from capsule/card.

Mode: update

  1. •Extract assumptions from context ("ASSUMPTION:" lines in cards, spike verdicts, slice summaries)
  2. •Match against existing entries → update confidence/status/evidence. New → assign ID, add under Active.
  3. •Confidence < 70% → mark High Risk, recommend clarification or /pragma:spike
  4. •Disproved by spike/test → move to Invalidated, note "Replaced by A-###" if superseded
  5. •For any stabilized assumption, apply the graduation protocol and add cross-reference links to the promoted artifact

Mode: review

  1. •List Active (Proposed) sorted by: lowest confidence first, highest impact first
  2. •Recommend: /pragma:spike for unknowns, /pragma:card+/pragma:slice for E2E-validatable assumptions, /pragma:characterize for behavior already in code
  3. •Identify stale assumptions (not reviewed recently, weak evidence)
  4. •Identify promotable assumptions and their target authority document

Constraints

  • •No vague assumptions. "Should be scalable" → rewrite as falsifiable statement.
  • •Validated/Invalidated requires evidence. Cite test, command output, or spike verdict.
  • •Do not delete history. Invalidated assumptions stay recorded.
  • •Assumptions are not features. The ledger records knowledge state, not work.
  • •Do not treat assumptions as semantic authority. Durable definitions and laws must be promoted to capsule.

Output

  1. •The updated docs/assumptions.md diff summary
  2. •The top 3 highest-risk active assumptions
  3. •Promotion summary (assumptions promoted, with destination artifacts)
  4. •The recommended next step (often /pragma:spike or /pragma:card)
  5. •Lifecycle: State: governance, Next: /pragma:consult (or the explicitly recommended next step), Loop: /pragma:consult (default unless user explicitly continues directly)