Skip to content
cccskills
FreePublished on GitHub

fanout

Run independent development tasks in parallel, each with a separate git worktree and implementation agent. Each agent opens its own pull request, which receives cross-review before being handed to a human for review and merging.

OriginalShow the original description

Run independent subtasks in parallel — one git worktree and one implementation sub-agent per task, each opening its own PR — then cross-review every PR. polly never merges; the human does.

See how to install

Good for

  • Implementing independent changes in parallel
  • Assigning separate working directories to agents
  • Preparing an individual pull request for each task
  • Handing cross-reviewed pull requests to a human

Files included (1)

  • SKILL.md3.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

fanout — safe parallel execution

Use ONLY for subtasks that are parallel-safe (no shared files, no ordering dependency).

Procedure

  1. Per task, create an isolated worktree: sys_os_shell("git worktree add .worktrees/<task_id> -b polly/<task_id>"). Record the worktree path + branch in the registry (.polly/registry.json).
  2. Dispatch one implementation sub-agent per task, scoped to its worktree: sys_session_send(agent="claude_code"|"codex"|"opencode"|"cursor"|"hermes"|"agy", title="<task_slug>", args={purpose: "implement", input: "<task + acceptance contract + worktree path>"}). Use a short task-based title such as auth-refactor or fix-sse-error, never the raw vendor name. State the scope and that it must work only inside .worktrees/<task_id>. The worker drives the task to green and opens its OWN PR for the branch. Every commit the worker authors must end with a blank line followed by the exact co-sign trailer as its final line — Co-authored-by: omnigent <noreply@omnigent.ai>. For a long-running claude_code or codex implementation with an explicit completion condition, the input may instead be one standalone /goal <condition> command containing that same task, worktree, acceptance contract, green gates, and PR requirement. Do not use child goal mode for other workers or non-implementation purposes. Record each handle's conversation_id in the registry. Emit the worktree + sys_session_send tool calls in THIS turn — never end a turn having only said you will dispatch; the dispatch calls and their announcement go in the same turn. Dispatch the whole parallel-safe set, THEN (and only then) END YOUR TURN. Do not poll.
  3. Each sub-agent runs autonomously and notifies you through the inbox when it finishes. Collect its structured result with sys_read_inbox and record the PR URL in the registry. If the inbox result is empty/unclear, inspect that worker conversation with sys_session_get_history before deciding what to do next.
  4. Send each finished task's PR through cross-review.
  5. polly does NOT merge — the PR is the deliverable. When cross-review passes, the task is done: mark it ready in the registry with its PR URL and leave it for the human to review and merge. Never run git merge / gh pr merge.
  6. Remove a finished worktree (git worktree remove) only once its PR is open and review is clean — the branch lives on the remote, so the worktree is disposable. Don't remove a worktree that still has open fix-tasks.

Notes

  • Respect the per-turn dispatch cap (enforced by policy). More tasks than the cap → dispatch in waves (let the running batch finish before dispatching more).
  • The human can open any sub-agent in the UI's Subagents panel and read its conversation while it runs.
  • If a running worker is wrong, runaway, superseded, or no longer useful, call sys_cancel_task with task_id set to the recorded conversation_id before dispatching a replacement. claude_code is hard-stopped; codex cancellation is best-effort until its runner-side hard-stop exists.
  • A sub-agent that returns a dark or failing result: don't re-prompt it in a loop — re-dispatch a fresh implementation sub-agent in a clean worktree, or escalate to the user.
  • Because polly never merges, cross-PR conflicts surface when the human merges, not here. Keeping each parallel task's file scope disjoint is what keeps that rare — honor it.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Test Omnigent’s native Antigravity integration with a live local server and the real agy CLI. Verify messages traveling between the web interface and terminal, mirrored replies, permission requests, interruption, session resumption, and process cleanup.

  • Testing message delivery from the web interface to agy
  • Checking terminal output against mirrored session replies
  • Verifying permission requests and interruption
omnigent-ai/omnigent10.9KUpdated Oct 20, 2026

Test Omnigent’s Antigravity SDK integration against a live local server. Build test agents and run real conversations to check Gemini authentication, model selection, tool connections, and failures across the full execution path.

  • Test authentication and real Gemini responses
  • Verify tool connections and sub-agent delegation
  • Investigate model selection failures
omnigent-ai/omnigent10.9KUpdated Oct 20, 2026

api-docs

FreeSummary

Create reference documentation directly from source code for public functions, classes, command-line commands, and endpoints. Organize parameters, defaults, return values, errors, and runnable examples, then check that the documentation matches the implementation.

  • Writing reference docs for a public module
  • Documenting command-line arguments and defaults
  • Adding minimal usage examples for an API
omnigent-ai/omnigent10.9KUpdated Oct 20, 2026

build-omnigent

FreeSummary

Create an Omnigent agent directory using validated templates for configuration and instructions. Choose how the agent runs, then add web search, shell access, external tool connections, or subagents only when the task requires them.

  • Creating a minimal Omnigent agent
  • Configuring an agent with web search
  • Adding shell access or MCP tool connections
omnigent-ai/omnigent10.9KUpdated Oct 20, 2026

changelog

FreeSummary

Turn a selected range of commits or merged pull requests into release notes grouped by change type. Describe user-visible effects, link to supporting changes, and highlight breaking changes so readers can assess an upgrade.

  • Write release notes covering changes since the last tag
  • Summarize pull requests merged during a selected period
  • Highlight breaking changes before an upgrade
omnigent-ai/omnigent10.9KUpdated Oct 20, 2026

cli-setup-verify

FreeSummary

Test Omnigent’s setup, help, and terminal interactions by driving the real CLI in an isolated environment. Capture rendered screens and compare checks before and after a change to establish whether a reported interface problem was fixed.

  • Reproducing a first-run setup problem
  • Inspecting menus in a narrow terminal
  • Checking help text and command visibility
omnigent-ai/omnigent10.9KUpdated Oct 20, 2026

See all skills by omnigent-ai

Report a problem with this skill