Skip to content

Method — Tier classification + Two-Floor grounding

The vt-c-pov decision algorithm. Read this for the mechanics behind the SKILL.md's Execution steps.

Tier classification (reversibility)

Tier answers "how expensive is it to undo this adoption?" — it sets how much grounding and ceremony a verdict needs.

  • Tier 1 — easily reversible. A doc, a reference file, a nudge, one additive prose edit. Reverting is a one-line git revert-scale change. Light grounding; no ADR even on a decided verdict.
  • Tier 2 — moderate. A new skill, a script, a new agent persona, a new test. Reverting means removing a self-contained unit and its registration. Both floors mandatory.
  • Tier 3 — hard to reverse. A namespace change, a workflow-gate change, a new runtime or external dependency, anything other skills will come to depend on. Both floors mandatory and a decided verdict (Adopt or Reject) routes to /vt-c-adr so the reasoning is durable.

--tier N forces the tier. Otherwise infer from the blast radius of undoing it, and when in doubt, tier up (more grounding is cheap; an unrecorded hard-to-reverse decision is not).

Two-Floor grounding

Both floors must be established before a grade is emitted. "Established" means you have concrete evidence, not an impression. If a floor cannot be established from available sources, the verdict is Hold naming the missing floor — never a guessed grade.

Project floor — "is this a fit for our toolkit as it actually is?"

  1. Get the question-agnostic project profile from the shared cache (get → HIT/MISS/NO-CACHE; see repo-profile-cache.md).
  2. Dispatch project-grounding-scout read-only: does the candidate fit our stack, our vt-c-* conventions (SPEC-050), the workflow-gate model, and our composability principle? Would adopting it violate a locked convention?
  3. Dispatch precedent-activity-scout read-only: have we already decided this (docs/decisions/, docs/adr/, intake/processed/)? Do we already have adjacent coverage (docs/solutions/patterns/, existing skills) that makes this a duplicate?

The Project floor is what makes the verdict grounded rather than abstract — it is never optional.

External floor — "is the thing itself sound?"

Dispatch external-evidence-researcher read-only. Establish:

  • Maturity — version, age, adoption signal.
  • Maintenance — recent commit/release cadence, open-issue health.
  • License — compatible with our use (MIT/Apache/BSD fine; copyleft or non-commercial flagged).
  • Security posture — known CVEs, supply-chain hygiene, credential handling.

The researcher MUST NOT embed any credential/secret into the grounding (Constitution I; see boundaries.md).

From floors to grade

Project floor External floor Typical grade
Strong fit, no duplicate Sound Adopt
Fit but unproven for us Sound but we lack experience Trial
Fit but wrong time / blocked by an external trigger Sound Hold
Poor fit / violates a convention / duplicate (any) Reject
Fits a product repo, not the toolkit (any) Not-our-problem
Either floor not establishable Hold (name the gap)

The grade is a decision, stated first (grade-first contract). The floors are the evidence that justifies it.