Skip to main content
Glama

aide_scaffold

Create .aide spec files that enforce naming conventions: research.aide triggers rename of existing .aide to intent.aide. Supports intent, research, both, todo, plan.

Instructions

Create new .aide spec files with automatic naming convention enforcement. Handles the naming rules: 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.

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 (no naming interaction with intent/research)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
directoryYesDirectory where the .aide file(s) will be created
typeYesType of .aide file to create

Implementation Reference

  • src/index.ts:111-130 (registration)
    Tool registration for 'aide_scaffold' — defines name, description, and inputSchema with directory (string) and type (enum: intent, research, both, todo, plan) properties as part of the ListToolsRequestSchema handler setup.
    {
    	name: "aide_scaffold",
    	description:
    		"Create new .aide spec files with automatic naming convention enforcement. Handles the naming rules: 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.\n\nTypes:\n- intent — Strategy, contracts, anti-patterns\n- research — Sources, data, patterns (triggers rename of existing .aide)\n- both — Creates research.aide + intent.aide pair\n- todo — QA re-alignment document for QA agents\n- plan -- Architect's implementation plan (no naming interaction with intent/research)",
    	inputSchema: {
    		type: "object" as const,
    		properties: {
    			directory: {
    				type: "string",
    				description: "Directory where the .aide file(s) will be created",
    			},
    			type: {
    				type: "string",
    				enum: ["intent", "research", "both", "todo", "plan"],
    				description: "Type of .aide file to create",
    			},
    		},
    		required: ["directory", "type"],
    	},
    },
  • Call handler for 'aide_scaffold' — parses args with ScaffoldInput, calls scaffold(), returns text content.
    case "aide_scaffold": {
    	const parsed = ScaffoldInput.parse(args);
    	const result = await scaffold(root, parsed.directory, parsed.type);
    	return { content: [{ type: "text", text: result }] };
    }
  • Zod schema ScaffoldInput — validates directory (string) and type (enum: intent, research, both, todo, plan).
    export const ScaffoldInput = z.object({
    	directory: z.string().describe("Directory where the .aide file(s) will be created"),
    	type: z
    		.enum(["intent", "research", "both", "todo", "plan"])
    		.describe("Type of .aide file to create (intent, research, both, todo, or plan)"),
    });
  • Main scaffold function — creates .aide files with naming convention enforcement. Handles auto-rename logic (.aide -> intent.aide when research.aide exists), writes templates for intent/research/todo/plan/both types.
    export default async function scaffold(
    	root: string,
    	directory: string,
    	type: "intent" | "research" | "both" | "todo" | "plan",
    ): Promise<string> {
    	const dir = isAbsolute(directory) ? directory : join(root, directory);
    
    	// Ensure directory exists
    	await mkdir(dir, { recursive: true });
    
    	const existing = await existingAideFiles(dir);
    	const actions: string[] = [];
    
    	if (type === "todo") {
    		const target = join(dir, "todo.aide");
    		await writeFile(target, TODO_TEMPLATE, "utf-8");
    		actions.push("Created todo.aide");
    	} else if (type === "plan") {
    		const target = join(dir, "plan.aide");
    		await writeFile(target, PLAN_TEMPLATE, "utf-8");
    		actions.push("Created plan.aide");
    	} else if (type === "intent") {
    		if (existing.includes("research.aide")) {
    			const target = join(dir, "intent.aide");
    			await writeFile(target, INTENT_TEMPLATE, "utf-8");
    			actions.push("Created intent.aide (research.aide exists, so using explicit name)");
    		} else {
    			const target = join(dir, ".aide");
    			await writeFile(target, INTENT_TEMPLATE, "utf-8");
    			actions.push("Created .aide");
    		}
    	} else if (type === "research") {
    		// If .aide exists, rename to intent.aide first
    		if (existing.includes(".aide") && !existing.includes("intent.aide")) {
    			await rename(join(dir, ".aide"), join(dir, "intent.aide"));
    			actions.push("Renamed .aide → intent.aide");
    		}
    		const target = join(dir, "research.aide");
    		await writeFile(target, RESEARCH_TEMPLATE, "utf-8");
    		actions.push("Created research.aide");
    	} else if (type === "both") {
    		// If .aide exists, remove it since we're creating intent.aide
    		if (existing.includes(".aide") && !existing.includes("intent.aide")) {
    			await rename(join(dir, ".aide"), join(dir, "intent.aide"));
    			actions.push("Renamed .aide → intent.aide");
    		} else if (!existing.includes("intent.aide")) {
    			await writeFile(join(dir, "intent.aide"), INTENT_TEMPLATE, "utf-8");
    			actions.push("Created intent.aide");
    		}
    		if (!existing.includes("research.aide")) {
    			await writeFile(join(dir, "research.aide"), RESEARCH_TEMPLATE, "utf-8");
    			actions.push("Created research.aide");
    		}
    	}
    
    	if (actions.length === 0) return "No changes needed — files already exist.";
    	return actions.join("\n");
    }
Behavior5/5

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

No annotations provided, yet the description fully discloses critical behaviors: auto-renaming of .aide to intent.aide when research.aide exists, and the side effect of creating research.aide. This is excellent for an unannotated tool.

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?

Well-structured with bullet points for types, but slightly verbose. All sentences earn their place, but minor trimming could improve conciseness.

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?

Despite lacking annotations and output schema, the description provides thorough context: naming rules, type semantics, side effects, and directory parameter. Enters no user in doubt about what the tool does and how it behaves.

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

Parameters5/5

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

The schema covers 100% of parameters, but the description adds substantial meaning beyond enum values—explaining each type's purpose and naming consequences, which the schema alone does not convey.

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?

Clearly states the tool's function: creating .aide spec files with automatic naming convention enforcement. Specifies types and naming rules, distinguishing it from sibling tools like aide_read or aide_brain that operate on existing files.

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?

Provides detailed context on when to use each type (intent, research, both, todo, plan) and explains naming interactions. Lacks explicit comparison to sibling tools, but the descriptions suffices for selecting the correct type.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aidemd-mcp/server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server