| name | relentless-vision-pursuit |
| description | Use for a recurring, generative pursuit run that closes the gap between what a project is today and the ideal its doctrine describes: fan-out audits of every surface against the applicable quality bar, vision-grounded ideation lenses, synthesis into a ranked move list with tier-board movement across runs, and a gated (never auto-released) work plan. Triggers: "run the vision pursuit", "what's the next best step toward the vision", "relentlessly improve this project", "audit the whole project against the ideal", "generate the next round of improvements".
|
| metadata | {"owner":"tze","authors":["tze","Claude Fable 5"],"status":"active","last_reviewed":"2026-07-27"} |
| compatibility | Needs repo-root access and doctrine (about/heart-and-soul/). Fan-out wants the Workflow tool and bd (beads); both degrade — small projects run audits inline sequentially, and without bd the ranked move list stays in the dossier.
|
Relentless Vision Pursuit
A recurring, generative audit loop. The goal is not to verify correctness
(that is ../project-review/SKILL.md) but to relentlessly close the gap
between what the project is today and the ideal its doctrine describes. Each
run produces new moves — never a re-filing of what a prior run already
found — and measures movement since the last run.
The posture, which every dispatched prompt inherits:
- Judge against the north star, quoted from the prior dossier or
re-derived from
about/heart-and-soul/vision.md. Verdicts are
gap-to-ideal, not pass/fail.
- Propose the ideal. Backward compatibility inside the project's own
surface is waived by default — redesigns and removals are in scope; note
migration cost, don't let it veto the move. External consumers' contracts
are never waived silently.
- Fewer new findings after a release is success, not failure. Report
tier movement prominently; never pad the move list to hit a count.
Do not use when
- Correctness or health question ("is it wired", "score this repo") →
../project-review/SKILL.md.
- One concrete feature to specify →
../project-feature-request/SKILL.md.
- Quick candidate brief with no orchestration →
../project-direction/SKILL.md
ideation focus mode.
- Sequencing already-approved work →
../project-direction/SKILL.md.
Phase 0 — Ground and scope (inline, before any fan-out)
- Doctrine. Read
about/heart-and-soul/ (vision, non-negotiables,
NOT-boundaries) plus any normative design-language or architecture spec
the project keeps. Absent → stop and recommend ../project-shape/
bootstrap: a pursuit without a vision is a random walk.
- Surface inventory. Enumerate from the project's source-of-truth
artifact for its type — route table for frontends, command tree for CLIs,
public API for libraries, module map from
about/lay-and-land/ otherwise
— never a directory listing. Group routes/modules into cohesive surfaces,
one agent each.
- Already-known ledger — the dedup input injected verbatim into every
prompt: prior pursuit dossiers (move lists + tier boards), open/in-flight
beads (
bd list --json), recently merged work on the audited surfaces,
and about/legends-and-lore/ideas-ledger.md. Compress to a bullet list:
"known and in-flight — do not re-report".
- Tier-board baseline from the newest prior dossier so this run reports
movement. First run: no baseline — say so, don't fabricate one.
- If a prior pursuit epic shipped since the last run, start with a scoped
../project-review/SKILL.md verification pass over the surfaces it
touched; only verified landings count as movement.
Phase 1 — Surface pursuit fan-out
One agent per surface, plus cross-cutting sweeps chosen for the project:
discoverability/shell, visual language, interaction speed, accessibility for
human surfaces; architecture seams, test rigor, operability for code
surfaces. Non-negotiables baked into every prompt:
- Hold the surface to the applicable bar:
/th-design (one relevant
subskill) for human-facing surfaces, /th-engineering for code-facing
ones.
- Judge against the quoted north star; every finding cites
file:line.
- Every surface gets a verdict tier —
world-class | solid | functional | weak | broken — a gap paragraph, and
a ranked move list.
- The already-known ledger is included verbatim; duplicates are dropped by
the agent, not the synthesizer.
Phase 2 — Vision pursuit lenses (concurrent with Phase 1)
Ideation at scale. Lens definitions, fit-trace discipline, and the
mandate-grounded vs vision-extending classing all come from
../project-direction/references/ideation.md
— do not redefine them here. Beyond its base lenses, derive 3–6
project-specific lenses from topology and doctrine (e.g. integrations, the
core loop's latency/cost, data or knowledge growth, proactivity/automation,
cross-component collaboration). Each lens agent returns concrete,
integration-point-named proposals (which module, schema, or spec would
change), scored owner-value vs build-cost, deduped against the ledger.
Phase 3 — Synthesis (orchestrator, barrier after Phases 1–2)
The strategic core — keep it on the session's model, inline. Read inputs
from the durable harvest file, never from live agent returns (see execution
discipline §3). Produce:
- Tier board with movement vs baseline (verified movement only; inferred
movement labeled).
- Systemic themes — cross-surface defects with exemplars.
- One ranked move list (~10–15) mixing surface moves and vision extensions;
each move: what, why (doctrine citation), evidence, rough slice plan.
Vision-extending moves carry their doctrine-amendment prerequisite.
Phase 4 — Deliverables
Dossier + data JSON, gated beads epic, and a memory line — formats and the
gate protocol in
references/pursuit-deliverables.md.
A pursuit run is planning, never execution: nothing it files may be
runnable until the owner releases the gate.
Execution discipline
Load references/execution-discipline.md
before any fan-out. Four hard rules — throttle (≤3 agents in flight), model
routing by task difficulty, checkpoint-to-disk per batch, cadence/resume
hygiene. Violating one is a defect in the run, not a style choice.
Handoffs
- Released moves that need behavior specification → the
../project-feature-request/SKILL.md funnel as fuzzy input;
vision-extending moves enter knowing Gate 2 requires doctrine amendment
or rejection.
- Gate release → the owner's move; execution belongs to
/beads-orchestration (beads-coordinator), never to this skill.
- Next run verifies this run's shipped moves via a scoped
../project-review/SKILL.md pass (Phase 0 step 5).
