Intake — the three argument forms

vt-c-pov accepts the candidate in one of three forms. Resolve which one you have before grounding.

1. A URL / repo reference

/vt-c-pov https://github.com/org/thing

• Treat the URL as the External-floor primary source.
• If this follows a /vt-c-repo-evaluate run on the same URL, reuse that run's discovery output (patterns, safety level, next steps) instead of re-deriving — vt-c-pov consumes that discovery (Decision 4). Do not re-clone; the verdict layer is API/metadata-level.

2. A pattern / capability description

/vt-c-pov "persona-selection gates for the review dispatcher"

• The candidate is a pattern or capability, possibly with no single URL.
• External floor draws on the researcher's web evidence for the general technique; Project floor is the dominant signal (does this pattern fit our workflow?).
• This is the common form when triaging an intake/pending/ proposal or an idea raised mid-conversation.

3. No argument — mid-session "second opinion"

/vt-c-pov

• The subject is the thing the current session is implicitly about to adopt (a library you were about to add, an approach you were about to commit to).
• State the inferred subject back in one line before grounding, so the user can correct it. If the session gives no clear subject, ask one AskUserQuestion to name it — never invent one.

Optional flag

• --tier N (N ∈ {1,2,3}) forces the reversibility tier instead of inferring it. See method.md.

What intake is NOT

• Not a re-run of discovery. If /vt-c-repo-evaluate or /vt-c-content-evaluate already discovered the candidate, start from their output. vt-c-pov adds the graded verdict, it does not repeat the scan.