superforge-dev

Superforge Dev — Multi-Agent Building & Model Tiering Engine

Use this skill when implementing multi-component features, executing complex build plans, or dispatching subagents. It ensures optimal model tiering and agent topology selection.

---

0. Split the work before choosing anything else

Topology and model tier are decisions about how to run tasks. They cannot rescue a bad split, and a bad split is where unattended runs actually fail — agents that conflict, duplicate, or wait.

A task is well-formed only when it has one outcome, a proof line, a listed set of files it will touch, and no question left to ask. The file list is not bookkeeping; it is what makes the next rule decidable:

Two tasks may run in parallel only if the set of files they write does not intersect. Not "probably do not conflict" — listed, and disjoint.

Shared foundations — schema, shared types, design tokens, the route table, a dependency upgrade, any rename — run alone and first, then fan out. Most failed parallel runs are one of those done concurrently with its dependants.

The never-parallel table, how to find the dependencies a file list cannot show, how much context to hand each agent (both too little and too much fail, in different ways), what to do when a subtask fails — revert before retry — and when not to split at all → references/decomposition.md.

The schema is the shared foundation that runs first and alone, and it is also the one part of a product that gets harder to change as the product succeeds — code with no users can be rewritten in an afternoon, a table with real rows cannot. The decisions that are cheap now and expensive later (IDs, timestamps, money, deletion, the ownership chain every authorization check reads), the three causes of every data performance problem, and how to run a migration against data you cannot restore → references/data-design.md.

---

1. Agent Topology Proposal (Subagents · Agent Teams · Workflow)