Stress-test a risky change with ak:predict

Use ak:predict before a major or risky change to expose architecture, security, performance, user-experience, and assumption failures early. Five expert perspectives analyze the proposal independently, debate meaningful conflicts, and produce a bounded verdict with mitigations before implementation.

Choose ak:predict when a proposal needs pre-analysis

Use ak:predict when

• A feature or refactor has high blast radius or changes system architecture.
• Authentication, data exposure, latency, query volume, or accessibility could change materially.
• Competing approaches need a risk-centered comparison.
• You want to stress-test assumptions before investing in a detailed plan.
• A proposed design needs explicit go, caution, or stop conditions.

Choose another workflow when

• The change is trivial, low-risk, or already approved with no open design question. Use ak:plan or ak:cook as appropriate.
• You are diagnosing a bug or failing test. Use a debugging or fix workflow.
• You need to discover relevant files first. Use ak:scout.
• You need to define the outcome or explore product directions broadly. Use ak:brainstorm.
• You need an implementation roadmap after risks are understood. Use ak:plan.

Prepare the project and runtime

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Describe the proposed change, its intended outcome, and the systems or users it affects.
• Name existing constraints, rejected alternatives, and assumptions that deserve challenge.
• Provide a bounded file glob with --files when current code evidence should inform the debate.
• Keep sensitive or unrelated files outside the glob.

Run the Skill

/ak:predict "Add cross-device draft synchronization while preserving offline editing and the current document format" --files "src/editor/**/*.ts"

/ak:predict "Add cross-device draft synchronization while preserving offline editing and the current document format" --files "src/editor/**/*.ts"

$ak:predict "Add cross-device draft synchronization while preserving offline editing and the current document format" --files "src/editor/**/*.ts"

The feature or change proposal is required. Options refine the evidence or add a follow-on reasoning mode:

The chain modes belong to a predict session; they are not standalone Skills.

Describe the proposal clearly

Useful input gives all five perspectives something concrete to assess:

• Outcome: what the proposed change should achieve.
• Scope: affected users, data, interfaces, components, and operations.
• Constraints: compatibility, security, latency, accessibility, budget, or deployment boundaries.
• Assumptions: especially premises the proposal fails without, whether they can be verified now, and the cost of reversing course if they prove false.
• Evidence: relevant files, measurements, incidents, or prototypes.
• Decision: what you need the verdict to unblock.

For cross-device draft synchronization, state conflict behavior, offline requirements, authentication boundary, current document compatibility, latency target, recovery state, and whether a server component already exists.

Understand the five perspectives

These are analytical perspectives within one workflow. The output is their evidence-backed synthesis, not five independently authorized implementations.

Understand what happens during a run

1. The Skill reads the proposal. It captures the intended change, scope, assumptions, and expected decision.
2. The Skill reads bounded project evidence. When --files is present, it searches matching areas for current behavior relevant to the proposal.
3. Each perspective analyzes independently. Early conclusions remain separate so one perspective does not anchor the others.
4. The Skill identifies agreements. It records concerns or strengths shared by at least four perspectives.
5. The Skill surfaces conflicts. It compares materially different views and resolves them according to impact rather than majority alone, including each option's worst plausible case.
6. The Skill builds the risk summary. Risks receive severity and a concrete mitigation or an explicit statement that no viable mitigation is known. When uncertainty remains, the report also names an observable early signal.
7. The Skill issues a verdict. It returns GO, CAUTION, or STOP with ordered recommendations.
8. The Skill runs an optional chain. reason refines subjective trade-offs; probe harvests missing constraints and assumptions before the report is finalized.

Interpret the verdict

A single unmitigated authentication bypass, data exposure, fundamental design incompatibility, unacceptable latency or query explosion, or premise-invalidating assumption can produce STOP.

Keep approval and safety with you

The source-defined workflow reads the proposal and optionally bounded project files. It does not require network access, a paid provider, credential use, publication, or deployment. It should not modify product code or execute the recommendations.

Keep the --files glob narrow enough to avoid unrelated private material. Security, performance, and UX conclusions are limited to the evidence provided; use specialist review and tests for release decisions. Do not use a chain mode to talk past a STOP trigger without new evidence or a viable mitigation.

Verify the result

A complete prediction report should contain:

• A GO, CAUTION, or STOP verdict.
• Agreements shared by the perspectives.
• A conflict table showing each view and the resolution.
• A risk summary with severity, observable early signals where applicable, and mitigation.
• Ordered, actionable recommendations.
• Evidence boundaries and assumptions that remain unverified.
• For --chain reason, the refined trade-off decision.
• For --chain probe, the newly identified requirements and remaining gaps.

The report is ready for planning when every STOP trigger is resolved or the proposal is redesigned, and every CAUTION item is represented as a constraint, acceptance gate, or risk decision.

Troubleshoot or continue

Feed risk rows to ak:scenario for deeper scenarios or attach the recommendations and mitigations to ak:plan. Use ak:cook only after the resulting acceptance gates are approved.

Know the current limits

• The report predicts risk from the proposal and inspected evidence; it does not forecast unknown future changes or guarantee outcomes.
• --files does not automatically prove runtime behavior, load limits, or exploitability.
• The five perspectives can expose missing evidence but cannot manufacture it.
• Cursor slash invocation is user-verified evidence, not proof of full runtime parity.