parallel-plan

Files (1)

• SKILL.md

SKILL.md (first lines)

# Parallel Implementation Plan

Create an implementation-ready plan that uses meaningful agent parallelism without introducing edit races.

## Core principles

1. Explain the feature before explaining agent orchestration.
2. Parallelize independent files and concerns, not arbitrary subtasks.
3. Give every concurrent writer an exclusive file allowlist.
4. Place a single-writer integration barrier after concurrent edits.
5. Tell lane agents that peer scopes are not their responsibility; the integrator will reconcile all lanes.
6. Run independent verification lanes concurrently and keep them source-read-only.
7. Consolidate fixes through one writer, then rerun affected checks in parallel.
8. Use an Economy-by-default model budget and never inherit the parent's model for fan-out workers.
9. Run only explicitly named unit-test files during the agent workflow; leave broad suites to CI unless the user authorizes escalation.
10. Prefer the fewest agents that capture the natural parallelism. More agents are not automatically better.

## Planning workflow

### 1. Understand the implementation

Read the request, source specification, applicable rules, and relevant code. Identify:

- required behavior and acceptance criteria;
- existing patterns and helpers to reuse;
- files that will be created or modified;
- API/data/privacy/backward-compatibility constraints;
- tests and verification commands;
- dependencies between files and tasks.

Ask only questions whose answers materially change the contract or task graph.

### 2. Write the implementation narrative first

The plan body must begin in this order:

```markdown
# [Feature]

## What is being implemented and why
[User/business problem, intended behavior, scope, compatibility.]

## How: [contract/architecture]
[Response shape, data flow, boundaries, major decisions.]

## How: [implementation details]
[Files, symbols, algorithm, safety, tests.]
```

Do not begin with waves, agents, task tables, or orchestration mechanics.

### 3. Find natural parallel lanes

Build a file-ownership map. A lane is safe to run concurrently when:

- it writes files no other active lane writes;
- its contract is fully specified in the plan;
- it can tolerate peer files temporarily not existing;
- it does not need repository-wide formatting or automatic fixes;
- integration can resolve temporary import/type mismatches afterward.

Typical lanes include:

- DTO/schema/contract;
- application service;
- service tests;
- controller plus controller tests;
- module wiring plus a focused wiring test;
- independent adapters or migrations when they touch separate files.

Keep implementation and tests in separate lanes only when the method signatures, fixtures, and expected outcomes are precise enough for both agents to work independently.

### 4. Define a focused test budget

The plan must enumerate exact unit-test files that cover the changed behavior and compatibility boundary. During implementation and verification:

- run tests by explicit file path using the framework's exact-file option, such as Jest `--runTestsByPath`;
- include directly modified specs and specifically named neighboring regression specs when the change affects their contract;
- never invoke a package-wide, project-wide, workspace-wide, or complete unit-test suite by default;
- never run integration, end-to-end, preview, or environment-backed suites unless they are explicit acceptance criteria or the user authorizes them;
- do not use coverage mode unless requested;
- leave broad suite coverage to CI.

Escalate narrowly: when a targeted test exposes a dependency issue, add only the specific relevant unit-test file. For shared foundational changes where focused tests cannot provide reasonable confidence, explain the risk and ask before running a broader suite. Do not silently broaden test scope.

### 5. Assign an Economy-by-default model budget

Do not hardcode model names here or in the generated plan. Use the tier names from the global main rule (`low-tier`, `medium-tier`, `high-tier`, `highest-tier`) — that rule is the source of truth for which models map to each tier. At execution, pick an explicit model slug from the Task tool's allowed list for every model-backed subagent.

Use this default allocation:

| Work | Model budget |
|---|---|
| Mechanical DTO/schema, controller, module wiring, straightforward tests | `low-tier` |
| Core business logic, ambiguous implementation, difficult test design | `medium-tier` |
| Integration and cross-lane fixes | Current parent agent; do not launch another agent |
| Final contract/code review | At most one `medium-tier` reviewer (ask before `high-tier` / `highest-tier`) |
| Tests, build, typecheck, lint, formatting checks | Direct tools; no model-backed subagent |

Fan-out workers must never use `inherit`. The user's selected planning model may be `high-tier` / `highest-tier`, and inheritance would multiply that cost across every lane. If the requested `low-tier` / `medium-tier` model is unavailable, do not silently escalate workers; choose the nearest lower-cost suitable model or ask the user.

Hard guardrails:

- without explicit user permission, only launch `low-tier` or `medium-tier` subagents (same as the global main rule);
- never launch more than one `high-tier` / `highest-tier` subagent unless the user explicitly opts in;
- keep worker prompts and context packets limited to the plan plus their lane;
- use the parent as integrator and fixer so it can reuse existing context without another expensive run;
- record the tier for every implementation lane in the plan's ownership table.

### 6. Define dependency waves

After the implementation narrative, add:

```markdown
## Parallel agent execution waves
```

Use this default fan-out/fan-in structure:

From mister-gnommer/rules-of-engagement, MIT.

More from mister-gnommer/rules-of-engagement