Skip to main content
Glama

aide_scaffold

Creates new AIDE spec files (intent, research, todo, plan, session) from blank templates, applies canonical naming, skips existing files, and requires an intent spec before a plan.

Instructions

Create a new AIDE working file from its blank template, under its canonical name. It never overwrites: a request for a file that already exists, filled or empty, is a no-op reported as a skip line — remove a file first with aide_cleanup to replace it. New files start with their starting value: an intent spec alignment: unreviewed, a plan or todo list status: proposed. Handles the naming rules, so never pick a name yourself: in a module folder, intent specs are .aide by default, but become intent.aide when research.aide exists in the same folder. Creating a research.aide auto-renames any existing .aide to intent.aide. The project root intent spec always lands at .aide/intent.aide: pass directory ".aide" or "." (both mean the project's .aide folder for intent, research and both). A bare .aide/.aide left by an older project, with no intent.aide beside it, is renamed to .aide/intent.aide with its content kept; if .aide/intent.aide exists, nothing changes. Folders are never treated as spec files. A plan needs an intent spec beside it: scaffolding a plan in a folder with no intent spec (.aide or intent.aide; a research.aide alone does not count) is refused and creates nothing — write the folder's intent spec first. For a root-level plan, pass directory ".aide".

Types:

  • intent — Strategy, contracts, anti-patterns

  • research — Sources, data, patterns (triggers rename of existing .aide)

  • both — Creates research.aide + intent.aide pair

  • todo — QA re-alignment document for QA agents

  • plan — Architect's implementation plan; refused unless the folder already holds an intent spec

  • session — The project's session record, always at .aide/session.aide whatever directory you pass: the empty placeholder with every section heading. Its single source; never write the placeholder by hand.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "directory": "<directory>",
      "type": "<type>"
    },
    "name": "aide_scaffold"
  }
}

Input Schema

NameRequiredDescriptionDefault
typeYesType of file to create: intent, research, both, todo, plan, or session (always .aide/session.aide)
directoryYesDirectory where the .aide file(s) will be created. For the project root intent spec pass ".aide" or "."; it lands at .aide/intent.aide

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.15.0
    • changedInput schema / properties / directory / description
      Previous value: -"Directory where the .aide file(s) will be created"New value: +"Directory where the .aide file(s) will be created. For the project root intent spec pass \".aide\" or \".\"; it lands at .aide/intent.aide"
    • changedInput schema / properties / type / description
      Previous value: -"Type of .aide file to create"New value: +"Type of file to create: intent, research, both, todo, plan, or session (always .aide/session.aide)"
    • changedInput schema / properties / type / enum
      Previous value: -[
      -  "intent",
      -  "research",
      -  "both",
      -  "todo",
      -  "plan"
      -]New value: +[
      +  "intent",
      +  "research",
      +  "both",
      +  "todo",
      +  "plan",
      +  "session"
      +]
  2. First observedv0.3.15

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so thoroughly: it discloses no-overwrite behavior, skip-line reporting, initial values, naming rules, auto-renames, root special cases, plan prerequisites, and session file handling. These are meaningful behavioral traits beyond parameter mechanics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and no-overwrite rule are front-loaded, and most sentences carry necessary edge-case information. It is dense and lengthy for a two-parameter tool, but the complexity of naming, renaming, and prerequisite behavior justifies most of the detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity, lack of annotations, and no output schema, the description is complete: it covers creation behavior, prerequisites, side effects, naming rules, edge cases, and failure/no-op outcomes. An agent would have little reason to guess about how to invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline would be 3, but the description adds substantial meaning: it explains the semantic effect of each type, including research-triggered renames, the research+intent pair for both, plan refusal, and the always-fixed session path. Directory semantics for '.aide' and '.' are also clarified beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Create a new AIDE working file from its blank template, under its canonical name.' It also distinguishes this creation behavior from deletion/replacement by naming aide_cleanup explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage conditions and exclusions: existing files become no-ops, plans are refused without an intent spec, and replacement requires aide_cleanup first. It does not broadly compare against other creation/setup siblings such as aide_init, but the when/when-not guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.