example_plans
Returns a curated list of example plans with download links for reports and zip bundles. Use this to preview what PlanExe output looks like before creating your own plan. Especially useful when the user asks what the output looks like before committing to a plan. No API key required.
example_prompts
Call this first. Returns example prompts that define what a good prompt looks like. Do NOT call plan_create yet. Optional before plan_create: call model_profiles to choose model_profile. Next is a non-tool step: formulate a detailed prompt (typically ~300-800 words; use examples as a baseline, similar structure) and get user approval. Good prompt shape: objective, scope, constraints, timeline, stakeholders, budget/resources, and success criteria. Write the prompt as flowing prose, not structured markdown with headers or bullet lists. Weave technical specs, constraints, and targets naturally into sentences. Include banned words/approaches and governance preferences inline. The examples demonstrate this prose style — match their tone and density. Then call plan_create. PlanExe is not for tiny one-shot outputs like a 5-point checklist; and it does not support selecting only some internal pipeline steps.
model_profiles
Optional helper before plan_create. Returns model_profile options with plain-language guidance and currently available models in each profile. If no models are available, returns error code MODEL_PROFILES_UNAVAILABLE.
plan_create
Call only after example_prompts and after you have completed prompt drafting/approval (non-tool step). PlanExe turns the approved prompt into a strategic project-plan draft (20+ sections) in ~10-20 min. Sections include: executive summary, interactive Gantt charts, investor pitch, project plan with SMART criteria, strategic decision analysis, scenario comparison, assumptions with expert review, governance structure, SWOT analysis, team role profiles, simulated expert criticism, work breakdown structure, plan review (critical issues, KPIs, financial strategy, automation opportunities), Q&A, premortem with failure scenarios, self-audit checklist, and adversarial premise attacks that argue against the project. The adversarial sections (premortem, self-audit, premise attacks) surface risks and questions the prompter may not have considered. Returns plan_id (UUID); use it for plan_status, plan_stop, plan_retry, and plan_file_info. To track progress, poll plan_status at reasonable intervals (e.g. every 5 minutes). Optionally, run `curl -N <sse_url>` in a background shell as a completion detector — the stream auto-closes on terminal state (completed/failed/stopped). If you lose a plan_id, call plan_list to recover it. If the same prompt + model_profile is submitted by the same user within a short window, the existing plan is returned (with deduplicated=true) instead of creating a new one. If you are unsure which model_profile to choose, call model_profiles first. If your deployment uses credits, include user_api_key to charge the correct account. Common error codes: INVALID_USER_API_KEY, USER_API_KEY_REQUIRED, INSUFFICIENT_CREDITS.
plan_status
Returns status and progress of the plan currently being created. This is the primary way to check progress — it returns structured JSON with all progress fields. Poll at reasonable intervals (e.g. every 5 minutes): plan generation typically takes 10-20 minutes (baseline profile) and may take longer on higher-quality profiles. State contract: pending/processing => keep polling; completed => download is ready; failed => terminal error; stopped => user called plan_stop (consider plan_resume). progress_percentage is 0-100 (integer-like float); 100 when completed. Note: steps vary in duration — early steps complete quickly while later steps (review, report generation) take longer. Do not use progress_percentage to estimate time remaining. steps_completed and steps_total give the number of plan generation steps completed and expected (both nullable). current_step is the human-readable label of the most recently completed step (e.g. 'SWOT Analysis'). timing.last_progress_at is an ISO 8601 timestamp of the last progress update (null until the first worker update); use it to compute time-since-last-progress and detect stalls — a gap > 10 minutes with no progress change is a strong stall signal. files lists the most recent 10 intermediate outputs produced so far (files_count gives the total); use their updated_at timestamps as a secondary stall signal. When state is 'failed', the response includes an error dict with failure diagnostics: error.failure_reason (category: generation_error, worker_error, inactivity_timeout, internal_error, version_mismatch), error.failed_step (pipeline step active at failure), error.message (human-readable message), and error.recoverable (true => plan_resume may work, false => use plan_retry). The error dict is absent for non-failed states. Unknown plan_id returns error code PLAN_NOT_FOUND. Troubleshooting: pending for >5 minutes likely means queued but not picked up by a worker. processing with timing.last_progress_at unchanged for >10 minutes likely means stalled — call plan_stop then plan_retry. Fall back to file updated_at timestamps if last_progress_at is null. Report these issues to https://github.com/PlanExeOrg/PlanExe/issues .
plan_stop
Request the plan generation to stop. Pass the plan_id (the UUID returned by plan_create). Stopping is asynchronous: the stop flag is set immediately but the plan may continue briefly before halting. A stopped plan will transition to the stopped state. If the plan is already completed or failed, stop_requested returns false (the plan already finished). Unknown plan_id returns error code PLAN_NOT_FOUND.