Expose plan types to agents via /agent-instructions#83
Conversation
…ype by name - Add Plan Types section to agent instructions listing available types - Accept 'plan_type' param (by name) on plan creation instead of UUID - Return clear error with available types when an unknown plan_type is given - Update coplan skill docs to document plan_type param - Add request specs for agent instructions endpoint Amp-Thread-ID: https://ampcode.com/threads/T-019d6373-a857-75b8-b976-dc9a989c53e0 Co-authored-by: Amp <amp@ampcode.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4406b5bb7f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| content: params[:content] || "", | ||
| user: current_user, | ||
| plan_type_id: params[:plan_type_id].presence | ||
| plan_type_id: plan_type&.id |
There was a problem hiding this comment.
This line makes POST /api/v1/plans persist only plan_type-by-name lookups and drops params[:plan_type_id] entirely, so existing v1 clients that still send plan_type_id now get a 201 response with the plan created without a type instead of the previously expected typed plan (or a 422 for bad IDs). Because the failure is silent, it can skew downstream behavior that depends on plan type (classification/template workflows) and is likely to break older agents during rollout unless you continue accepting plan_type_id (or explicitly reject it).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Intentional — there are no existing v1 clients using plan_type_id (the field was added in the same development cycle). We're shipping plan_type by name as the only supported path.
|
|
||
| ### Plan Types | ||
|
|
||
| Plan types provide templates and default tags for common plan categories. When creating a plan, pass `plan_type` to use a type's template as the initial content. |
There was a problem hiding this comment.
The new instructions state that passing plan_type uses the type’s template as initial content, but the create endpoint still sets content from params[:content] || "" and never applies PlanType.template_content. Agents following this guidance and omitting content will create blank plans instead of template-backed drafts, so either implement template fallback in create or adjust this instruction text.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — the docs were inaccurate. Plans::Create doesn't actually fall back to template content. Fixed in 214b580 to say plan types categorize plans and apply default tags, which is what they actually do today.
The docs said plan_type uses template content as initial content, but Plans::Create doesn't actually do that. Updated to accurately describe what plan_type does: categorizes the plan and applies default tags. Amp-Thread-ID: https://ampcode.com/threads/T-019d6373-a857-75b8-b976-dc9a989c53e0 Co-authored-by: Amp <amp@ampcode.com>
1 participant
Summary
Exposes plan types to agents so they can create plans with the right type by name.
Changes
plan_typeparam —POST /api/v1/plansnow acceptsplan_typeby name (e.g.,"general") instead of requiring a UUID. Returns a clear 422 error listing available types if the name is invalid.plan_typeusageExample error response
{"error": "Unknown plan_type \"nope\". Available types: \"design-doc\", \"general\", \"rfc\"."}