本文へ移動
cccskills
無料GitHub で公開

dmux-workflows

Multi-agent orchestration using dmux (tmux pane manager for AI agents). Patterns for parallel agent workflows across Claude Code, Codex, OpenCode, and other harnesses. Use when running multiple agent sessions in parallel or coordinating multi-agent development workflows.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

dmux Workflows

Orchestrate parallel AI agent sessions using dmux, a tmux pane manager for agent harnesses.

When to Activate

  • Running multiple agent sessions in parallel
  • Coordinating work across Claude Code, Codex, and other harnesses
  • Complex tasks that benefit from divide-and-conquer parallelism
  • User says "run in parallel", "split this work", "use dmux", or "multi-agent"

What is dmux

dmux is a tmux-based orchestration tool that manages AI agent panes:

  • Press n to create a new pane with a prompt
  • Press m to merge pane output back to the main session
  • Supports: Claude Code, Codex, OpenCode, Cline, Gemini, Qwen

Install: Install dmux from its repository after reviewing the package. See github.com/standardagents/dmux

Quick Start

# Start dmux session
dmux

# Create agent panes (press 'n' in dmux, then type prompt)
# Pane 1: "Implement the auth middleware in src/auth/"
# Pane 2: "Write tests for the user service"
# Pane 3: "Update API documentation"

# Each pane runs its own agent session
# Press 'm' to merge results back

Workflow Patterns

Pattern 1: Research + Implement

Split research and implementation into parallel tracks:

Pane 1 (Research): "Research best practices for rate limiting in Node.js.
  Check current libraries, compare approaches, and write findings to
  /tmp/rate-limit-research.md"

Pane 2 (Implement): "Implement rate limiting middleware for our Express API.
  Start with a basic token bucket, we'll refine after research completes."

# After Pane 1 completes, merge findings into Pane 2's context

Pattern 2: Multi-File Feature

Parallelize work across independent files:

Pane 1: "Create the database schema and migrations for the billing feature"
Pane 2: "Build the billing API endpoints in src/api/billing/"
Pane 3: "Create the billing dashboard UI components"

# Merge all, then do integration in main pane

Pattern 3: Test + Fix Loop

Run tests in one pane, fix in another:

Pane 1 (Watcher): "Run the test suite in watch mode. When tests fail,
  summarize the failures."

Pane 2 (Fixer): "Fix failing tests based on the error output from pane 1"

Pattern 4: Cross-Harness

Use different AI tools for different tasks:

Pane 1 (Claude Code): "Review the security of the auth module"
Pane 2 (Codex): "Refactor the utility functions for performance"
Pane 3 (Claude Code): "Write E2E tests for the checkout flow"

Pattern 5: Code Review Pipeline

Parallel review perspectives:

Pane 1: "Review src/api/ for security vulnerabilities"
Pane 2: "Review src/api/ for performance issues"
Pane 3: "Review src/api/ for test coverage gaps"

# Merge all reviews into a single report

Best Practices

  1. Independent tasks only. Don't parallelize tasks that depend on each other's output.
  2. Clear boundaries. Each pane should work on distinct files or concerns.
  3. Merge strategically. Review pane output before merging to avoid conflicts.
  4. Use git worktrees. For file-conflict-prone work, use separate worktrees per pane.
  5. Resource awareness. Each pane uses API tokens — keep total panes under 5-6.

Git Worktree Integration

For tasks that touch overlapping files:

# Create worktrees for isolation
git worktree add -b feat/auth ../feature-auth HEAD
git worktree add -b feat/billing ../feature-billing HEAD

# Run agents in separate worktrees
# Pane 1: cd ../feature-auth && claude
# Pane 2: cd ../feature-billing && claude

# Merge branches when done
git merge feat/auth
git merge feat/billing

Complementary Tools

ToolWhat It DoesWhen to Use
dmuxtmux pane management for agentsParallel agent sessions
SupersetTerminal IDE for 10+ parallel agentsLarge-scale orchestration
Claude Code Task toolIn-process subagent spawningProgrammatic parallelism within a session
Codex multi-agentBuilt-in agent rolesCodex-specific parallel work

ECC Helper

ECC now includes a helper for external tmux-pane orchestration with separate git worktrees:

node scripts/orchestrate-worktrees.js plan.json --execute

Example plan.json:

{
  "sessionName": "skill-audit",
  "baseRef": "HEAD",
  "launcherCommand": "codex exec --cwd {worktree_path} --task-file {task_file}",
  "workers": [
    { "name": "docs-a", "task": "Fix skills 1-4 and write handoff notes." },
    { "name": "docs-b", "task": "Fix skills 5-8 and write handoff notes." }
  ]
}

The helper:

  • Creates one branch-backed git worktree per worker
  • Optionally overlays selected seedPaths from the main checkout into each worker worktree
  • Writes per-worker task.md, handoff.md, and status.md files under .orchestration/<session>/
  • Starts a tmux session with one pane per worker
  • Launches each worker command in its own pane
  • Leaves the main pane free for the orchestrator

Use seedPaths when workers need access to dirty or untracked local files that are not yet part of HEAD, such as local orchestration scripts, draft plans, or docs:

{
  "sessionName": "workflow-e2e",
  "seedPaths": [
    "scripts/orchestrate-worktrees.js",
    "scripts/lib/tmux-worktree-orchestrator.js",
    ".claude/plan/workflow-e2e-test.json"
  ],
  "launcherCommand": "bash {repo_root}/scripts/orchestrate-codex-worker.sh {task_file} {handoff_file} {status_file}",
  "workers": [
    { "name": "seed-check", "task": "Verify seeded files are present before starting work." }
  ]
}

Troubleshooting

  • Pane not responding: Switch to the pane directly or inspect it with tmux capture-pane -pt <session>:0.<pane-index>.
  • Merge conflicts: Use git worktrees to isolate file changes per pane.
  • High token usage: Reduce number of parallel panes. Each pane is a full agent session.
  • tmux not found: Install with brew install tmux (macOS) or apt install tmux (Linux).

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.

日本語の概要は準備中です。原文の説明を表示しています。

tensology/decisionsai172026年10月13日 更新

tensology のスキルをすべて見る

このスキルの問題を報告する