Forge Engine

Design spec + milestones AI coding agents read before building; drift flagged, changes reviewed.

¿Debería usar esto?

Calidad y seguridad

B
Calidad de la descripción
89%
Integridad del esquema
83%
Calidad de los nombres
92%
Riesgo de envenenamiento
40%
Coincidencia de permisos
100%
Cumplimiento del protocolo
100%

Hallazgos (19)

  • HIGHTool description contains system tag or markeren get_build_region
  • HIGHTool poisoning patterns detected
  • MEDIUMTool 'report_build_status' description contains placeholder texten report_build_status
  • MEDIUMTool 'report_screen_status' description contains placeholder texten report_screen_status
  • LOWTool 'list_projects' description lacks action verben list_projects
  • LOWTool 'get_system' description lacks action verben get_system
  • LOWTool 'list_systems' description lacks action verben list_systems
  • LOWTool 'list_screens' description lacks action verben list_screens
  • LOWTool 'reorder' description lacks action verben reorder
  • LOWTool 'list_milestones' description lacks action verben list_milestones

Basado en el análisis automatizado de las definiciones de herramientas y el cumplimiento del protocolo.

Costo de contexto

~7,026Tokens (definiciones de herramientas)
~836 BTamaño de respuesta típico
Impacto significativo en la atención (5.49% del contexto de 128k)

Este es el número aproximado de tokens que se consumen cada vez que las herramientas del servidor se cargan en el contexto de un modelo. Los recuentos más altos reducen la atención disponible para otras tareas.

Instalar

Instalación con un clic

Agrega esto a tu archivo `claude_desktop_config.json`:

{
  "mcpServers": {
    "forge": {
      "url": "https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcp"
    }
  }
}

Puntos de conexión remotos

https://mmvdabzadclebfxyzudg.supabase.co/functions/v1/forge-mcpstreamable-http

Qué puede hacer

Inventario de herramientas

Herramientas (54)

🟢 Solo lectura🟡 Escritura🔴 Eliminación⚪ Desconocido
🟢get_help

Forge how-to on demand (no project needed): propose→adopt, what a System is, Balance Lab formats, sign-in. Call when unsure.

Esquema de entrada

{
  "type": "object",
  "properties": {}
}
🟢get_workflow

Run FIRST in a new repo (no project): first-connect routine + the working-agreement block to ADD to AGENTS.md/CLAUDE.md now (tell the user in one line; remove if they object).

Esquema de entrada

{
  "type": "object",
  "properties": {}
}
🟢import_from_code(project_id)

One-command codebase import: recipe + batch id — propose one Context overview + one System per real module; the owner adopts all at once.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢design_ui_from_systems(project_id)

Recipe to design the UI from Systems (user request only): steps + batch id — confirm canvas aspect, then screens + PLACED elements + edges in one batch.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟡post_log(text, entity, version, project_id)

Append a build-log entry to Activity — what you built/decided (commit-note style).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "text": {
      "type": "string",
      "description": "What you did / decided (1–2 sentences)"
    },
    "entity": {
      "type": "string",
      "description": "System/screen/milestone it's about"
    },
    "version": {
      "type": "string",
      "description": "e.g. \"0.379.0\""
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "text"
  ]
}
🟢get_project_context(project_id)

FULL design dump — LARGE, last resort; prefer get_project_meta + list_*/get_*/search.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢list_projects

Projects your key reaches (id, name, role); pass an id as project_id to switch.

Esquema de entrada

{
  "type": "object",
  "properties": {}
}
🟢get_project_meta(project_id)

START HERE. Tiny overview: counts, members, task claims + working_now (avoid collisions), forge_workflow_version.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢trace_ui_from_image(screen, project_id)

SECONDARY (user-driven UI): turn a screen's REFERENCE IMAGE into placed elements. Returns the image itself plus the recipe — the canvas resolution, the fraction→pixel conversion that stops coordinates landing wrong, and what is already on the screen so a second pass updates instead of duplicating. You look at the picture and send back propose_element / update_element with x/y/w/h; it all lands in the owner's Inbox. Use when the user wants the wireframe to match a screenshot or mockup they uploaded.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "screen": {
      "type": "string",
      "description": "The screen whose reference image to trace (name or id)"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "screen"
  ]
}
🟢get_stale(project_id)

What has drifted between the Idea lane and the System Specs — the design's own out-of-sync list, computed deterministically (no AI, no tokens). Three kinds: Idea notes edited since the systems were generated from them (with the systems each one touches), Idea notes whose prose the systems have moved past, and specs whose stamped source fingerprint no longer matches. Read this before assuming the design is coherent; fix the first kind with resync_from_idea.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢resync_from_idea(note, project_id)

The recipe for re-syncing ONE changed Idea note into the specs that depend on it — the same scoped job the app's "Re-sync N systems" button does, minus the button. Returns the note, the affected specs in full, and exactly how to send the result back. You do the writing; it lands in the owner's Inbox to ADOPT. CRUCIAL: send updates with `resync:true`, or the owner adopts your fix and the design still reports it as stale.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "note": {
      "type": "string",
      "description": "The Idea note's title or id (from get_stale)"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "note"
  ]
}
🟢get_design_document(for_summary, page, project_id)

The WHOLE design as one readable document — Vision (+ Project DNA) → every System spec → reference notes, compiled deterministically from the current design. Read this to understand a project end-to-end instead of walking list_systems → get_system N times. Returns markdown plus the project `version` it was compiled from. Long designs come back PAGED — the header says 'part N of M', call again with `page: N+1` for the rest. Pass `for_summary: true` to get the condensed projection instead (every system's Goal + Boundary, tables stripped, one page) — that is what you should summarize from.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "for_summary": {
      "type": "boolean",
      "description": "Return the condensed summarization source (all system goals + boundaries, no tables) instead of the full document"
    },
    "page": {
      "type": "number",
      "description": "Which part of the full document to return (default 1). The header tells you how many parts there are."
    },
    "project_id": {
      "type": "string"
    }
  }
}
🔴set_design_overview(summary, project_id)

Write the Design Document's Overview — the human-readable page a new team member reads first. WRITES DIRECTLY (no Inbox): it is a derived, clearly-labelled AI summary, not design truth, and the owner can clear or rewrite it in one click. HARD RULES, same as the in-app button: use ONLY facts stated in the design (call get_design_document with for_summary:true first); invent no mechanics, numbers or names; describe, never evaluate; write in the design's dominant language. Structure: `### What this is` · `### The core loop` · `### How the systems fit` (which system feeds which — the part a raw spec list cannot give) · `### Edges` (ONLY if the design states scope limits / open questions). 250-400 words, no top-level heading. Forge stamps the project version it was compiled from, so the owner is told when the design has moved past it.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "summary": {
      "type": "string",
      "description": "The Overview in markdown, starting at `### What this is`"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "summary"
  ]
}
🟢get_briefing(files, task, project_id)

ONE-CALL orientation before you build: pass `files` you're about to edit (or a `task`) → the systems that own them, each with Goal + Acceptance + build status/files/last_commit/drift + coupled_systems (code neighbors an edit may break) + pending Inbox changes + recent decisions, plus open-rejection count, who's active, `recent_changes` (what happened since you were last here — a session handoff), and a task to claim. Replaces the get_project_meta→get_system→get_build_region dance.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "files": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Repo-relative paths you're about to touch — mapped to their systems"
    },
    "task": {
      "type": "string",
      "description": "A task id or name — briefs its milestone's systems instead"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_system(id, name, project_id)

ONE system's full spec (Goal/Boundary/Acceptance, markdown, sources, status) + pending Inbox changes touching it.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢list_systems(project_id)

All systems, compact: id, name, status, 1-line goal.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_build_region(system, page, project_id)

System→code map per built system: implementing files, status, drift flag, last_commit, and acceptance-evidence COUNTS. Mapped files gone from the repo? report_drift. Pass `system:"<name|id>"` for ONE system plus the full text of its acceptance criteria (omitted from the map — it is the bulk of the payload). Big projects come back paged: the body says 'page N of M', call again with `page: N+1`.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "system": {
      "type": "string",
      "description": "One system by name or id — returns its acceptance-criteria detail too"
    },
    "page": {
      "type": "number",
      "description": "Which page of the map (default 1); the body tells you how many there are"
    },
    "project_id": {
      "type": "string"
    }
  }
}
⚪report_drift(id, name, missing_files, note, project_id)

Flag CODE DRIFT — mapped files no longer match the repo. Advisory; a fresh report_build_status clears it.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "missing_files": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Paths that no longer exist"
    },
    "note": {
      "type": "string",
      "description": "Optional — what drifted"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_history(system, query, limit, project_id)

DESIGN MEMORY: recorded decisions/logs/rejections with who/when. Read BEFORE changing a system's direction; empty = no recorded WHY — don't invent one.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "system": {
      "type": "string",
      "description": "System id or exact name"
    },
    "query": {
      "type": "string",
      "description": "Keyword filter"
    },
    "limit": {
      "type": "number",
      "description": "Default 30, max 100"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_impact(id, name, project_id)

BLAST RADIUS of a system (deterministic): upstream context, siblings, dependent screens/milestones, files, code-coupled systems, pending Inbox, recent activity. Run BEFORE changing it.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_rejections(project_id)

Owner's DECLINED list — check at session start; follow each entry's guidance, then resolve_rejection(title).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟡resolve_rejection(title, project_id)

Report you REVERTED a declined change (unlocks the owner's Clear). Call after realigning the build.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "Exactly as get_rejections returned it"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "title"
  ]
}
🟢list_screens(project_id)

All screens, compact: id, name, purpose, status.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_screen(id, name, project_id)

ONE screen's layout: canvas `resolution` (use THESE px), elements x/y/w/h, links, popups. Read before editing a screen. has_reference_image:true → get_screen_image shows you the actual image.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_screen_image(id, name, project_id)

A screen's reference image (HUD background) as an actual IMAGE you can see — reads the stored file inline (signed-URL fallback past 4MB).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟡update_element(element_id, screen, label, x, y, ...)

Move/resize/relabel an element — DIRECT, live. element_id (preferred) or screen+label; x+y also places an unplaced one.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "element_id": {
      "type": "string",
      "description": "From get_screen (preferred)"
    },
    "screen": {
      "type": "string",
      "description": "With label, if no element_id"
    },
    "label": {
      "type": "string",
      "description": "Current label"
    },
    "x": {
      "type": "number",
      "description": "px on the screen's canvas"
    },
    "y": {
      "type": "number"
    },
    "w": {
      "type": "number"
    },
    "h": {
      "type": "number"
    },
    "new_label": {
      "type": "string",
      "description": "Rename (optional)"
    },
    "type": {
      "type": "string",
      "description": "e.g. button/bar/panel (optional)"
    },
    "note": {
      "type": "string",
      "description": "\"\" clears"
    },
    "system": {
      "type": "string",
      "description": "System it serves"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🔴withdraw_proposal(id, project_id)

Remove YOUR OWN still-pending Inbox item (id from the propose response / get_inbox).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "The pending item's id"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "id"
  ]
}
🔴delete_entity(kind, id, name, from, to, ...)

PROPOSE a delete → Inbox (owner adopts; nothing deleted now). id preferred or exact name; flow_edge may use from+to.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "kind": {
      "type": "string",
      "enum": [
        "system",
        "context",
        "screen",
        "milestone",
        "task",
        "element",
        "flow_edge"
      ],
      "description": "What to delete"
    },
    "id": {
      "type": "string",
      "description": "Entity/task/element/edge id"
    },
    "name": {
      "type": "string",
      "description": "Exact name/title (if no id)"
    },
    "from": {
      "type": "string",
      "description": "flow_edge: source screen"
    },
    "to": {
      "type": "string",
      "description": "flow_edge: destination screen"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "kind"
  ]
}
🔴dedupe(kind, screen, project_id)

Remove duplicate-named entries (keep first) — DIRECT, destructive.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "kind": {
      "type": "string",
      "enum": [
        "milestones",
        "elements"
      ],
      "description": "What to dedupe"
    },
    "screen": {
      "type": "string",
      "description": "For kind=elements"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "kind"
  ]
}
⚪reorder(kind, order, milestone_id, milestone, screen, ...)

Reorder milestones / tasks / elements — DIRECT. order = ids in new order; omitted keep relative order.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "kind": {
      "type": "string",
      "enum": [
        "milestones",
        "tasks",
        "elements"
      ],
      "description": "What to reorder"
    },
    "order": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Ids in the new order"
    },
    "milestone_id": {
      "type": "string",
      "description": "For kind=tasks"
    },
    "milestone": {
      "type": "string",
      "description": "For kind=tasks (name)"
    },
    "screen": {
      "type": "string",
      "description": "For kind=elements"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "kind",
    "order"
  ]
}
🟢list_milestones(project_id)

All milestones, compact: id, name, weeks, order, done/total.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_milestone(id, name, project_id)

ONE milestone: goal, weeks, difficulty, systems, every task (id/name/done/status/effort).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢list_activity(query, kind, who, limit, project_id)

Change history {who, change, entity, kind, when}, newest first; filter kind/who/query.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "description": "Keyword filter (optional)"
    },
    "kind": {
      "type": "string",
      "description": "system | context | milestone | screen (optional)"
    },
    "who": {
      "type": "string",
      "description": "Author email substring (optional)"
    },
    "limit": {
      "type": "number",
      "description": "Default 30, max 200"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟢get_inbox(project_id)

PENDING Inbox (the owner's triage queue). Check BEFORE proposing — avoid duplicates. Read-only.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "project_id": {
      "type": "string"
    }
  }
}
🟢search(query, kinds, project_id)

Keyword search — compact hits {kind, id, name} + snippet.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "description": "Text to search for"
    },
    "kinds": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Optional: system | context | milestone | task | screen | proposal"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "query"
  ]
}
🟡propose_system(title, spec, files, derives_from, batch, ...)

Propose a NEW system → Inbox. spec = ## Goal / ## Boundary (Owns · Doesn't own) / ## Acceptance. Exists? use update_system. (Alias: create_proposal.)

Esquema de entrada

{
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "System name (Title Case, English)"
    },
    "spec": {
      "type": "string",
      "description": "Markdown: ## Goal / ## Boundary / ## Acceptance"
    },
    "files": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Implementing paths, ONE file per entry"
    },
    "derives_from": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Context note title(s) this system derives from → wires provenance (upstream + siblings)"
    },
    "batch": {
      "type": "string",
      "description": "import_from_code batch id"
    },
    "acknowledge_rejection": {
      "type": "boolean",
      "description": "Only after a DECLINED bounce AND asking the user"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "title",
    "spec"
  ]
}
🟡propose_context(title, content, batch, resync, acknowledge_rejection, ...)

Propose a new/updated Idea note → Inbox. Title-match to update; send the COMPLETE revised text. Set resync:true ONLY when you rewrote the note FROM the current systems (get_stale lists notes the systems have moved past) — it stops the adopted note from immediately nagging to re-generate the systems it was just written from.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "Match existing to update, or new to add"
    },
    "content": {
      "type": "string",
      "description": "Complete text, not a delta"
    },
    "batch": {
      "type": "string",
      "description": "import_from_code batch id"
    },
    "resync": {
      "type": "boolean",
      "description": "This note was re-derived from the current systems — re-stamps both staleness signals on adopt"
    },
    "acknowledge_rejection": {
      "type": "boolean",
      "description": "Only after a DECLINED bounce AND asking the user"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "title",
    "content"
  ]
}
⚪propose_dna(dna, tech_notes, batch, project_id)

Propose Project DNA and/or Tech Notes → Inbox (at least one).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "dna": {
      "type": "string",
      "description": "Omit to leave unchanged"
    },
    "tech_notes": {
      "type": "string",
      "description": "Omit to leave unchanged"
    },
    "batch": {
      "type": "string",
      "description": "import_from_code batch id"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟡update_system(id, name, spec, new_title, context_title, ...)

Propose a system UPDATE → Inbox diff. get_system first; send the FULL revised spec. new_title renames; context_title+context bundles the Idea update. Set resync:true ONLY when you rewrote this spec FROM its upstream Idea (see resync_from_idea) — it re-stamps the staleness signal on adopt.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "spec": {
      "type": "string",
      "description": "Full revised spec markdown"
    },
    "new_title": {
      "type": "string",
      "description": "Rename in the same card"
    },
    "context_title": {
      "type": "string",
      "description": "Idea section to also update"
    },
    "context": {
      "type": "string",
      "description": "Full revised Idea text"
    },
    "resync": {
      "type": "boolean",
      "description": "This spec was re-derived from its upstream Idea — re-stamps sourceSig on adopt. Never set it on an ordinary edit."
    },
    "acknowledge_rejection": {
      "type": "boolean",
      "description": "Only after a DECLINED bounce AND asking the user"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "spec"
  ]
}
🟢get_balance(board, include_rows, project_id)

Read Balance Lab: stat tables, boards with EVALUATED values, scenarios.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "board": {
      "type": "string",
      "description": "One board (omit = all)"
    },
    "include_rows": {
      "type": "boolean",
      "description": "false = schema only"
    },
    "project_id": {
      "type": "string"
    }
  }
}
⚪propose_balance_table(title, csv, schema, rows, registry, ...)

Propose a stat-doc TABLE → Inbox. csv (header; `key%` = percent; first column = name) OR schema+rows. Adopting REPLACES same-named.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "title": {
      "type": "string",
      "description": "Table name"
    },
    "csv": {
      "type": "string",
      "description": "Header + rows; non-numeric = info"
    },
    "schema": {
      "type": "array",
      "items": {
        "type": "object"
      },
      "description": "[{key, mode: flat|pct|text, base, min, max, desc}]"
    },
    "rows": {
      "type": "array",
      "items": {
        "type": "object"
      },
      "description": "[{name, atk: 350, …}]"
    },
    "registry": {
      "type": "boolean",
      "description": "true = the shared Stats registry"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "title"
  ]
}
⚪propose_balance_board(name, nodes, project_id)

Propose a node board → Inbox. Kinds const|formula|item|sheet|loadout|picker|pool|process|note|frame; formulas reference blocks by NAME; omit x/y = auto-layout. Adopting REPLACES same-named.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Board name"
    },
    "nodes": {
      "type": "array",
      "items": {
        "type": "object"
      },
      "description": "e.g. {kind:\"formula\",name:\"dmg\",formula:\"atk - mdef\"}"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "name",
    "nodes"
  ]
}
⚪propose_milestone(name, goal, tasks, acknowledge_rejection, project_id)

Propose a NEW milestone (+ optional tasks) → Inbox.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Milestone name"
    },
    "goal": {
      "type": "string",
      "description": "One-line goal (optional)"
    },
    "tasks": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Task names (optional)"
    },
    "acknowledge_rejection": {
      "type": "boolean",
      "description": "Only after a DECLINED bounce AND asking the user"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "name"
  ]
}
⚪report_milestone_progress(id, milestone, done_tasks, project_id)

Mark existing-milestone tasks done → Inbox progress card (owner adopts the ticks).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "milestone": {
      "type": "string",
      "description": "Milestone name (if no id)"
    },
    "done_tasks": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Task names that are done"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "done_tasks"
  ]
}
🟢report_build_status(id, name, status, files, decisions, ...)

Report a SYSTEM's status (todo|in-progress|implemented) — DIRECT, live. ALWAYS pass files (full list — it REPLACES); non-todo with no files shows done-but-EMPTY. 'implemented' counts as VERIFIED only when every UNIT-TESTABLE ## Acceptance bullet is backed via evidence[{criterion,proof}]; a bullet tagged [manual]/[e2e]/[ui]/[wip] is EXEMPT (verified by manual/e2e). Otherwise it's a CLAIM (verified:false) and the response names the unbacked criteria. TWO tiers: VERIFIED = a test is NAMED; GREEN (guarantee) = you RAN the test and reported `passed:true` on the evidence — green goes stale after 21 days, so re-run to keep it.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "If no id"
    },
    "status": {
      "type": "string",
      "description": "todo | in-progress | implemented"
    },
    "files": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "ONE file per entry (optional ' — function'); prose → decisions"
    },
    "decisions": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Decisions/divergences (prose)"
    },
    "evidence": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "criterion": {
            "type": "string"
          },
          "proof": {
            "type": "string"
          },
          "passed": {
            "type": "boolean",
            "description": "true = you RAN this test and it passed → counts toward TEST-GREEN"
          },
          "at": {
            "type": "string",
            "description": "ISO time of the pass (defaults to now); green expires after 21d"
          }
        }
      },
      "description": "Map ## Acceptance bullets to a test/file: [{criterion, proof, passed?, at?}]. Re-send full set (replaces). proof-only = backed (claimed); passed:true = test-green (guarantee)."
    },
    "version": {
      "type": "string",
      "description": "e.g. \"0.379.0\""
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "status"
  ]
}
⚪propose_flow_edge(from, to, label, project_id)

SECONDARY (user-driven UI): propose a link between two existing screens → Inbox.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "from": {
      "type": "string",
      "description": "Source screen name"
    },
    "to": {
      "type": "string",
      "description": "Destination screen name"
    },
    "label": {
      "type": "string",
      "description": "Transition label (optional)"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "from",
    "to"
  ]
}
🟢propose_element(screen, label, type, x, y, ...)

SECONDARY (user-driven UI): propose an element onto a screen → Inbox. ALWAYS pass x/y/w/h (px on the screen's `resolution` from get_screen); no coords = unplaced pile.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "screen": {
      "type": "string",
      "description": "Existing screen name"
    },
    "label": {
      "type": "string",
      "description": "Element label, e.g. 'HP bar'"
    },
    "type": {
      "type": "string",
      "description": "button/bar/panel/text (default box)"
    },
    "x": {
      "type": "number",
      "description": "Left px"
    },
    "y": {
      "type": "number",
      "description": "Top px"
    },
    "w": {
      "type": "number",
      "description": "Default 120"
    },
    "h": {
      "type": "number",
      "description": "Default 40"
    },
    "note": {
      "type": "string"
    },
    "system": {
      "type": "string",
      "description": "System it serves"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "screen",
    "label"
  ]
}
⚪propose_screen(name, purpose, parent, project_id)

SECONDARY (user-driven UI): propose a NEW screen → Inbox. parent = popup over that screen; purpose grounds AI suggestions. Whole UI? design_ui_from_systems first.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Screen name (Title Case, English)"
    },
    "purpose": {
      "type": "string",
      "description": "What this screen is for"
    },
    "parent": {
      "type": "string",
      "description": "Make it a POPUP over this screen"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "name"
  ]
}
⚪report_screen_status(screen, status, project_id)

Report a SCREEN's status (todo|in-progress|implemented) → Inbox.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "screen": {
      "type": "string",
      "description": "Screen name"
    },
    "status": {
      "type": "string",
      "description": "todo | in-progress | implemented"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "screen",
    "status"
  ]
}
⚪rename_screen(name, new_name, project_id)

Rename a screen IN PLACE — DIRECT; links/elements follow (id-referenced).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Exact CURRENT name"
    },
    "new_name": {
      "type": "string",
      "description": "New name (must not collide)"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "name",
    "new_name"
  ]
}
🟡update_milestone(id, name, goal, weeks, new_name, ...)

Edit milestone goal/weeks/difficulty/name — DIRECT. new_name renames (never delete+recreate).

Esquema de entrada

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string",
      "description": "Preferred"
    },
    "name": {
      "type": "string",
      "description": "Current name (if no id)"
    },
    "goal": {
      "type": "string"
    },
    "weeks": {
      "type": "number"
    },
    "new_name": {
      "type": "string",
      "description": "Rename"
    },
    "difficulty": {
      "type": "string",
      "enum": [
        "easy",
        "medium",
        "hard",
        ""
      ],
      "description": "\"\" clears"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟡add_task(milestone_id, milestone, name, done, status, ...)

Add a task to a milestone — DIRECT. assignee:"me" claims on creation.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "milestone_id": {
      "type": "string",
      "description": "Preferred"
    },
    "milestone": {
      "type": "string",
      "description": "If no id"
    },
    "name": {
      "type": "string",
      "description": "Task name"
    },
    "done": {
      "type": "boolean"
    },
    "status": {
      "type": "string",
      "enum": [
        "in-progress",
        "blocked"
      ]
    },
    "effort": {
      "type": "string",
      "enum": [
        "S",
        "M",
        "L"
      ]
    },
    "assignee": {
      "type": "string",
      "description": "\"me\" claims it"
    },
    "human": {
      "type": "boolean",
      "description": "Human-only (GTM/validation/people work) — next_task & get_briefing skip it"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "name"
  ]
}
⚪next_task(dry_run, project_id)

DISPATCHER (multi-agent): atomically pick + claim the next task to build — walks milestones in order, skips human-only tasks and any task whose systems share code files with a task another agent already holds or is actively touching, so parallel agents spread out instead of colliding. Returns the claimed task + systems, or why none is free. dry_run:true peeks without claiming.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "dry_run": {
      "type": "boolean",
      "description": "Peek without claiming"
    },
    "project_id": {
      "type": "string"
    }
  }
}
🟡update_task(task_id, name, done, status, effort, ...)

Edit a task or CLAIM it — DIRECT. assignee:"me"+status:"in-progress" claims (errors if held; force:true for stale); done:true or assignee:"" releases.

Esquema de entrada

{
  "type": "object",
  "properties": {
    "task_id": {
      "type": "string",
      "description": "From get_milestone"
    },
    "name": {
      "type": "string"
    },
    "done": {
      "type": "boolean",
      "description": "true releases the claim"
    },
    "status": {
      "type": "string",
      "enum": [
        "in-progress",
        "blocked",
        ""
      ],
      "description": "\"\" clears"
    },
    "effort": {
      "type": "string",
      "enum": [
        "S",
        "M",
        "L",
        ""
      ],
      "description": "\"\" clears"
    },
    "assignee": {
      "type": "string",
      "description": "\"me\" claims; \"\" releases"
    },
    "force": {
      "type": "boolean",
      "description": "Take over a STALE claim only"
    },
    "human": {
      "type": "boolean",
      "description": "true = human-only (next_task/get_briefing skip it); false clears"
    },
    "project_id": {
      "type": "string"
    }
  },
  "required": [
    "task_id"
  ]
}

Comunidad

Califica este servidor

Evidencia

Observaciones recientes

verificadoversión no registrada54 herramientas
verificadoversión no registrada54 herramientas