---
id: sm-parallel-feature-development
name: "parallel-feature-development"
url: https://skills.yangsir.net/skill/sm-parallel-feature-development
author: wshobson
domain: ai-ci-cd-deployment
tags: ["agile-development", "feature-branching", "ci/cd", "team-collaboration", "version-control"]
install_count: 5700
rating: 4.40 (40 reviews)
github: https://github.com/wshobson/agents
---

# parallel-feature-development

> 专注于DevOps并行功能开发，通过智能自动化和多智能体编排，加速新功能迭代与部署，缩短上市时间。

**Stats**: 5,700 installs · 4.4/5 (40 reviews)

## Before / After 对比

### 智能并行开发，加速功能迭代上线

## Readme

# parallel-feature-development

# Parallel Feature Development

Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.

## When to Use This Skill

- Decomposing a feature for parallel implementation

- Establishing file ownership boundaries between agents

- Designing interface contracts between parallel work streams

- Choosing integration strategies (vertical slice vs horizontal layer)

- Managing branch and merge workflows for parallel development

## File Ownership Strategies

### By Directory

Assign each implementer ownership of specific directories:

```
implementer-1: src/components/auth/
implementer-2: src/api/auth/
implementer-3: tests/auth/

```

**Best for**: Well-organized codebases with clear directory boundaries.

### By Module

Assign ownership of logical modules (which may span directories):

```
implementer-1: Authentication module (login, register, logout)
implementer-2: Authorization module (roles, permissions, guards)

```

**Best for**: Feature-oriented architectures, domain-driven design.

### By Layer

Assign ownership of architectural layers:

```
implementer-1: UI layer (components, styles, layouts)
implementer-2: Business logic layer (services, validators)
implementer-3: Data layer (models, repositories, migrations)

```

**Best for**: Traditional MVC/layered architectures.

## Conflict Avoidance Rules

### The Cardinal Rule

**One owner per file.** No file should be assigned to multiple implementers.

### When Files Must Be Shared

If a file genuinely needs changes from multiple implementers:

- **Designate a single owner** — One implementer owns the file

- **Other implementers request changes** — Message the owner with specific change requests

- **Owner applies changes sequentially** — Prevents merge conflicts

- **Alternative: Extract interfaces** — Create a separate interface file that the non-owner can import without modifying

### Interface Contracts

When implementers need to coordinate at boundaries:

```
// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
export interface AuthResponse {
  token: string;
  user: UserProfile;
  expiresAt: number;
}

export interface AuthService {
  login(email: string, password: string): Promise<AuthResponse>;
  register(data: RegisterData): Promise<AuthResponse>;
}

```

Both implementers import from the contract file but neither modifies it.

## Integration Patterns

### Vertical Slice

Each implementer builds a complete feature slice (UI + API + tests):

```
implementer-1: Login feature (login form + login API + login tests)
implementer-2: Register feature (register form + register API + register tests)

```

**Pros**: Each slice is independently testable, minimal integration needed.
**Cons**: May duplicate shared utilities, harder with tightly coupled features.

### Horizontal Layer

Each implementer builds one layer across all features:

```
implementer-1: All UI components (login form, register form, profile page)
implementer-2: All API endpoints (login, register, profile)
implementer-3: All tests (unit, integration, e2e)

```

**Pros**: Consistent patterns within each layer, natural specialization.
**Cons**: More integration points, layer 3 depends on layers 1 and 2.

### Hybrid

Mix vertical and horizontal based on coupling:

```
implementer-1: Login feature (vertical slice — UI + API + tests)
implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)

```

**Best for**: Most real-world features with some shared infrastructure.

## Branch Management

### Single Branch Strategy

All implementers work on the same feature branch:

- Simple setup, no merge overhead

- Requires strict file ownership to avoid conflicts

- Best for: small teams (2-3), well-defined boundaries

### Multi-Branch Strategy

Each implementer works on a sub-branch:

```
feature/auth
  ├── feature/auth-login      (implementer-1)
  ├── feature/auth-register    (implementer-2)
  └── feature/auth-tests       (implementer-3)

```

- More isolation, explicit merge points

- Higher overhead, merge conflicts still possible in shared files

- Best for: larger teams (4+), complex features

Weekly Installs2.1KRepository[wshobson/agents](https://github.com/wshobson/agents)GitHub Stars31.5KFirst SeenFeb 5, 2026Security Audits[Gen Agent Trust HubPass](/wshobson/agents/parallel-feature-development/security/agent-trust-hub)[SocketPass](/wshobson/agents/parallel-feature-development/security/socket)[SnykPass](/wshobson/agents/parallel-feature-development/security/snyk)Installed ongemini-cli1.7Kopencode1.7Kcodex1.7Kclaude-code1.6Kcursor1.6Kgithub-copilot1.5K

---
*Source: https://skills.yangsir.net/skill/sm-parallel-feature-development*
*Markdown mirror: https://skills.yangsir.net/api/skill/sm-parallel-feature-development/markdown*