faffter-dark-concurrency-parallel

Runs parallel build passes in isolated git worktrees with rebase-before-merge validation.

3|Updated Apr 16, 2026
One-click install
npx skills add https://github.com/shftwst/faff --skill faffter-dark-concurrency-parallel-shftwst
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: faffter-dark-concurrency-parallel
Source: https://github.com/shftwst/faff/tree/main/plugin/skills/faffter-dark-concurrency-parallel
Command: npx skills add https://github.com/shftwst/faff --skill faffter-dark-concurrency-parallel-shftwst

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Sequential build pipelines are slow when a backlog partition contains many independent issues, but naive parallel builds risk stale-green merges that break main. This Skill executes multiple builds concurrently while keeping merges safe. ## Core Features & Use Cases - Capped parallel execution: Runs multiple build subagents at once in separate git worktrees, bounded by a configurable concurrency_max (default 4), with collision groups serialized internally. - Rebase-before-merge safety: Serializes merges under a lock, rebases each PR onto the latest main, and re-confirms CI green and review pass before merging, so stale-green merges never reach main. - Fleet supervision and evidence custody: Polls in-flight members via heartbeat files, parks stalled members without interrupting live work, and verifies integrity digests plus per-issue AC/review evidence on every subagent return. - Use Case: A team draining a backlog of ten independent issues configures the concurrency slot with this executor so four builds run simultaneously, each merging only after re-validation against the moving main branch. ## Quick Start Configure the concurrency slot to faffter-dark-concurrency-parallel in .faffrc and let the build pass execute the partition in parallel worktrees.

Frequently Asked Questions about faffter-dark-concurrency-parallel

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run multiple builds in parallel with git worktrees?▼

Configure the concurrency slot with this executor and set concurrency_max in .faffrc (default 4). Each build runs in its own worktree under ~/.faff/worktrees, so parallel builds never share a working tree.

How does rebase-before-merge prevent stale-green merges?▼

Before merging, the executor takes a merge lock, rebases the PR branch onto the latest main, and re-confirms CI green and review pass on the rebased head. Merging on pre-rebase green is forbidden, so a moved main never receives stale validation.

What is the difference between the parallel and sequential concurrency executors?▼

The parallel executor runs multiple builds in flight at once using background dispatch and an await-all gate, while the sequential default builds one issue at a time in the foreground. Both honor the same slot contract and merge gate; parallel trades simplicity for throughput.

Can a stalled parallel build be parked without stopping the whole run?▼

Yes. A member-scoped pause verdict triggers the member-park procedure: commit worktree WIP via stage-guard, post a park comment, apply the park label, record the ledger outcome, and free the slot. Genuinely live subagents are never interrupted.

What happens when a parallel build hits a rebase conflict?▼

A rebase conflict means two supposedly independent issues shared a surface. The executor re-dispatches the member as a fresh build subagent to resolve the conflict on the rebased branch, or records a park if it cannot be resolved autonomously.

When should I not use the parallel concurrency executor?▼

Avoid it when builds share surfaces heavily, when disk or worktree capacity is limited, or when you need the simplest auditable path. The sequential default is the safe option; parallelism adds coordination complexity around merges and supervision.