Skip to main content
Glama

aide_cleanup

Remove a module's pipeline ephemerals after its cycle closes, keeping code and intent specs durable. Refuses open or unclosed files, naming each blocker.

Instructions

Remove a module's pipeline ephemerals (plan.aide, todo.aide, brief.aide) once that module's cycle has closed, leaving the code and the intent specs as the durable record. It never removes, rewrites or reads anything else: intent specs, research specs, code, and .aide/session.aide are all out of reach.

Each file it would remove must record a closed status: completed (re-checked — every checkbox really checked) or abandoned. A file from before statuses existed, with no status but every checkbox checked, also passes. It refuses anything still proposed or approved, a completed file with an open item, a brief.aide with no plan.aide beside it, and a folder with no ephemerals. An abandoned plan takes its brief with it, and where there is no plan.aide a closed todo.aide is removed on its own. A refusal names each open file or item with its file and line, and nothing is removed. Record a closing status with aide_frontmatter first; this tool never sets or infers one.

Call it directly, because the real call is already safe. dryRun is an optional preview for inspection only and is never a required step before the real call.

This is the cross-platform replacement for a shell delete, so it can be permitted by name.

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": {
      "path": "<path>"
    },
    "name": "aide_cleanup"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesThe module directory whose ephemerals to remove, relative to the project root
dryRunNoOptional. Removes nothing and only reports what a real call would remove. Agents closing a module omit it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.15.0
    • removedInput schema / properties / allowEmptyPlan
      Removed value: -{
      -  "description": "Optional, off by default. Lets a plan.aide with no checkboxes pass. Overrides nothing else, and has no effect where there is no plan.aide.",
      -  "type": "boolean"
      -}
  2. Addedv0.11.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses exact removal scope, status eligibility rules, refusal behavior with file/line reporting, all-or-nothing refusal semantics, and dryRun behavior, plus a clear statement that it never reads or rewrites specs/code/session state. This is unusually rich behavioral context for a destructive file operation.

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

Conciseness5/5

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

The description is front-loaded with the core action and then expands into the necessary safety conditions. Despite being multi-paragraph, each sentence contributes a concrete rule, refusal case, or invocation constraint, and no part is redundant filler.

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

Completeness4/5

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

For a complex destructive tool with no annotations and no output schema, the description is nearly complete: it covers prerequisites, eligibility, refusal behavior, dryRun, and cross-platform intent. The main remaining gap is that it does not describe the success response or reporting format for a real non-dryRun call.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented. The description reinforces that path is the module directory and that dryRun is an optional preview, but it does not add substantial new parameter-level meaning beyond the schema. Baseline 3 is appropriate when the schema handles parameter documentation.

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 description states a specific verb and resource: remove a module's pipeline ephemerals (plan.aide, todo.aide, brief.aide) once its cycle has closed. It clearly delimits what is removed from what remains durable (code, intent specs, research specs, session.aide), so an agent can distinguish this cleanup operation from sibling inspection, validation, or frontmatter tools.

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

Usage Guidelines5/5

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

It gives explicit timing and prerequisites: call after the module cycle closes and record a closing status with aide_frontmatter first. It also says when the tool refuses (proposed/approved status, open items, orphan brief.aide, empty folder) and notes that dryRun is optional and never required, so the agent knows when and how to invoke it directly.

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