How to use the Parallel Feature Development agent skill

What the skill makes the agent do

The skill is guidance and templates, not automation. When it is active, the agent helps you decompose a feature into independent work streams, assign each implementer a clear boundary, and plan how their results fit together. It does not run git or split code for you.

It covers three main areas: file ownership strategies (by directory, by module, or by layer), conflict avoidance rules, and integration patterns (vertical slice, horizontal layer, or hybrid). It also covers single-branch versus multi-branch git workflows and common troubleshooting such as merge conflicts and blocked implementers.

• Assign ownership by directory, module, or architectural layer
• Enforce one owner per file
• Define interface contracts so implementers can build against each other's APIs before they are ready
• Choose between vertical slices, horizontal layers, or a hybrid
• Pick a single-branch or multi-branch git strategy

Install the skill (ZIP or Claude apps upload)

Download the ZIP for this skill from this page. The skill is a folder containing SKILL.md, references/file-ownership.md and references/merge-strategies.md. You can install it in one of two ways.

For Claude Code, unzip the download into your personal skills folder ~/.claude/skills/, or into a project's .claude/skills/ folder if you want it available only in that project. For the Claude apps, upload the ZIP under Settings → Capabilities → Skills.

• Personal install: unzip into ~/.claude/skills/
• Project install: unzip into the project's .claude/skills/
• Claude apps: upload the ZIP under Settings → Capabilities → Skills

Trigger the skill with natural requests

You do not need a special command. The skill's description tells the agent when to use it, so ask in plain terms about the situation you are in. Requests that match its stated uses include decomposing a large feature into independent work streams, splitting work between two or more agents, preventing merge conflicts in a shared codebase, designing interface contracts, and deciding between vertical slices and horizontal layers.

Be specific about the number of agents, the codebase layout and the problem you are hitting. The more context you give, the more useful the ownership map will be.

• "Split this auth feature across three agents so they don't touch the same files."
• "Should we build the checkout flow as vertical slices or horizontal layers?"
• "Two agents keep conflicting in src/api. Help me set up file ownership."
• "Design an interface contract so the frontend agent can build before the API exists."

Example: planning a full-stack feature

Suppose you want an authentication feature built by three agents. The skill's directory strategy suggests one implementer for UI components, one for API endpoints, and one for tests, each with a named directory. For a feature that is mostly self-contained, it may instead recommend vertical slices, where each agent builds a login or register feature end to end.

Where some infrastructure is shared, the skill describes a hybrid: one agent builds a complete feature slice while another owns shared middleware, utilities and types. A shared contract file, such as an auth types file owned by the lead and read-only for implementers, lets both sides build against the same shapes.

Handle shared files and barrel/index files

The cardinal rule is one owner per file. If a file truly needs changes from several implementers, the skill suggests designating a single owner, having others request changes from that owner, and letting the owner apply them in sequence. Alternatively, extract an interface into a separate file that the non-owner can import without modifying.

Barrel or index files such as index.ts or __init__.py are a frequent source of conflicts because they auto-import everything. The troubleshooting guidance says to give one owner all of them, or have the lead merge them at the end.

Choose a single-branch or multi-branch workflow

A single branch means all implementers work on the same feature branch. It is simple and suits small teams of two or three with well-defined boundaries, but it requires strict file ownership. A multi-branch setup gives each implementer a sub-branch under the feature branch, which adds isolation and explicit merge points. The skill suggests it for larger teams of four or more and for complex features, while warning that merge conflicts are still possible in shared files.

The merge strategies reference describes three patterns: direct integration on one branch, sub-branch integration where the lead merges sequentially in dependency order, and trunk-based development behind feature flags.

• Single branch: small teams (2-3), strict ownership
• Multi-branch: larger teams (4+), review gates, merge in dependency order
• Trunk-based: commits to main behind a feature flag

Troubleshoot blocked implementers and merge conflicts

When implementers block each other waiting for shared code, extract that piece into an interface contract file and have implementers code against it. When an implementer finishes early but integration is blocked, the skill suggests a staging stub or mock of the downstream dependency, replaced by the real implementation at integration time.

If the decomposition turns out wrong mid-stream, the skill suggests stopping new work, redistributing files, and broadcasting the change. If tests fail against another implementer's code, the usual cause is a contract that changed without notice, so it recommends requiring a broadcast before any contract file is modified.

• Blocked on shared code: extract an interface contract
• Finished early: write a stub or mock downstream
• Wrong split: stop, redistribute files, broadcast the change
• Test failures across implementers: enforce contract change broadcasts