Skip to content

vt-c-pov

Deliver a project-grounded, grade-first adoption verdict (Adopt / Trial / Hold / Reject / Not-our-problem) for external tech, libraries, patterns, or platforms — grounded against this toolkit's actual stack and conventions, not in the abstract. Use when triaging an intake/pending/ candidate, following up a /vt-c-repo-evaluate or /vt-c-content-evaluate discovery, or as a mid-session "second opinion".

Plugin: core-standards
Category: Other
Command: /vt-c-pov

/vt-c-pov — Project-Grounded Adoption Verdict

Turn an open question about external tech into a decided verdict with an explicit handoff — grounded against what this toolkit actually is, not an abstract "it depends". vt-c-pov owns the 5-grade adoption contract; the discovery skills (/vt-c-repo-evaluate, /vt-c-content-evaluate) hand off here for the graded decision (SPEC-145 Decision 4).

When to Use

  • Triaging an intake/pending/ candidate that needs an adopt/reject call.
  • Following up a /vt-c-repo-evaluate or /vt-c-content-evaluate run that surfaced a pattern but stopped short of a graded verdict.
  • A mid-session "second opinion" on a library, framework, pattern, or platform you're about to reach for (no-arg invocation).
  • Deciding whether an external thing is even our problem (toolkit) vs. a consuming product repo's.

Prerequisites

  • Runs anywhere; a git repo enables the shared repo-profile cache but is not required (degrades to fresh derivation — see references/repo-profile-cache.md).
  • No external network is strictly required, but the External floor is stronger with WebSearch/WebFetch available.

Execution

Step 1 — Intake the candidate

Resolve what is being evaluated from the argument (a URL, a pattern description, or — with no argument — the current session's implicit subject). See references/intake.md for the three arg forms. If the candidate is genuinely ambiguous, ask one clarifying question via AskUserQuestion before grounding — never guess the subject.

Step 2 — Classify reversibility (Tier)

Classify how hard the adoption would be to undo. --tier N overrides; otherwise infer:

Tier Reversibility Examples Ceremony
1 Easily reversible a doc nudge, a reference file, a single additive prose edit light grounding, no ADR
2 Moderate a new skill, a script, a new agent persona both floors mandatory
3 Hard to reverse a namespace change, a workflow-gate change, a new runtime/external dependency both floors + /vt-c-adr on a decided verdict

Step 3 — Two-Floor grounding (both mandatory)

A verdict requires both floors established. If either cannot be established, the verdict is Hold (insufficient grounding) — never a guessed grade. Full algorithm in references/method.md.

Project floor — is this a fit for our toolkit as it actually is? First get the question-agnostic project profile from the shared cache, then dispatch the project-grounding and precedent scouts on top of it:

TOOLKIT_ROOT="<absolute path of the toolkit root (the dir containing plugins/)>"
python3 "$TOOLKIT_ROOT/plugins/core-standards/scripts/repo-profile-cache.py" get
  • HIT → load the profile JSON that follows; skip derivation.
  • MISS → dispatch repo-profiler to derive it, write its JSON to the printed path, then put it (separate Bash call — re-set TOOLKIT_ROOT).
  • NO-CACHE → derive fresh for this run, skip put.

Then dispatch, read-only: project-grounding-scout (does it fit our stack/conventions/coverage?) and precedent-activity-scout (have we already decided this, or built adjacent coverage?). V025 grounding sources: README.md, AGENTS.md, CLAUDE.md, docs/concepts/, docs/decisions/, docs/solutions/patterns/, intake/processed/ — plus PRODUCT-VISION.md / docs/architecture/ if present (skip silently when absent).

External floor — is the thing itself sound? Dispatch external-evidence-researcher: maturity, maintenance cadence, license compatibility, security posture. It MUST NOT embed any credential or secret into the grounding (Constitution I) — see references/boundaries.md.

Step 4 — Emit the grade-first Verdict Contract

Lead with the grade, then the evidence. See the contract shape below and references/invocation.md for handoff routing.

Verdict Contract (grade-first)

VERDICT: <Adopt | Trial | Hold | Reject | Not-our-problem>   (Tier <1|2|3>)

Candidate:     <what was evaluated>
Project floor: <fit against our stack/conventions/coverage — 1-3 lines>
External floor:<maturity / license / maintenance / security — 1-3 lines>
Rationale:     <why this grade, decisively>
Handoff:       <the recommended next command — see routing below>
Grade Meaning Default handoff
Adopt Bring it into the toolkit scope clear → /vt-c-spec-from-requirements; fuzzy → /vt-c-shape
Trial Time-boxed experiment first /vt-c-quickfix
Hold Right idea, wrong time / insufficient grounding none (re-open trigger noted)
Reject No Tier-3 → optional /vt-c-adr to record why
Not-our-problem Belongs to a consuming product repo, not the toolkit flag target repo/namespace

Any verdict may optionally hand off to /vt-c-compound to capture the reasoning as a durable learning (Constitution III).

Integration Points

  • Consumes the discovery output of /vt-c-repo-evaluate (patterns + next steps) and /vt-c-content-evaluate (coverage gaps). Those skills nudge here for the graded verdict; vt-c-pov is the verdict authority (anti-duplication, Decision 4).
  • Cache: shares scripts/repo-profile-cache.py with any future repo-grounding consumer (US-2). Resolved via TOOLKIT_ROOT, never copied.
  • Handoffs: /vt-c-spec-from-requirements, /vt-c-shape, /vt-c-quickfix, /vt-c-adr, /vt-c-compound (routing in references/invocation.md).

Edge Cases

  • No git repo / cache unavailable → derive the project profile fresh; never stall on the cache.
  • Only one floor establishable → Hold, stating which floor is missing.
  • Ambiguous subject → one AskUserQuestion, then proceed.
  • Candidate is really a product concern → Not-our-problem, name the target repo/namespace (aligns with the no-cross-repo-specs rule).

Anti-patterns

  • Abstract verdict — never grade without the Project floor; "it depends" is not a verdict. A verdict is decided or it is Hold.
  • Verdict as a gate — vt-c-pov produces a recommendation, not a workflow gate; it does not block /vt-c-activate (Constitution II reconciliation, see references/boundaries.md).
  • Credentials in grounding — the external researcher never embeds secrets (Constitution I).
  • Hardcoded cache path — always resolve the shared script via TOOLKIT_ROOT; never copy it per-skill (AD-2).

Success Criteria

  • The output leads with one of the five grades and a Tier.
  • Both floors are addressed (or Hold explains which is missing).
  • A concrete handoff command is named.
  • The three calibration cases classify correctly (tests/test-pov-calibration.sh, HARD GATE).