A PROCESS YOU CAN EXPLAIN

An idea becomes useful through a clear next step.

The Vabes method connects the goal, feature map, specification, queue, implementation and acceptance. Use its structure or keep your own documents and tools. Obsidian is optional.

From an idea through a plan to a product.

EviSpec first — then the work.

Worked example · illustrative

Find a project without a long scroll.

A person has many projects and wants to find one by part of its name. This is a reusable planning pattern, not a claim about a completed customer project.

Goal and brief. “Find a project by name without scrolling the full list.” Keep existing data and controls; creating or deleting projects is outside this change.
Feature map. Record one feature, F-SEARCH, with an owner and acceptance checks. Keep the map as the source of scope instead of adding a second competing plan.
Small specification. Search part of a name without case sensitivity. Clearing the field restores the list. No matches produces a clear message. Keyboard access and existing project buttons still work.
Bounded queue. Prepare one task: add the field and filter existing rows. Review is a separate step. Sorting, saved filters and new project actions go into later tasks.
Supported execution. Use the configured supported runner with agreed files and permissions. A changed requirement returns to the plan; a block produces a concrete question rather than endless retries.
Checks and review. Try a partial name, mixed case, an empty query and no match. Use the keyboard. Verify project controls after filtering and confirm no project was created, removed or started.
Owner decision and record. Show the result and evidence against the checks. The owner accepts it, requests a bounded correction or leaves it unaccepted. Record the decision, report and next step in the same work history.

A brief you can edit.

Goal: the useful change.
Scope: what is included and preserved.
Acceptance: observable checks.
Authority: what can proceed and what needs a decision.
Handoff: result, evidence, limits and next step.

A short text file or your existing tracker can hold this. The method does not require a particular editor, model or vault.

Tools support the process.

A runner performs supported work; a review inspects evidence; the owner keeps sensitive decisions. Permissions, budgets, STOP and HOLD remain effective. Adding a skill or changing a model does not expand authority.

Read the practical field guide →

Reviewed catalog · planned

Recommendations need a provenance trail.

The future skills, plugins and prompts catalog is separate from supported connectors. An entry needs its purpose, publisher, source repository, checked version, review date, permissions, dependencies, conflicts and limitations. An update needs another review; changed code does not silently inherit trust.

Installation will require an explicit choice about access. Reporting a problem, withdrawing a recommendation and disabling a connection belong to that design. No automatic installation or guarantee of harmlessness is made here.

Plan your first loop Check supported features →