megacode-ultracode

name	megacode-ultracode
description	Use when asked to convert a substantial development task into a MegaCode workflow plan with phases, scoped profiles, model policy, worktree strategy, and verification gates. Triggers on ultracode: prefix or multi-phase implementation requests. Do not use for tiny edits or conversational questions.

MegaCode Ultracode Planning Skill

Produce a workflow plan, not implementation code.

Output format

Return these 11 sections in order:

1. Objective — one paragraph stating the outcome and success criteria.
2. Scope and assumptions — in/out of scope, dependencies, locked constraints (local CI only, GitHub Issues not Linear, app-server workers, no Agents SDK).
3. Proposed workflow phases — ordered phases with ids, types (codex_run, codex_batch, shell, gate, cross_check, etc.), and depends_on edges.
4. Agent profiles per phase — map each phase to a .megacode/profiles/*.json role (explorer, planner, implementer, reviewer, test-runner, etc.).
5. Model and reasoning policy — default models, reasoning effort per phase, concurrency caps (max_concurrency, max_xhigh_concurrency).
6. MCP/skills required per profile — role-scoped servers only; no Linear, no Agents SDK bridge.
7. Worktree strategy — per_workflow vs per_phase, foldback mode (pr, squash, patch), dirty-tree refusal.
8. Test and verification plan — local commands (pnpm verify or npm test + npm run typecheck); never GitHub Actions.
9. Review/cross-check plan — independent reviewers, artifact outputs, blocking vs non-blocking findings.
10. Risks and stop conditions — when to pause, escalate, or refuse foldback.
11. Suggested .megacode/workflows/<name>.yaml skeleton — valid YAML matching schemas/workflow.schema.json.

Rules

• Do not assign high/xhigh reasoning to every worker.
• Prefer Spark or mini for exploration, summaries, and small low-risk tasks.
• Use independent reviewers for high-risk claims.
• Require a worktree for write phases (worktree_policy: required on implementer).
• Keep intermediate outputs as artifacts under .megacode/runs/, not only chat context.
• Verification gates use local-verify-watch, not remote CI watchers.
• Intake uses GitHub Issues (gh issue view) when an issue number is provided.

YAML skeleton template

name: <workflow-name>
version: 1
trigger:
  type: manual  # or github_issue
inputs: {}
model_policy:
  max_concurrency: 8
  max_frontier_concurrency: 2
  max_xhigh_concurrency: 1
worktree:
  mode: per_workflow
  foldback: pr
phases:
  - id: context-map
    type: codex_batch
    profile: explorer
    concurrency: 3
    prompt_template: |
      <phase prompt>
  - id: local-verify-watch
    type: shell
    depends_on: [<prior-phase>]
    verification:
      - pnpm verify

After the plan is approved, delegate YAML authoring to the megacode-workflow-author skill or workflow-author subagent.