verify-intent

Files (1)

• SKILL.md

SKILL.md (first lines)

<what-to-do>

Load the active intent from `intent.md` in the project root first. That file is bound to this repository and remains the content authority even when `PATHMODE_API_KEY` is set. If the repository has no `intent.md`, ask the user which saved intent they mean and load it with `get_intent`. With a workspace connected, `get_current_intent` picks by a workspace heuristic and can return an intent unrelated to this repository.

Walk the user through the five verification dimensions below. Ask one question at a time. For each question, propose your best-guess answer based on the intent's outcomes and what's visible in the codebase (existing tests, observability hooks, CI config).

The five dimensions:

1. **Fastest check** — What's the quickest signal that the code is broken? (typecheck, single unit test, lint rule)
2. **Highest-confidence check** — What's the most reliable signal it actually works? (e2e test, integration test, manual flow)
3. **Manual fallback** — If automation isn't available, what's the 30-second manual check? (curl command, screen recording flow, console query)
4. **Observable shipped signal** — Once deployed, what tells you it's working in production? (metric, log pattern, user behavior change)
5. **What must not regress** — What existing behavior would a fix here accidentally break? (named cases the user worries about)

Hold the five answers until the loop is complete; do not spend five tool calls logging fragments. Then write them once to the structured `verification.checks` collection: `fastest`, `test` (the highest-confidence check), `manual`, `shipped-signal`, and `regression-guard`. When `intent.md` exists, call `intent_save` with the full updated spec (it writes the file and also syncs in connected mode). Only use `update_intent` when no local file exists. In team mode, add one consolidated `log_implementation_note` only when the session produced rationale or a tradeoff that the structured checks do not carry.

When all five are answered, summarize the loop:

```
Verification loop for this intent:
- Fastest: [command/check]
- Highest-confidence: [command/check]
- Manual fallback: [steps]
- Shipped signal: [metric/log]
- Must not regress: [named cases]
```

</what-to-do>

<supporting-info>

## Why five dimensions, not "tests"

A `verification` field that says "add tests" is a document, not a contract. It doesn't tell an implementation agent what to actually run, and it doesn't tell a reviewer what to check.

The five-dimension breakdown turns verification into something runnable:

- The agent knows the **fastest check** to run after every change → tight feedback loop
- The agent knows the **highest-confidence check** to run before declaring done → catches issues
- The user has a **manual fallback** when CI is broken or the test framework is mid-migration
- The team has a **shipped signal** to watch in production → closes the deploy-to-verify gap
- Everyone knows what **must not regress** → prevents the "fix that broke unrelated thing" pattern

## Concrete example

Intent: "Payment completes in under 3 seconds (p95)"

Bad verification: "Add a test for the payment timeout."

Good verification (five dimensions):

- Fastest check: `pnpm vitest run payment-timeout.test.ts` — 2s, runs locally on save
- Highest-confidence: `pnpm playwright test payment-flow.spec.ts` — 30s, hits the actual payment provider sandbox
- Manual fallback: Open `/checkout`, add a $1 item, complete payment, time the wall clock from "pay" click to confirmation screen
- Shipped signal: Datadog metric `checkout.payment.duration.p95` < 3000ms over 24h after deploy
- Must not regress: Refund flow (uses the same payment service); guest checkout (different code path that calls the same client)

The first version is a wish. The second version is a contract.

## Mode behavior

- **Repo-bound intent (local or connected)** — Write all five answers to `verification.checks` with one `intent_save`. The rendered `## Verification` section is the file projection of those structured checks.
- **Cloud-only intent** — Write all five answers with one `update_intent` call. `log_implementation_note` is for session narrative, not for a field that already exists.

## Pairing with other skills

- After `compile-intent` produces a spec, run `verify-intent` before treating the spec as agent-ready. A spec without a verification loop is not agent-ready.
- Before `handoff-intent`, check that the verification loop ran — if outcomes are claimed delivered but verification was never designed, that's a gap to surface.
- `review-against-intent` consumes the verification field to know what "delivered" means.

</supporting-info>

From pathmodeio/claude-plugin, MIT.

More from pathmodeio/claude-plugin