Passing tests is not the same as completing the user's task.
The UI test may stop at a mock. The API test may never exercise authorization. The worker may never consume the queued job. The external service may never send the webhook that changes the user's state.
no-vibes defines the user-visible outcome, traces the critical end-to-end flow, and reports what was verified, inferred, not verified, or blocked.
Install
Install with the Skills CLI:
npx skills add Lum1104/no-vibes
Install globally for all projects:
npx skills add Lum1104/no-vibes -g
Then invoke it explicitly when the outcome matters:
Use $no-vibes to implement subscription cancellation and verify the real user flow.
Before / after
Before
Done. The cancellation endpoint is implemented, all unit tests pass, and the app builds successfully.
What is missing: no cancellation was sent to the billing provider, no webhook was processed, and no loss of premium access was observed.
After
The implementation and local checks are complete. The API authorization and entitlement update were verified locally. The provider cancellation and webhook path used mocks, so the subscription flow is not verified end to end.
The second report is less triumphant and more useful. It tells you what is known, what is assumed, and what still needs to happen.
The core mechanism
1. Define the outcome
Write the requested result as one observable sentence:
A customer cancels a subscription and loses premium access.
2. Trace the shortest critical flow
Cancel click -> authorized API call -> billing provider cancellation
-> webhook -> entitlement update -> refreshed UI
The trace stays proportional to the task. It is not a diagram of the whole system.
3. Label the evidence
| Status | Meaning |
|---|
| Verified | The claim itself was directly observed with a relevant check in a named environment |
| Inferred | Supported by evidence, but not directly observed |
| Not verified | The claim was not exercised; available evidence covers only a narrower proxy |
| Blocked | A concrete dependency, permission, environment, or safety boundary prevented verification |
A unit test can verify the behavior it directly exercises. It cannot establish a broader deployed flow or external side effect that it never observed.
4. Apply the completion gate
The agent may call the outcome complete only after observing it end to end in an environment representative of that claim. If an essential boundary was mocked, skipped, or unavailable, it narrows the claim instead of upgrading confidence.
What the final report looks like
Outcome: A customer cancels and loses premium access.
Verified: API authorization and entitlement update in the local stack.
Inferred: The refreshed UI will hide premium controls after entitlement refresh.
Not verified: Live provider cancellation and webhook delivery.
Blocked: No provider sandbox credentials were available.
Conclusion: Implementation is complete; the end-to-end outcome is not verified.
Empty lines can disappear. An unverified essential boundary cannot.
Use it for
- Features that cross UI, API, database, queue, worker, or external-service boundaries.
- Permission, migration, billing, email, and background-processing changes.
- Fixes whose success depends on deployed configuration or durable side effects.
- Completion reviews where “tests pass” is doing too much argumentative work.
Explicit prompts:
Use $no-vibes before coding this password-reset flow.
Use $no-vibes to audit whether this PR proves the requested outcome.
Use $no-vibes when you report completion; separate observation from inference.
Non-goals and limits
- It does not replace tests, builds, static analysis, or code review. It states what each one proves.
- It does not demand production access or unsafe verification. Unavailable checks become blocked.
- It does not turn a small local edit into an architecture exercise. Trace only material boundaries.
- It cannot verify an environment the agent cannot observe. Its value there is an honest gap, not invented certainty.
The skill
The full agent-facing workflow lives in SKILL.md. The repository is intentionally small: instructions only, with no runtime service.
Related skills
| Skill | Use it when |
|---|
bet-on-it | A diagnostic change needs a prediction recorded before the result |
prove-me-wrong | A current claim needs an active attempt to falsify it |
archaeologist | Repository history may explain unusual code or constrain a change |
red-button | A high-impact operation deserves scenario-specific safeguards |
Each repository is standalone. Install only the behavior you want.
License
MIT © 2026 Lum1104
@lum1104