parallel-feature-development

Overview of parallel-feature-development skill

What the parallel-feature-development skill does

The parallel-feature-development skill helps you split one feature into multiple implementation streams so several agents can work at the same time without colliding on the same files. Its core value is not “generate code faster” in the abstract; it is reducing merge pain, clarifying ownership, and defining interface contracts early enough that independent work can proceed safely.

Who should use this skill

This skill fits best for:

• teams using multiple AI agents or implementers on one feature
• leads planning a medium or large change that touches UI, API, types, tests, or data layers
• repos where merge conflicts and unclear responsibility slow delivery more than coding itself
• Git workflows that need deliberate branch, ownership, and integration rules

If you only have one implementer or a tiny isolated change, parallel-feature-development is usually more structure than you need.

The real job-to-be-done

Users adopt parallel-feature-development for Git Workflows when they need answers to practical questions such as:

• how should the feature be decomposed?
• which files belong to which implementer?
• what must be shared or owned by a lead?
• should work be split by directory, module, or layer?
• which merge pattern is safest for this feature?

That decision support is the differentiator. A generic prompt may suggest “divide the work,” but this skill gives a usable planning frame for file ownership and integration.

What makes it different from ordinary planning prompts

The repository is most useful because it combines:

• ownership strategies by directory and by module
• concrete project-type examples in references/file-ownership.md
• merge pattern guidance in references/merge-strategies.md
• explicit focus on interface points, shared types, and dependency-aware integration

That makes the parallel-feature-development skill more actionable than a vague “coordinate multiple agents” instruction.

What to check before you install

Install this skill if you want help planning parallel execution, not if you expect it to automatically orchestrate branches or enforce ownership in Git. It is guidance-heavy rather than tool-automation-heavy. The adoption question is simple: do you need a repeatable decomposition method that humans or agents can follow?

How to Use parallel-feature-development skill

Install context for parallel-feature-development

Use your normal skills installation flow for the wshobson/agents repository, then load the parallel-feature-development skill from the agent-teams plugin set. A common install pattern is:

npx skills add https://github.com/wshobson/agents --skill parallel-feature-development

If your environment uses a different skill loader, the important part is the source path:
plugins/agent-teams/skills/parallel-feature-development

Read these files first

For a fast, high-signal parallel-feature-development guide, read in this order:

1. SKILL.md
2. references/file-ownership.md
3. references/merge-strategies.md

Why this order:

• SKILL.md tells you when to use the skill and the main decomposition options.
• references/file-ownership.md helps you assign clean boundaries.
• references/merge-strategies.md tells you how to reintegrate the work with less conflict.

What input the skill needs to work well

The skill performs much better when you provide:

• the feature goal in one sentence
• the files or directories likely to change
• your stack, such as React, Next.js, Express, or Fastify
• the number of implementers or agents
• whether branches, feature flags, or direct commits are allowed
• any shared files that are risky conflict zones
• required checks such as build, typecheck, lint, and tests

Without that context, the output tends to stay generic and may choose the wrong ownership model.

Turn a rough goal into a strong prompt

Weak input:

Split this feature across 3 agents.

Better input:

Use the parallel-feature-development skill to decompose an auth feature for 3 implementers in a Next.js app. Expected changes likely touch src/components/auth/, src/hooks/auth/, src/api/auth/, src/types/auth.ts, and tests. We want low merge risk, one lead-owned shared types file, and a merge plan that respects dependencies. Recommend file ownership, interface contracts, and the safest branch strategy.

This is stronger because it supplies likely file boundaries, team size, stack, and integration constraints.

Ask for outputs you can execute immediately

A good parallel-feature-development usage prompt should request explicit artifacts, not just advice. Ask the model to produce:

• ownership map by implementer
• shared files and who owns them
• contract definitions that must be stabilized first
• recommended branch strategy
• merge order
• verification checklist after integration

That turns the skill into a planning tool you can hand directly to agents or reviewers.

Choose the right ownership model

The repository emphasizes two main ownership approaches:

• By directory: best when the repo already has clear structural boundaries
• By module: better when one feature spans several locations but still forms a coherent unit

In practice:

• choose directory ownership for mature, well-organized repos
• choose module ownership when functional cohesion matters more than folder layout
• avoid mixed ownership of the same file unless one lead explicitly owns shared contracts

Handle shared contracts early

The highest-value pattern in this skill is defining interface points before parallel coding starts. In many repos, the actual bottleneck is not coding speed but unstable contracts.

Before agents begin implementation, lock down:

• shared type definitions
• API request and response shapes
• event names and payloads
• function signatures at component or service boundaries

If you skip this, parallel work often degenerates into post-hoc reconciliation.

Pick an integration pattern that matches team size

The references describe three practical merge patterns:

• Direct integration: small groups, strict ownership, low expected overlap
• Sub-branch integration: safer for larger teams or dependency-heavy work
• Trunk-based with feature flags: good for continuous deployment environments

Decision shortcut:

• 2 to 3 implementers with clean file boundaries: direct integration can work
• 4+ implementers or uncertain overlap: use sub-branches
• production systems shipping continuously: trunk-based plus feature flags is often the least disruptive

Use dependency-aware merge order

A useful detail from the repo is merge sequencing based on dependency graph. Merge foundational work before dependent work. Typical order:

1. shared types or contracts
2. services or API layer
3. UI or consumer layer
4. tests and integration polish

This matters because many “conflicts” are really contract timing problems, not Git problems.

Verify integration the same way every time

After parallel implementation, run a fixed validation pass:

• build check
• type check
• lint
• unit tests
• integration tests
• interface verification

This checklist from references/merge-strategies.md is one of the strongest reasons to use the skill: it closes the loop from planning to integration quality.

Best-fit workflow for real repositories

A practical workflow for parallel-feature-development install and adoption looks like this:

1. identify all files likely to change
2. cluster them into cohesive ownership groups
3. isolate shared contract files and assign a lead owner
4. choose branch strategy based on overlap and team size
5. brief each implementer with exact owned files and dependencies
6. integrate in dependency order
7. run the verification checklist

This is the usage pattern most likely to reduce rework.

When this skill gives the most value

Use parallel-feature-development when the feature crosses layers, such as:

• frontend + backend + tests
• routes + services + models
• hooks + API client + shared types
• event producer + event consumer + schema validation

It adds less value for isolated one-file changes, bugfixes with a single owner, or tasks where the repo structure is too chaotic to define clean boundaries.

parallel-feature-development skill FAQ

Is parallel-feature-development worth using for small changes?

Usually no. If one implementer can finish the work cleanly, the planning overhead may outweigh the benefit. This skill shines when coordination risk is higher than coding difficulty.

Is the parallel-feature-development skill beginner-friendly?

Yes, if a beginner already understands their repository shape. The skill explains ownership and merge patterns clearly, but it assumes you can identify likely files, layers, and dependencies. New developers may need help mapping the codebase first.

How is this different from a normal “split the work” prompt?

A normal prompt often stops at role assignment. The parallel-feature-development skill goes further into file ownership, shared contract handling, and merge strategy selection. That extra structure is what improves Git workflow outcomes.

Does parallel-feature-development automate Git branches or merges?

No. It provides strategy and planning guidance. You still need to create branches, assign work, review code, and merge changes using your own tooling.

Can I use parallel-feature-development for non-web projects?

Yes, if your codebase can be partitioned into coherent ownership zones with clear interfaces. The included references are strongest for common web stacks, but the underlying method also applies to other modular systems.

When should I not use parallel-feature-development for Git Workflows?

Avoid it when:

• the feature is too small to justify decomposition
• too many files are shared and cannot be cleanly owned
• contracts are inherently unstable and still being invented
• one lead should prototype first before parallelizing

In those cases, sequential implementation may be faster and safer.

How to Improve parallel-feature-development skill

Give the skill a file-level starting map

The biggest upgrade to output quality is supplying a probable file list. Even an imperfect draft helps the model propose realistic ownership boundaries. Ask it to refine your map rather than generate one from nothing.

Explicitly mark shared files and conflict hotspots

Tell the skill which files are dangerous to split, such as:

• shared type files
• route registries
• root configuration files
• central index exports
• schema definitions used across layers

This helps parallel-feature-development recommend lead ownership or contract-first sequencing.

Request one recommended plan, not five vague options

If you ask for broad brainstorming, you often get noncommittal output. Better prompt:

Recommend the single best ownership model and merge strategy for this repo, with a short rationale and fallback only if the primary plan fails.

That produces a decision, not a menu.

Force contract definition before implementation planning

A common failure mode is assigning implementers before agreeing on interfaces. Improve results by asking for:

• contract files to stabilize first
• exact producer/consumer boundaries
• temporary stubs or mocks if downstream work must start early

This is especially important in full-stack features.

Ask for merge order with reasons

Do not accept “merge sequentially” as enough. Ask the skill to name the dependency order and explain why. That reduces integration guesswork and reveals whether the decomposition is actually viable.

Adapt the examples to your stack

The references include project-type patterns like React/Next.js frontend, Express/Fastify backend, and full-stack layouts. Use those as templates, but rename paths to match your repo. The skill is much more useful when your prompt includes real directories instead of abstract layers.

Watch for over-parallelization

A subtle failure mode is splitting work too finely. If every implementer depends on frequent contract changes, you have created coordination overhead instead of speed. Ask the skill to identify which pieces should remain sequential or lead-owned.

Iterate after the first plan

After the first parallel-feature-development guide, run a second pass with new information:

• which boundaries still overlap
• which contracts remain unclear
• which files were missed
• whether the chosen branch strategy still fits

A good follow-up prompt is:

Revise the ownership map after discovering overlap in src/types/auth.ts and src/api/auth/index.ts. Minimize rebasing and keep one implementer responsible for final interface reconciliation.

Use the references as decision tools, not just reading material

references/file-ownership.md is best used when deciding who owns what.
references/merge-strategies.md is best used when deciding how work lands safely.

Reading both before execution improves results more than jumping straight into implementation prompts.

Measure success by integration friction

The best way to improve the parallel-feature-development skill in practice is to judge the plan by outcomes:

• fewer merge conflicts
• fewer interface mismatches
• less rework after integration
• faster handoff between implementers

If those do not improve, the fix is usually better ownership boundaries or earlier contract definition, not more decomposition.