# Gardeners

> Autonomous project gardening by a coordinated team of agents. Spawns a team of gardeners that each run the `garden` skill in parallel, coordinating via a shared task list to avoid duplicate work. Use when the user wants to tend multiple small issues in one pass. Invoke with /gardeners.

- Skill: `maragudk/gardeners` (Agent Skill)
- Install (CLI): `npx skillmds@latest add maragudk/gardeners`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maragudk/gardeners/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: maragudk (https://skillmd.com/u/maragudk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/maragudk/gardeners

---


# Gardeners

A team version of the `garden` skill. Instead of one gardener pulling one weed, you spawn a small team that each pulls a different weed in parallel. They share a task list so two gardeners don't fight over the same issue.

Use this when the user wants a broader sweep than a single `garden` run would do -- several small, independent issues fixed in one pass. For a single focused fix, use the `garden` skill directly instead.

## Flow

1. **Use the session's team** -- it forms when the first teammate is spawned and comes with a shared task list
2. **Spawn N gardeners** (default 5) as teammates, each instructed to run the `garden` skill with coordination rules
3. **Gardeners coordinate** via the shared task list -- claim before scanning, stand down on collisions
4. **Collect results** as each gardener reports in with a PR URL
5. **Review and merge** the PRs, then clean up

## Step 1: Use the session's team

There's no team to create: each session has a single implicit team with a shared task list, formed automatically when the first teammate is spawned.

That task list is the coordination backbone -- it's how siblings discover what's already claimed.

## Step 2: Spawn gardeners

Default to **five gardeners** unless the user asks for a different count. More gardeners means more coverage but more collisions; fewer means less parallelism.

Spawn each one with the `Agent` tool, passing a distinct `name` and `model: "opus"` -- gardening tasks are small and well-scoped, so they don't need the most expensive model. Sub-agents a gardener spawns (like its self-reviewers) inherit the model automatically. Give them real names, not numbers -- it makes the team feel like a team and the task list easier to read. Pick from the default roster of gardener names and extend it if you need more than five:

- Herb
- Basil
- Rose
- Fern
- Pip
- Sage
- Hazel
- Rosemary

Give each the same prompt -- the coordination rules are what keep them from stepping on each other.

### Gardener prompt template

Each gardener needs:

- An identity (their name in the team)
- A reminder that siblings exist
- The coordination rules below
- Instructions to run the `garden` skill to completion and report back the PR URL

The coordination rules (include these verbatim in every gardener prompt):

```
1. Before scanning, call TaskList to see what other gardeners have already claimed or completed. Avoid duplicating their work.
2. When you pick an issue, immediately call TaskCreate with a specific subject (e.g. "Fix typo X in file Y") and TaskUpdate to set yourself as owner and status=in_progress. This tells siblings what you're working on.
3. If another gardener has already claimed the issue you'd have picked, scan for a different one -- don't open a duplicate PR.
4. On collision (two gardeners on the same issue), earliest claim wins. The later claimer stands down and picks something else.
5. When done, TaskUpdate status=completed and include the PR URL.
6. You fix exactly one issue. If the scan surfaces others, leave them for the next gardening pass -- don't spin up more tasks or expand scope.
```

Run gardeners in the background (`run_in_background: true`) so they work in parallel. You'll get a notification as each reports in.

## Step 3: Let them work

Gardeners will:

- Post a claim to the task list when they pick an issue
- Broadcast (via `SendMessage`) if they detect a collision, citing earliest-claim-wins
- Open a PR and mark their task completed

You generally don't need to intervene. If a gardener seems stuck, send them a message or check the task list for blocked tasks.

## Step 4: Collect results

As each gardener reports in, note the PR URL. Expect between `N-2` and `N` PRs from a team of `N` -- some gardeners may find nothing new to pick after coordination, which is fine.

## Step 5: Merge and clean up

Review the PRs together. Look for:

- Duplicates that slipped through (close the losers)
- PRs that should be combined

Then:

- Merge the good ones (squash, delete branch)
- Close any duplicates with a comment pointing at the survivor
- Prune stale local `garden/*` branches that are left over from the team run
- Shut down the gardeners: `SendMessage` a `shutdown_request` to each one. The team itself needs no teardown -- its shared state is cleaned up automatically when the session ends

## Notes

- **Earliest claim wins** is the simplest collision-resolution rule and the one that worked in practice. Don't overthink it.
- **Shared task list beats chat** for coordination. Use `TaskList` for status; reserve `SendMessage` for collision alerts and direct asks.
- This skill composes with `garden` -- each gardener is just running `garden` with extra coordination. If the single-gardener flow changes, this one benefits automatically.
- **Talk like a gardener -- to the user.** While running this skill, the orchestrating agent should shift register when addressing the user: speak like a gardener tending a plot, with dry humor. Weeds, flower beds, pruning, seasons. Keep it subtle -- one turn of phrase per update, not a costume. Sibling-gardener prompts stay plain; the vibe is only for the user-facing narration.