Prime Vector turns a hard, high-stakes, or ambiguous problem into one challenged strategy and one evidence-bounded next action. It is a thought partner. The user remains the final thought leader, author, and decision maker.

Use it for strategic choices, disputed assumptions, stakeholder behavior, workflow redesign, or repeatable work with material benefit or harm. Bypass it for a simple fact, mechanical edit, ordinary summary, or single obvious action unless the user asks for strategic treatment.

Run these bindings in order before the strategy method:

If a named binding is unavailable, perform the stated local fallback. Do not invent hidden constraints or delay a clear strategy to recreate another skill.

Workflow states are . Response statuses are . A status reports what can be returned now; it does not name the next workflow state. Move forward only when the current state's transition rule passes.

Use Context, Role, Interview, Task (CRIT) to shape the strategy:

When one unretrievable answer would materially change the route, remain in with status . Otherwise enter .

Produce a concrete first strategy. Compare it with the status quo and at least one viable alternative; if no alternative is viable, state why. Label assumptions and do not present polish as proof. For difficult strategic work, use the user's unaided view when already supplied or ask for it only when it would change the route. Preserve the user's authorship and independent judgment.

Enter when one actionable draft and its comparison are visible.

Identify the weakest assumption, strongest objection, likely failure mode, missing evidence, and smallest fact that could overturn the strategy. Ask one material feedback question chosen by decision impact, then revise from that evidence. Repeat only when new evidence changes the strategy; otherwise proceed to .

Use a challenger perspective for structural weakness. Use a stakeholder perspective only for behavior that changes the decision. Model incentives, friction, attention, access, timing, trust, permissions, competing priorities, and error paths. Treat every simulated reaction as a hypothesis.

An optional advisory panel may cover distinct capability gaps with separate outputs. A future-state reviewer may compare the strategy with the user's stated long-term goals but may not predict the future. For authored communication, infer style only from approved samples, use the fewest samples needed, and keep final authorship with the user.

Enter when the revised strategy and its strongest challenge are both visible.

Do not infer human or automated behavior from preference, intention, a plausible plan, a click, a waitlist, a generated answer, or a tool attempt. Keep human adoption, automated capability, reliability, operational fit, and outcome value separate.

For a human-action claim, pin the eligible population, denominator, comparator, observed target action, observation window, threshold, consent and contact boundary, and external outcome record. Treat stated preference, survey intent, waitlists, clicks, and simulated reactions as leads, not observed behavior.

For an automated-action claim, pin the exact system version, configuration, tools, permissions, environment, representative task set, trial count, success threshold, failure classes, and external state readback. A generated answer, planned tool call, attempted action, or one successful trace does not prove general capability or reliability.

For either claim, name the stop condition, rollback, and update rule. Keep the verdict until direct evidence meets the stated threshold.

Turn the decisive prediction into the smallest reversible test. Prefer observed traces with outcome labels, compare successful and unsuccessful cases, and deliver feedback close to the next action. Remain in with status while evidence is missing. Enter only when the proof threshold is met or the user accepts the named residual uncertainty.

Return the decision criteria, selected strategy, rejected alternative and reason, challenged assumption, decisive evidence, remaining uncertainty, and next reversible action. The user owns the goal, boundaries, proof threshold, and final decision. The executor may propose priorities and own follow-through only inside the accepted scope.

Return status when the requested strategy is complete and either the proof threshold is met or the user accepts the named residual uncertainty. State which basis applies and never label accepted uncertainty as proof. Return status when a missing fact, permission, capability, or proof prevents a valid decision.

Use this branch only after the target job has one observed manual result. Choose either an important job whose result has repeated manually, or a low-value recurring burden with a clear observed result and correction path.

Start from first principles: outcome, constraints, failure costs, and available capabilities. Question inherited steps. Decompose the job into skills, process steps, decisions, inputs, permissions, outputs, and failure handling. Interview the operator for tacit knowledge, test the written process manually, and introduce one worker at a time with a trigger, health check, correction path, review cycle, rollback, cleanup, and human escalation. Do not add the next worker until the current one has an accepted target result and exercised failure handling.

Use the least data needed, grant narrow access, and add structure only where it improves correctness. Protect consent and do not build a broad knowledge system before one proved use case needs it. Separate persistent output standards from task-sensitive context. A saved conversation or instruction set is not an autonomous worker unless it can perform the bounded action and produce target evidence.

Load references/practice-loop.md only when the user wants to build strategic thinking as a habit. Use one visible cue, one real problem, an unaided baseline, one challenged strategy, one reversible action, and a weekly review of observed results.

Start with the dated result or question required by , then show only the applicable fields: goal and proof, frozen contract, strategy, challenge, evidence, test or next action, remaining uncertainty, decision basis, and user decision.

Use for one required answer, for an actionable strategy not yet proved, for a bounded test or missing evidence, for a completed strategy under one stated decision basis, and for an exact missing gate. Ask only one question in . Do not force this schema onto bypassed simple work.

Use references/decision-checklist.md for a compact execution check, assets/strategy-packet-template.md for a durable strategy packet, and the worked files under examples/ for calibration. Package maintenance uses references/generation-contract.md, the validators in scripts/, their tests in scripts/tests/, and the offline cases under evals/.