edt-mcp-autopilot

name	edt-mcp-autopilot
description	Autonomous, spec-driven, multi-agent pipeline that takes an EDT-MCP task or issue end-to-end — research → critics → architect → parallel development → review loop → tests → live-stand check → Russian issue comment + PR. Use when asked to take a whole task/issue to completion autonomously (not for a single quick edit or a pure question).

EDT-MCP Autopilot

A repeatable pipeline for delivering a whole EDT-MCP task with minimal human input. You are the conductor running in the main loop: you prepare the stand, drive each fan-out phase with the Workflow tool, hold the gates a workflow cannot (waiting/polling, human confirm, irreversible ship), and finish by commenting the issue and opening a PR.

It runs unattended. The only mandatory human touchpoint is the operator confirming the live stand result (Phase 8). Principal design questions are posted to the issue and polled until answered (Phase 4 gate). Everything else proceeds on its own.

Operating rules (always)

• Spec-Driven (SDD). Write the spec before the code; keep the spec as the contract every agent works against. Persist artifacts to .claude/work/<task-slug>/ (this path is git-ignored — safe for internal notes, issue numbers, stand details).
• Language. Code, comments, commits → English. Issue comments + PR title + PR body → Russian.
• Safety. Never touch the live EDT — stand work runs only on a throwaway copy. The concrete stand path/port are environment-specific (the build/test sibling skills know how to reach them); never hardcode them in this skill.
• Delegate machine specifics. For build, stand, redeploy and test mechanics, use the sibling skills (edt-mcp-build-test, edt-mcp-e2e-testing, edt-mcp-ready-to-deploy) and the project context — do not re-derive commands here.
• Scale to the task. Small tasks get the minimum fan-out; large tasks get more. Pass size and a token budget directive to the workflows so they size themselves.
• Skip-bias. Every agent brief ends with: "no behaviour change unless the spec says so; if the cited code is actually meaningful or risky, SKIP and report instead of forcing a change."

Checklist (create one todo per phase)

1. Phase 0 — Intake & stand prep
2. Phase 1–4 — Discover (run discover.workflow.js)
3. Phase 4 gate — escalate principal questions to the issue, poll until answered
4. Phase 5–6 — Build (run build.workflow.js)
5. Phase 7 — Build + unit tests (the real safety net)
6. Phase 8 — Live stand scenarios + operator confirmation
7. Phase 9 — Ship (issue comment + PR, Russian)

Phase 0 — Intake & stand prep

• Read and study the task (the issue / tracker item / user prompt). Restate it in your own words and capture the acceptance criteria.
• Sync the fork and branch from fresh master (per the project git flow): sync upstream → master → git pull → git checkout -b feature/<slug> (or fix/<slug>). Use a worktree to keep the main clone clean.
• Prepare the test stand now, at the very start, so it is healthy by verification time (delegate to edt-mcp-build-test). If a fresh build is needed for the stand, kick it off.
• Create .claude/work/<slug>/ and write spec.md from references/sdd-templates.md.

Phases 1–4 — Discover

Run the discover workflow (it implements: 2 doc researchers → ≥3 code-research agents in waves with loop-until-dry → adversarial critics that drop refuted findings and bounce "rework" back into another wave → an architect that synthesises the surviving findings into a concrete spec and a file-disjoint developer partition):

Workflow({
  scriptPath: ".claude/skills/edt-mcp-autopilot/references/discover.workflow.js",
  args: { task: "<the task statement>", size: "small|medium|large" }
})

It returns { spec, devPartition, escalations }. Save spec + devPartition into .claude/work/<slug>/architecture.md (template in references/sdd-templates.md).

Phase 4 gate — escalate principal questions

If escalations is non-empty, do not guess. For each, post the question to the issue in Russian (with the 2–3 options), then enter the poll loop in references/autonomy.md (ScheduleWakeup ≈ every 10 min) until the maintainer answers. Fold the answer into architecture.md, then continue. What counts as "principal" (wire contract, architecture choice, bilingual semantics, breaking change, destructive op, ambiguous requirement) is listed in references/review-checklist.md.

Phases 5–6 — Build

Run the build workflow (parallel developers over the file-disjoint slices → a review loop where each round both COMPILES + runs the unit tests (the build gate) AND applies 3–4 reviewers; build failures and review findings both go to fixers, and a round is "clean" only when the build is green AND no findings remain — with a max-round safeguard that escalates instead of spinning):

Workflow({
  scriptPath: ".claude/skills/edt-mcp-autopilot/references/build.workflow.js",
  args: {
    task: "<the task statement>",
    spec: <spec from discover>,
    devPartition: <devPartition from discover>,
    reviewChecklist: "<contents of references/review-checklist.md>",
    maxRounds: 4,
    buildCommand: "<the project build + unit-test command, WITH the machine's JDK17/maven — e.g.
                    bash source/compile.sh --java-home <..> --maven-home <..>>"
  }
})

Always pass buildCommand. Reviewers read the diff but cannot compile — so an unverified API or a broken test churns rounds forever until a real build settles it. The build gate makes the compiler the arbiter inside the loop (it reads the surefire reports and feeds failing tests to the fixers as blockers). Take the exact command from the project context / CLAUDE.md (it is machine-specific, so it lives in args, not in the release-clean script). If you ever see the loop "reviewing and fixing the same thing round after round", that is the symptom of a missing/failing build gate — check reviewLog[].buildOk.

It returns { changedFiles, reviewLog, openProblems, rounds, clean }. If clean is false after maxRounds, treat the remaining openProblems as an escalation (Phase 4 gate). Record the review outcome in .claude/work/<slug>/review-log.md.

The developers edit disjoint files in the shared working tree and do not touch git — you commit at the end. If two slices must touch the same file, re-partition or run that slice with isolation:'worktree' and merge.

Phase 7 — Build + unit tests (final confirmation)

Run the project build + unit tests yourself (delegate to edt-mcp-build-test). With buildCommand set, the review loop already compiled + tested each round, so when it returned clean: true this is a fast confirmation on your own deterministic build (it should pass first try). It is still the real safety net — it catches missing throws, ratchet failures (unit XxxToolTest, schema/execute parity) and golden drift. Red → back to Phase 5/6 with the failures as the brief. Green → continue. If a tool's wire surface changed, regenerate the golden and review the diff.

If the loop hit maxRounds still red (or you did NOT pass buildCommand), do NOT keep spawning review rounds — stop the workflow and run the build yourself; the compiler settles what the reviewers were guessing at, and you fix the concrete failures directly.

Phase 8 — Live stand scenarios + operator gate

If the task is live-verifiable (a tool behaviour, a form/metadata effect, a runtime contract):

• Redeploy the fresh build to the throwaway stand and run the real scenarios (the e2e matrix or targeted MCP calls) — delegate to edt-mcp-e2e-testing / edt-mcp-ready-to-deploy.
• Scan the workspace log after exercising the feature. Grep <workspace>/.metadata/.log for stack traces / errors from our code (com.ditrix.edt.mcp.server) logged since the redeploy. Runtime failures often log there WITHOUT surfacing through the MCP wire — an exception in a UI Job, a caught Activator.logError, or a per-item failure swallowed into a degraded result (a real case: a single-image CommonPicture whose decode threw but showed only as "No variants" in the gallery, found only in .log). A green tool response does NOT prove a clean run — treat any such stack as a real finding to diagnose BEFORE the operator gate, not after a user hits it.
• Operator gate (the one human touchpoint): use AskUserQuestion to show the live result and ask the operator to confirm it before shipping (see references/autonomy.md). Do not open the PR until the operator confirms.

If the task is not live-verifiable (pure refactor, hygiene, docs), skip the stand run and the operator gate — the green build + e2e already prove it.

Phase 9 — Ship

On all-green and operator OK:

• Record the key facts and lessons for future work.
• Commit (English message; include the standard AI Co-Authored-By trailer), push the branch.
• Comment the issue in Russian (what was done, how it was verified).
• Open the PR to upstream in Russian (title + body), body ending with 🤖 Generated with [Claude Code](https://claude.com/claude-code).

Files in this skill

• references/discover.workflow.js — Phases 1–4 (research → critics → architect).
• references/build.workflow.js — Phases 5–6 (parallel dev → review loop).
• references/review-checklist.md — the MUST-ENFORCE criteria reviewers and the architect apply.
• references/sdd-templates.md — spec.md / architecture.md / review-log.md templates.
• references/autonomy.md — the issue-poll gate and the operator-confirm gate recipes.

Notes

• This skill orchestrates the existing recipes; it does not redefine build/stand mechanics.
• Keep this skill and its references release-clean: English only, no machine paths, ports, stand names, or internal issue numbers (those belong in the project context and in the git-ignored .claude/work/).