autoplan

name	autoplan
description	Compares practical solutions with the ideal end state, selects the best in-scope option, and produces an implementation plan. Use only when the user explicitly asks to run autoplan.
compatibility	Requires pi-workflows and the built-in autoplan workflow.

Autoplan

Start the workflow

Use the built-in autoplan workflow when it is available. At top level, list workflows, build the complete input, and start autoplan once.

Build the input as follows:

• problem: State the decision or implementation-planning problem and its observable end state.
• scope: Name the repositories, systems, and interfaces that may change. State important exclusions. Derive an unambiguous repository-local scope without asking the user to restate it.
• constraints: Preserve all user, repository, safety, compatibility, cost, and authority limits. Use an empty array when none apply.
• previousPlan: Include it only when revising an existing plan.
• newEvidence: Include it only when evidence caused the revision request.

Replace the example values below with facts from the conversation, then make one start call:

{
  "action": "start",
  "workflow": "autoplan",
  "input": {
    "problem": "Choose a production-ready timeout fallback and write its implementation plan.",
    "scope": "Only /absolute/path/to/repository. Plan changes to its public workflow API, built-in workflow, tests, and documentation. Exclude Pi core, external services, credentials, releases, and unrelated repositories.",
    "constraints": ["Keep cancellation terminal.", "Use only documented public interfaces."]
  }
}

When this skill is loaded inside an active workflow step, do not start another workflow. Complete the current step contract.

Outside Pi, or when the workflow is unavailable:

1. Frame the problem, observable success criteria, scope, constraints, and interfaces under our control.
2. Record two through four distinct practical candidates. Ask whether each is a Long term elegant and production ready solution. Give each one a stable id, short title, plain gist, full solution, rationale, parts, and trade-offs.
3. Describe the Holy grail separately. Ask whether it is the Holy grail for the problem. Name every dependency outside our authority.
4. Choose the right option without asking the user to decide between them. Record one rejection reason for every other explicit candidate.
   • Choose the Holy grail when it is proportionate, production-ready, in scope, and implementable through interfaces we control.
   • Otherwise choose the strongest practical in-scope solution with a clear path toward the Holy grail.
   • Do not block only because the Holy grail requires an upstream or external change.
5. Write a detailed implementation plan. For each step, state what changes, where it changes, and how to verify it.
6. Present one short plain assistant message with the chosen plan, its main steps, and a one-line gist and rejection reason for every other candidate. Call it selected for approval when a later human decision still applies.
7. Stop as blocked only when no truthful in-scope solution can meet the success criteria.

When revising a plan, preserve the previous plan and new evidence. Record whether the previous plan remains a candidate or why new evidence rejects it. State whether the final plan changed and why. “All plans” means the explicit candidate records, never hidden model reasoning. Do not implement unless the user also requested implementation.