• When you want multiple AI agents to independently tackle a problem
• When the task doesn't fit neatly into evaluate, plan, or spec
• Writing, research, code generation, design, analysis, or any open-ended task

• After iterating and stalling — need outside perspective
• Before submitting PRs or delivering artifacts
• When wanting diverse AI perspectives on implementation quality

• When starting a complex feature or project that needs task decomposition
• When an existing plan has gaps, is too vague, or needs restructuring
• When you need a valid task DAG with verification criteria

• When starting a feature that needs precise requirements before implementation
• When an existing spec has ambiguities, missing edge cases, or gaps
• When you need EARS-formatted requirements with acceptance criteria

I found these MassGen configs:

1. .massgen/config.yaml

   — project config

2. ~/.config/massgen/config.yaml

   — global config

Which would you like to use? You can also paste a path to a different config, say "create new" to generate one, or tell me which provider/model you prefer.

• List every found config with its location label (project / global / path)
• If the user expressed a preference (provider name, agent count), note which option best matches and say why
• Always include "create new" as an option
• If only one config exists, still ask — just make it easy: "I found one config at

  .massgen/config.yaml

  — use it, or would you prefer a different one?"

• General: the task to accomplish, relevant context, quality expectations
• Evaluate: which files/artifacts to evaluate, what to ignore, evaluation focus
• Plan: the goal/objective, constraints, what context to include
• Spec: the problem to specify, user needs, system boundaries

references/<mode>/workflow.md

$WORK_DIR/context.md

• General: describe the task, relevant context, quality expectations
• Evaluate: describe what was built, scope, git info, verification evidence
• Plan: describe the goal, constraints, existing context, success criteria
• Spec: describe the problem, user needs, system boundaries, constraints

1. Read the prompt template from

   references/<mode>/prompt_template.md

   (relative to this skill)
2. Read the context file you wrote in Step 1
3. Replace

   {{CONTEXT_FILE_CONTENT}}

   with the context file contents
4. Replace

   {{CUSTOM_FOCUS}}

   with the focus directive (or empty string if none)
5. Write the final prompt to

   $WORK_DIR/prompt.md

If using default criteria (no custom criteria file), omit `--criteria-file`.
For planning/spec modes, use `--criteria-preset planning` or `--criteria-preset spec` instead.
If you resolved a custom config in Step 2, add `--config <path>`.

The script handles everything atomically:
1. Launches MassGen in `--automation` mode
2. Waits for the log directory to appear (with 30s timeout)
3. Starts the web viewer at `http://localhost:8000`
4. Waits for MassGen to complete
5. Writes `$WORK_DIR/run_summary.json` with exit code, duration, log dir

**After the background task completes**, read the summary:

```bash
cat $WORK_DIR/run_summary.json

• --viewer

  — launch web viewer (opens

  http://localhost:8000

  )

• --viewer-port PORT

  — use a different port

• --config FILE

  — custom MassGen config YAML

• --output-file FILE

  — override result path (default:

  $WORK_DIR/result.md

  )

• --no-cwd-context

  — disable read-only CWD access

• --extra-args "..."

  — pass additional massgen CLI flags

1. Enter your task planning mode (e.g., TodoWrite in Claude Code, task tracking in Codex, or whatever native tracking your environment provides)
2. Create one tracked task per item from the MassGen output:
   • Evaluate: each task from

     next_tasks.json

     becomes a tracked task, preserving

     implementation_guidance

     ,

     depends_on

     , and

     verification

   • Plan: each task from

     project_plan.json

     becomes a tracked task, preserving chunk ordering, dependencies, and verification criteria
   • Spec: each requirement from

     project_spec.json

     becomes a tracked task (implement + verify), preserving priority, dependencies, and acceptance criteria
3. Preserve the dependency order — don't flatten the DAG. Tasks in chunk C01 must complete before C02 tasks begin
4. Include verification as explicit tasks — don't just track "implement X", also track "verify X meets [criteria]". Verification that isn't tracked doesn't happen
5. Mark each task's status as you work: pending → in_progress → completed

result.md

verdict.json

"iterate"

approach_assessment.ceiling_status

next_tasks.json

• ceiling_not_reached

  → execute

  fix_tasks

  , then

  evolution_tasks

  as stretch

• ceiling_approaching

  → execute

  fix_tasks

  , then

  evolution_tasks

• ceiling_reached

  → consider re-invoking plan mode with evaluation findings (see Plan-Evaluate Loop below) If

  "converged"

  , proceed to delivery.

eval_checkpoint

• The task has exploratory components (visual design, creative writing, UX)
• The project is complex enough that the initial plan is partly speculative
• Quality expectations are high and "correct but adequate" isn't enough
• Prior iterations show diminishing returns

1. Plan: invoke plan mode. Agents classify tasks as

   deterministic

   or

   exploratory

   and create prototypes to validate assumptions
2. Execute: implement the plan chunk by chunk
3. Evaluate: at

   eval_checkpoint

   tasks (or after any exploratory chunk), invoke evaluate mode
4. Decide: read

   approach_assessment

   in the evaluation output:

   • ceiling_not_reached

     → execute fix_tasks, continue

   • ceiling_approaching

     → execute fix_tasks + evolution_tasks, continue

   • ceiling_reached

     → re-invoke plan mode with evaluation discoveries
5. Evolve: if re-planning, pass

   approach_assessment

   and

   breakthroughs

   as context. The new plan amplifies what worked and avoids approaches that hit their ceiling
6. Repeat until evaluation returns "converged"

• Eval assesses whether the APPROACH has room to grow, not just whether the OUTPUT has defects
• When the approach is limited, the loop goes back to PLANNING, not just more implementation
• Breakthroughs discovered during execution feed FORWARD into new plans, not just into preserve lists
• The plan evolves based on evidence from execution, not speculation

• Max 3 plan mutations per chunk — if still not converging, escalate to user
• If evaluation returns "converged" with

  ceiling_not_reached

  , the loop is complete
• If the user provides explicit direction, follow it regardless of ceiling status

• Target audience: developers and data engineers
• Tech stack: HTML, CSS, vanilla JS (no frameworks)
• Must work on mobile and desktop

• Visually polished, not template-looking
• Fast load time, no external dependencies EOF

• src/api/handler.ts

  — API request handler

• src/hooks/useAuth.ts

  — authentication hook

• Test files, CI config

• Must work with existing PostgreSQL database
• Timeline: 2 weeks
• Team: 2 engineers

• End users: accidentally delete items, need easy recovery
• Admins: need to purge items for compliance after retention period

• PostgreSQL database, soft-delete pattern preferred
• 30-day retention before permanent purge
• Must not break existing API consumers EOF

• references/general/workflow.md

  — general mode context template and output handling

• references/general/prompt_template.md

  — general prompt template with placeholders

• references/criteria_guide.md

  — how to write quality criteria (format, tiers, examples)

• references/evaluate/workflow.md

  — evaluate mode context template, output structure, examples

• references/evaluate/prompt_template.md

  — evaluation prompt template with placeholders

• references/plan/workflow.md

  — plan mode context template, output format, lifecycle

• references/plan/prompt_template.md

  — planning prompt template with placeholders

• references/spec/workflow.md

  — spec mode context template, output format, lifecycle

• references/spec/prompt_template.md

  — spec prompt template with placeholders

• massgen/subagent_types/round_evaluator/SUBAGENT.md

  — source methodology for evaluation

• massgen/skills/massgen-develops-massgen/SKILL.md

  — reference pattern for

  --automation