| name | vc-feasibility-test |
| description | Use when a SPEC, INNOVATE, or VALIDATE (Layer 2) approach hinges on an unverified runtime/library/external mechanism: run a probe from the 8-family taxonomy and produce a VIABLE/NOT-VIABLE/INCONCLUSIVE VERDICT artifact. |
| argument-hint | [hypothesis] [task-folder] [probe-family] |
| trigger_keywords | feasibility, spike, verify assumption, probe mechanism, empirical check, unverified mechanism, does this work, runtime quirk, api shape check |
| layer | contract |
| metadata | {"author":"vibecode-pro-max-kit","version":"2.0.0"} |
vc-feasibility-test
Output style: Follow process/development-protocols/communication-standards.md — answer-first, plain language, no unexplained jargon, TL;DR on long responses.
One-shot empirical probe skill. Used when SPEC or INNOVATE encounters an approach
hinging on an unverified external/runtime/library mechanism — the question is
"does this mechanism actually work the way the design assumes?", asked
before the decision locks.
Boundary vs vc-test-coverage-plan
These two skills are complementary and must not be confused:
vc-feasibility-test (this skill) = PRE-decision. "Does the mechanism work at
all?" Run before SPEC/INNOVATE locks an approach, when the answer is unknown.
Output: a one-shot VERDICT artifact.vc-test-coverage-plan = POST-plan. "How do I cover this blast radius across
the 4 test tiers?" Run after a plan exists, when the design is already chosen.
Output: a per-area tier table.
If the approach is already decided and you are assigning test tiers → use
vc-test-coverage-plan. If you cannot decide because a mechanism is unverified →
use this skill first.
When To Invoke
- When vc-spec-agent, vc-innovate-agent, or a vc-validate-agent Layer 2 dimension agent emits
VC-FEASIBILITY-PROBE-NEEDED
- When a mechanism cannot be verified from source code alone
- One-shot: not an iterative loop (use vc-autoresearch for iteration)
Skill Executor
Always executed by vc-debugger (via the VC-FEASIBILITY-PROBE-NEEDED signal routing
in orchestration.md). SPEC, INNOVATE, and VALIDATE Layer 2 agents do not run probes themselves.
Probe-Method Taxonomy (pick one family)
Every probe belongs to one of these 8 families. Name the chosen family in the VERDICT.
Each family has a default cost/safety class (see next section) — the probe inherits it.
| # | Family | What it probes | Typical method | Default cost class |
|---|
| 1 | Local process / Node script | pure library/runtime behavior in isolation | run a .mjs/Bun script, regex/parse check, call the lib fn directly | cheap-local |
| 2 | Unit/integration test harness | behavior under the project's own test runner | pnpm --filter … test (Vitest) or bun test on a scratch case | cheap-local |
| 3 | tRPC / Prisma / DB query | route shape, query behavior, index/constraint semantics | hit a tRPC route or run a Prisma/raw-SQL query against a test DB | needs-container (only if it needs the live app DB) / else cheap-local |
| 4 | External API shape capture | real response shape/behavior of a 3rd-party API | one live request to OpenRouter / Stripe / Composio / Clerk / Bright Data | needs-live-provider |
| 5 | Container exec / internal-port curl | in-container service behavior, proxy injection, file-server, supervisord | docker exec … curl http://localhost:{port} on a disposable container | needs-container |
| 6 | Browser / CDP capture | anti-detect quirks, CDP events, SPA nav, popup behavior | Playwright/CDP client, page.on(...), snapshot | needs-browser |
| 7 | WS / SSE handshake & timing | gateway WS framing, SSE delivery/reconnect, JSONL shape | raw ws/EventSource client + frame/timing capture | needs-container (if against in-container service) / else cheap-local |
| 8 | Cloudflare worker runtime | KV staleness, step-replay/idempotency, edge JWT verify | wrangler dev + curl, deploy a throwaway worker | needs-cf |
If none of the 8 fit, the question is probably not a feasibility probe — reconsider
whether vc-research-agent (unknown context) or vc-test-coverage-plan (known
design) is the right tool instead.
Probe Cost / Safety Class (MANDATORY GATE)
Every VERDICT declares one cost class. The class governs whether the probe may run
unattended or needs explicit opt-in. A probe that cannot be run within its safety
gate produces an INCONCLUSIVE verdict — it is never silently skipped or faked.
| Cost class | Safety gate | If gate not met |
|---|
| cheap-local | none — run freely (local script, test harness, parse check) | n/a |
| needs-container | use a disposable container only. NEVER docker exec the shared dev container (app-*) or shared Postgres. Disposable live-E2E containers need the disposable-cleanup env gate enabled. | verdict INCONCLUSIVE, note "no disposable container available" |
| needs-live-provider | requires explicit double opt-in from the user before any billed/live 3rd-party call (OpenRouter, Stripe, Composio, Bright Data, Clerk). Default local mode is BYOK Mistral. | verdict INCONCLUSIVE, note "live-provider opt-in not granted" |
| needs-browser | a browser/CDP session must be available; never drive a shared user session | verdict INCONCLUSIVE, note "no browser session available" |
| needs-cf | a wrangler dev/throwaway-worker sandbox; never touch a deployed production worker | verdict INCONCLUSIVE, note "no CF sandbox available" |
The emitted VC-FEASIBILITY-PROBE-NEEDED signal SHOULD carry the anticipated cost
class so the orchestrator can resolve the opt-in gate before dispatching vc-debugger
(see orchestration.md §VC-FEASIBILITY-PROBE-NEEDED Signal Routing).
Probe Execution Steps
- Read the hypothesis from the
VC-FEASIBILITY-PROBE-NEEDED signal
- Pick the probe family (1–8) and its cost class
- Confirm the safety gate for that cost class is met. If not → write an
INCONCLUSIVE verdict with the gate-not-met reason and stop. Do NOT escalate
to a higher-cost probe or run against a shared resource.
- Design the minimal probe within that family
- Run the probe empirically — capture actual output, not expected output
- Analyze the evidence: does it confirm or refute the hypothesis?
- Assign a verdict:
VIABLE | NOT-VIABLE | INCONCLUSIVE
- Write the VERDICT artifact to the active task folder
VERDICT Artifact Format
Filename: {slug}_FEASIBILITY_{dd-mm-yy}.md
Location: same active task folder as the SPEC/plan that triggered the probe
Required frontmatter fields (MUST be present — validated by validate-feasibility-verdict.mjs):
---
slug: [task-slug]
date: YYYY-MM-DD
verdict: VIABLE | NOT-VIABLE | INCONCLUSIVE
originating-phase: spec | innovate | pvl
---
The originating-phase: field is REQUIRED. Valid values:
spec — probe triggered by vc-spec-agent ([SP3])innovate — probe triggered by vc-innovate-agent ([I2.5])pvl — probe triggered by vc-validate-agent Layer 2 ([V2-PROBE])
Required sections (MUST be present — validated by validate-feasibility-verdict.mjs):
Hypothesis
One-sentence statement of what is being tested.
Mechanism Under Test
The specific external, runtime, or library behavior being probed.
Probe Family
One of the 8 families above (e.g. 5 — Container exec / internal-port curl).
Probe Cost Class
One of: cheap-local | needs-container | needs-live-provider | needs-browser | needs-cf.
State whether the safety gate was met.
Probe Method
The exact command(s) or steps run to test the hypothesis.
Evidence Captured
The raw output from the probe (trimmed to relevant lines). For an INCONCLUSIVE
gate-not-met verdict, state explicitly that the probe was not run and why.
Verdict
One of: VIABLE | NOT-VIABLE | INCONCLUSIVE
Resulting Design Constraint
The "action consequence" of the probe, split into three explicit parts:
- What this licenses: what the approach is now allowed to depend on.
- What this forbids: what the approach must NOT depend on.
- What remains uncertain (known-gap): what the probe did not settle and must be
treated as an open risk (for
INCONCLUSIVE, this is the main content).
Completion Signal
After writing the VERDICT artifact, emit:
VC-FEASIBILITY-VERDICT-READY: [verdict keyword] — [full path to VERDICT file]
Example:
VC-FEASIBILITY-VERDICT-READY: NOT-VIABLE — process/features/model-selector/active/model-selector_10-06-26/model-selector_FEASIBILITY_10-06-26.md
Re-spawn Handoff
The orchestrator reads the VERDICT artifact and extracts a Prior Feasibility: summary.
Format passed to the re-spawned agent:
Prior Feasibility: [hypothesis] — verdict: [VIABLE|NOT-VIABLE|INCONCLUSIVE] — licenses: [one line] — forbids: [one line] — uncertain: [one line]
Example:
Prior Feasibility: Does the gateway forward params.provider.sort? — verdict: NOT-VIABLE — licenses: nothing new — forbids: any approach depending on params.provider.sort being forwarded (the layer strips it) — uncertain: whether a different forwarding field survives
The re-spawned SPEC, INNOVATE, or VALIDATE agent reads this block and uses the verdict to lock or reject the approach. When originating-phase: pvl, the re-spawned vc-validate-agent resumes from V1 and records resolved probes in a ## Feasibility Probes Resolved subsection of the validate-contract (omitted when no probe ran).
