Run parallel coding agents from Markdown specs in tmux
Feb 26, 2026 · 13 min read · discussed on Hacker News. Task: The author implemented a parallel coding workflow using tmux, Markdown Feature Design (FD) specs, and six custom slash commands (/fd-init, /fd-new, etc.) to manage agent lifecycles. Agents are assigned roles (Planner, Worker, PM) in separate tmux windows, with code changes tied to numbered FD files tracked in a FEATURE_INDEX.md. The human acts as the bridge between business context and FDs, reviewing specs, adding inline annotations in Cursor, and approving verification steps before closing tasks.; tools: custom-built or unnamed agent. Human role: The original post does not say how a person stayed involved.; limitations: The system requires manual translation of business requirements into FD specs and lacks multi-user collaboration features. Context window compaction can drop critical planning decisions, necessitating frequent checkpoints. The author notes security concerns with Claude Code's permission system, requiring a deny-list approach to prevent destructive commands. This is a personal setup, not a standardized enterprise tool..
Tools
custom-built or unnamed agent
Published on Agent Work Atlas:
Overview
Feb 26, 2026 · 13 min read · discussed on Hacker News
Workflow
The author implemented a parallel coding workflow using tmux, Markdown Feature Design (FD) specs, and six custom slash commands (/fd-init, /fd-new, etc.) to manage agent lifecycles. Agents are assigned roles (Planner, Worker, PM) in separate tmux windows, with code changes tied to numbered FD files tracked in a FEATURE_INDEX.md. The human acts as the bridge between business context and FDs, reviewing specs, adding inline annotations in Cursor, and approving verification steps before closing tasks.
Reported result
The author reports managing 4 to 8 parallel agents effectively, with over 300 FD specs completed in one project. However, they note that beyond 8 agents, cognitive load increases and decision quality suffers. No specific performance metrics or business outcomes are provided, only qualitative observations about workflow strain and context window limitations.
Human role
The original post does not say how a person stayed involved.
Limitations
The system requires manual translation of business requirements into FD specs and lacks multi-user collaboration features. Context window compaction can drop critical planning decisions, necessitating frequent checkpoints. The author notes security concerns with Claude Code's permission system, requiring a deny-list approach to prevent destructive commands. This is a personal setup, not a standardized enterprise tool.
Try it
I want to replicate the parallel coding agent workflow described in the source. First, initialize the FD system in my repository [replaceable: repo_url] by running /fd-init. Create a new Feature Design for [replaceable: feature_description] using /fd-new. I will act as the Planner: review the generated FD-XXX.md file, add inline %% annotations for any ambiguities, and confirm the implementation plan. Once I approve the spec, launch a Worker agent in a separate tmux window to implement the changes. Ensure the Worker uses 'plan mode' first, then 'accept edits' after my review. Do not close the FD or merge changes until I have manually verified the output against the FD's verification steps. If the task is complex, use /fd-deep to explore alternatives before finalizing the plan. Stop and ask for clarification if the FD template or slash commands are not available in my current environment.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.