Create a plan

Define the outcome, scope, and evidence needed before building on Veryfront. Use this guide for a planning request or the Studio Create a plan starter.

Agent-facing flow

If the Veryfront skill is not loaded, load it with load_skill({ "skillId": "veryfront" }). Reuse an already-loaded skill.
Read this guide through the documentation link or the reference reader exposed by your host. A reference path is not a tool name or a separate skill ID.
If the request is broad, ask exactly one short form_input with one required brief field, then continue from the submitted brief. The starter text is routing intent, not the planning brief.
Inspect only the project files, routes, docs, and history needed to plan the requested work.
Write a concise plan with outcome, scope, assumptions, steps, acceptance checks, risks, and stop condition. Include the requested lifecycle stages: plan, build, QA, deploy, run, operate, and improve. Omit stages outside the request.
For the bare Studio “Create a plan” starter, save the plan as Markdown under plans/ with create_file or update_file when file tools are available. Choose a concise slug from the submitted brief for the file name.
For other planning requests, save the plan when the user asks for a file or gives an exact path.

Guardrails

Do not repeat a skill or reference read whose content is already available.
Do not search tools for a documentation or reference filename.
Do not treat the starter label, generic starter prompt, or storage location instruction as the work topic.
Do not ask for output paths, depth, mode, audience, or option fields by default.
For a planning-only request, return the plan without implementation, deployment, or external writes. Create a plan file only when requested, including the bare Studio starter described above.
Do not finish the bare Studio starter with inline-only output when file tools are available.

Decide whether tools are needed

Separate model reasoning from external actions. Summarizing, classifying, and drafting from text already supplied by the user can be performed by the model. Start without tools for that work. Add a tool when the agent needs outside data, a deterministic computation, or an action beyond its response. Describe an unimplemented capability as a requirement, not an available tool ID. Use the authorized catalog and exact operation contract when tool availability affects the plan. Do not invent tool names. A preview or Studio session is not deployment evidence; a deployment check verifies the target environment and release separately.

Example pattern

Keep examples close to the product domain without baking in a single customer workflow. A good default plan theme is an AI agent capability, tool boundary, or verification path.

<!-- plans/support-triage-agent.md -->
# Plan: Support Triage Agent

## Outcome

Create an AI agent that reads incoming support requests, classifies severity, drafts a suggested reply, and escalates cases that need a human.

## Scope

- In scope: agent definition, tool selection, instructions, and test cases.
- Out of scope: sending replies, deployment, and changes to the ticket system.

## Assumptions

- The agent can read support tickets through an approved integration.
- The agent drafts responses but does not send them automatically.
- High-risk or billing-related cases require human review.

## Steps

1. Define the agent goal and escalation rules.
2. Select the minimum required tools for listing, reading, and drafting ticket responses.
3. Add instructions for severity classification, reply drafting, and handoff notes.
4. Add a verification checklist with sample tickets for low, medium, and urgent cases.
5. Define acceptance checks for the requested lifecycle stages. Keep deployment, execution, and external writes outside this planning request.

## Risks

- A wrong severity can delay an urgent case. The agent escalates when unsure.
- A draft can expose private data. The agent quotes only the current ticket.

## Stop condition

Stop when the Build and QA checks below pass, or when a required integration is unavailable. The later stages are follow-up acceptance criteria.

## Verification

- The agent classifies sample tickets consistently.
- Draft replies include evidence from the ticket.
- Escalation cases produce a concise human handoff summary.
- The agent never sends a message without explicit approval.

| Stage | Acceptance evidence |
| --- | --- |
| Plan | Outcome, scope, steps, risks, and stop condition are written and reviewed. |
| Build | Agent definition parses and required capabilities are available. |
| QA | Synthetic cases cover reply, no reply, missing information, and unsupported actions. |
| Deploy | An authorized target environment has a verified release and health check. |
| Run | A synthetic invocation completes and its output satisfies the contract. |
| Operate | Run status, errors, usage, and alerts are observable. |
| Improve | A changed version passes the same cases and has measured usage and quality. |

create_file({
  "project_reference": "<project>",
  "path": "plans/support-triage-agent.md",
  "content": "# Plan: Support Triage Agent\n\n## Outcome\n\nCreate an AI agent that reads incoming support requests, classifies severity, drafts a suggested reply, and escalates cases that need a human.\n\n## Scope\n\n- In scope: agent definition, tool selection, instructions, and test cases.\n- Out of scope: sending replies, deployment, and changes to the ticket system.\n\n## Assumptions\n\n- The agent can read support tickets through an approved integration.\n- The agent drafts responses but does not send them automatically.\n- High-risk or billing-related cases require human review.\n\n## Steps\n\n1. Define the agent goal and escalation rules.\n2. Select the minimum required tools for listing, reading, and drafting ticket responses.\n3. Add instructions for severity classification, reply drafting, and handoff notes.\n4. Add a verification checklist with sample tickets for low, medium, and urgent cases.\n5. Define acceptance checks for the requested lifecycle stages. Keep deployment, execution, and external writes outside this planning request.\n\n## Risks\n\n- A wrong severity can delay an urgent case. The agent escalates when unsure.\n- A draft can expose private data. The agent quotes only the current ticket.\n\n## Stop condition\n\nStop when the Build and QA checks below pass, or when a required integration is unavailable. The later stages are follow-up acceptance criteria.\n\n## Verification\n\n- The agent classifies sample tickets consistently.\n- Draft replies include evidence from the ticket.\n- Escalation cases produce a concise human handoff summary.\n- The agent never sends a message without explicit approval.\n\n| Stage | Acceptance evidence |\n| --- | --- |\n| Plan | Outcome, scope, steps, risks, and stop condition are written and reviewed. |\n| Build | Agent definition parses and required capabilities are available. |\n| QA | Synthetic cases cover reply, no reply, missing information, and unsupported actions. |\n| Deploy | An authorized target environment has a verified release and health check. |\n| Run | A synthetic invocation completes and its output satisfies the contract. |\n| Operate | Run status, errors, usage, and alerts are observable. |\n| Improve | A changed version passes the same cases and has measured usage and quality. |\n"
})

In the MCP tool call, path is the saved plan path and content is the Markdown artifact. When updating an existing plan, read it first and use update_file with the returned version or checksum when available.

Output shape

For the bare Studio starter, return the saved file path plus a short summary. For other planning requests, return the plan in the conversation unless the user requested a file.

Getting Started

Concepts

Guides

Agent-facing flow

Guardrails

Decide whether tools are needed

Example pattern

Output shape

​Agent-facing flow

​Guardrails

​Decide whether tools are needed

​Example pattern

​Output shape

Agent-facing flow

Guardrails

Decide whether tools are needed

Example pattern

Output shape