---
name: aimake-mcp
description: Use AIMake as the durable system of record while an agent builds production software. Apply when the user asks to use AIMake, the repository points to an AIMake project, or an AIMake MCP server is connected. AIMake governs context and records; the local harness still edits files and runs tools.
---

# AIMake MCP

Use the remote MCP server at `https://api.aimake.dev/mcp`. Let the client
complete OAuth; never ask the user to paste an access token into a prompt,
project note, or proof record.

## Prepare The Work

Before changing production software or durable AIMake records:

1. Call `list_projects` when the project is not already known. Do not guess IDs.
2. Call `prepare_work` with the project, the concrete requested outcome, and
   any known win, task, or decision ID.
3. Read the returned work packet before editing. It contains current project
   records, relevant decisions and Evergreen Notes, repository instructions,
   and the server-versioned production policy.

Treat connected GitHub repository evidence as primary for software facts. Keep
known facts separate from proposed ideas and call out conflicts in the returned
context instead of silently choosing one source.

## Keep AIMake Current

- Pass the returned `work_session_id` to every AIMake write.
- Use wins for stakeholder-visible outcomes and tasks for small, single-owner
  execution steps.
- Record options and tradeoffs in decision records. Only mark a decision
  accepted when a human has actually selected or approved it.
- Respect CX review, lifecycle, and proof gates. Never invent a review, waiver,
  approval, test result, URL, or deployment state.
- Use Evergreen Notes for durable operating knowledge, not temporary scratch
  work or facts already owned by the repository.

AIMake is the shared record and policy layer. Continue using the local harness
for code edits, commands, repository operations, and application inspection.

## Close The Loop

Run verification appropriate to the change. Attach durable HTTPS evidence with
`add_proof` when proof exists; use AIMake's web workspace for binary uploads.
Update tasks and lifecycle state only when their stated evidence exists or the
human has explicitly provided a waiver.

Always call `finish_work`, including for partial or blocked work. Record the
factual outcome, verification performed, and concrete follow-ups. In the final
reply, distinguish what shipped from what remains incomplete.