Feature Development

Take a feature request from Slack or a Linear ticket and turn it into a merged pull request without losing context across the handoffs.

What it does

A request arrives in Slack or as a Linear ticket. The lead agent triages, kicks off research, drafts a plan, ships an implementation PR, waits for CI, and routes a critical review — all without humans hand-walking the context across steps.

Agents

• Lead — orchestrator. Picks up the ping, decides whether a research/plan step is needed (complex feature) or direct implementation suffices (bug fix / small change), and routes the work.
• Researcher — deep codebase research and analysis. Outputs structured findings into agent-fs so downstream agents can pull them.
• Coder (ours is named Picateclas) — turns the plan into a working PR using git worktrees, conventional commits, and the repo's existing test discipline.
• Reviewer — critical PR reviewer that doesn't rubber-stamp. Uses gh / glab CLI for inline comments and review submissions.

Tools & Skills

Built-in (ships with agent-swarm)

• Slack, Linear, GitHub, GitLab integrations — read/reply/post, inbound Linear AgentSession sync, gh / glab CLI in every worker container.
• implement-issue, review-pr, respond-github, create-pr — built-in skills. Source: plugin/commands + plugin/pi-skills.
• agent-fs — persistent, searchable filesystem shared across agents. Plans and research live here; any agent can pull them.
• parentTaskId (core swarm feature) — follow-up tasks ("address review feedback") resume the original agent session, preserving context across reviews and re-pushes.

From ai-toolbox

• /desplega:research → /desplega:create-plan → /desplega:implement-plan — our open-source Claude Code plugin. Enforces "research before plan before code" and persists artifacts in agent-fs. Thin command wrappers in cc-plugin/base/commands over cc-plugin/base/skills (researching, implementing, …).

Custom (swarm-managed)

• linear-interaction, linear-expert — outbound Linear updates (Linear sync is inbound-only by default — these handle the outbound side: transitioning state, posting comments, creating issues). Publishing model under discussion.

Workflows / Schedules

• autopilot — manually triggered, full pipeline: research → review-research → plan → review-plan → implement → verify. Each phase has its own review gate so errata are caught before downstream steps.
• autopilot-plan — skip research when you already have one: plan → review-plan → implement → verify.
• autopilot-research — research-only, when you just want vetted findings.
• linear-drain-loop — given a Linear parent issue with sub-issues, branches off the previous PR's branch (stacked PRs), implements each, opens PRs, transitions Linear states. See the Drain Loops pattern.
• linear-merge-loop — companion: reviews the bottom-most open PR with base=main, squash-merges when the reviewer approves and CI is green, transitions the linked Linear sub-issue to Done, then loops up the stack.

Patterns used

• Drain Loops — turn one big Linear ticket into a chain of stacked, individually-reviewable PRs.

Tips for new swarm users

• Use a dependsOn chain for research → plan → implement. Don't let downstream steps fire before upstream artifacts exist.
• One reviewer per PR — a single reviewer can (and should) review multiple times across revisions. What you want to avoid is multiple different reviewers on the same PR, which creates conflicting requests.
• Pin code-implementing schedules to a specific code-capable agent (targetAgentId). Pool dispatch can land on a worker without the right harness.
• Stacked PRs are great for breaking a big ticket into reviewable chunks — but the drain/merge loop only works if each PR is independently mergeable.