跳到主要内容
知仓学习社ZHICANG

vc-feasibility-test

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 …

读文件执行命令联网无严重或高危命中withkynam/vibecode-pro-max-kit

它会碰到什么

扫了多少2 个文本文件,16 KB
它会碰到什么读文件执行命令联网
命中总数2 处
命中统计严重 0 · 高 0 · 中 1 · 低 1

这个仓库里自带 3 个测试样本文件(有些技能仓会放故意的恶意样本做演示),它们不计入上面的能力与命中。

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

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

  1. Read the hypothesis from the VC-FEASIBILITY-PROBE-NEEDED signal
  2. Pick the probe family (1–8) and its cost class
  3. 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.

  1. Design the minimal probe within that family
  2. Run the probe empirically — capture actual output, not expected output
  3. Analyze the evidence: does it confirm or refute the hypothesis?
  4. Assign a verdict: VIABLE | NOT-VIABLE | INCONCLUSIVE
  5. 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).

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。