| name | source-grounded-decisions |
| description | Use before a version- or spec-sensitive decision — framework or library code, a CLI flag, a config schema field, or a named standard/edition — when correctness depends on the exact version. Detect the version, ground the decision in the authoritative source, and cite it; flag the assumption when no source is available. |
| metadata | {"short-description":"Ground version- and spec-sensitive decisions in cited sources"} |
Source-Grounded Decisions
Do not implement version- or spec-sensitive details from memory — training data goes
stale and APIs, flags, and schemas change. Ground the decision in an authoritative
source the user can check, and cite it. Composes with research-verification-gate
and claim-preserving-writing.
When to use
- writing framework or library code where the version determines the correct pattern
- a CLI flag, environment variable, or config field whose name or behavior is
version-specific
- a named standard, schema, or data edition (an API field, a format, a regulation)
- a research step whose correctness depends on the exact tool or data version
When not to use
- version-agnostic logic (loops, data structures, renames, moving files)
- the user explicitly wants speed over verification
Method
- Detect the version. Read the authority pointer for the task: the dependency
file (
package.json, pyproject.toml, go.mod, Cargo.toml, Gemfile) for
code; --version or the man page for a CLI; the named edition for a standard.
State it explicitly, e.g. DETECTED: React 19.1, Vite 6.2. If it is missing or
ambiguous, ask rather than guess — the version determines which pattern is right.
- Fetch the authoritative source for the specific feature: the relevant
official doc page, spec section, or man entry, pinned to the detected version.
Prefer official docs, then the primary spec, then maintainer source, over blog
posts or memory.
- Ground the decision in what the source actually says; do not pattern-match
from memory or carry a pattern across versions.
- Cite or flag. Cite the source (page or section, and version) next to the
decision. If no authoritative source is reachable, mark the decision
UNVERIFIED — assumed rather than presenting it as established.
Output contract
Next to each version-sensitive decision, show the detected version and the cited
source, or an explicit UNVERIFIED — assumed flag.
Guardrails
- ask for the version rather than guess when it is ambiguous
- one authoritative source beats three blog posts
- never present an unverified version-sensitive choice as established — flag it
Recommended templates
When this skill is involved, consider these workflow templates (install via
the workflow-templates artifact profile, or --with-deps to pull backing skills):
reversible-decision-memo -- Evidence-grounded decision record with named alternatives, source-cited rationale, reversibility class and trip-wires, and a fresh-context adversarial confirmation before the decision stands.
