菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
ALWAYS invoke this skill as your FIRST action — before any Read, Write, Edit, or Bash — whenever a task involves Go in any way — creating or editing any `.go` file, `go.mod`, or `go test`; adding or changing handlers, structs, methods, interfaces, error handling, goroutines, channels, sqlc/database code, or gomponents views; or refactoring, reviewing, debugging, or testing Go. This is a hard requirement, not a suggestion — the user develops all Go through this skill, which encodes project-specific conventions (structure, error handling, testing, naming) that default Go habits violate. Do not start editing Go and consult it later — load it first. Skip only when no Go code is read or written (pure Python, shell, SQL, Dockerfiles, CI config, or conceptual Go questions with no code).
Use when you write or revise a long-form document an audience will read—documentation, a README, a how-to or user guide, a spec, a design or decision doc, a blog post, a proposal, an announcement, or a standalone report or summary written for a person. Such writing should be clear, concrete, and tight, so draft it from the start by Strunk's Elements of Style (active voice; definite, specific, concrete words; omit needless words) instead of first-draft sprawl. Do NOT fire for short or code-adjacent text—commit messages, PR descriptions, release notes or changelogs, error messages, UI strings, code comments, config, version bumps, quick internal scratch notes, or the implementation diary. These exclusions win even when the text reaches an audience: a release note, changelog, or PR description is a working artifact, not a document drafted for readers.
Guide for using git with specific preferences -- branch names without `feat/`/`hotfix/` prefixes, backticks around code identifiers in commit messages, asking about GitHub issues to reference before committing. Use this whenever you branch, commit, or write a commit message -- not just when explicitly asked to "commit". These conventions aren't in your default knowledge and you'll get them wrong without consulting this skill.
Present output one unit at a time instead of dumping a list or wall of text. Use when the user says "one at a time", "/one-at-a-time", "one thing at a time", "go one at a time", asks you to slow down, to stop the wall of text, or to stop dumping everything at once -- either to redo output you just gave, or to pace the rest of a task.
Guide for instrumenting and operating observable software systems. Use this skill whenever the user is adding or reviewing telemetry, instrumenting code with OpenTelemetry, working with traces/spans/metrics/logs/structured events, debugging production behavior, designing SLOs or alerts, setting up sampling or telemetry pipelines, choosing observability storage, or making code observable for humans or AI agents -- even if they don't say the word "observability". Triggers include "add tracing", "instrument this", "OTel/OpenTelemetry", "why is this slow in prod", "set up an SLO", "alert fatigue", "high cardinality", "structured logging", "wide events", and observability for LLM/agent applications.
Building, rendering, or editing any HTML or UI in a Go application means using gomponents — ALWAYS invoke this skill as your FIRST action, before any Read, Write, Edit, or Bash. This fires for any view, page, layout, component, form, table, navbar, footer, or list that renders to HTML; any function returning a `Node`; anything in the `html` package; and converting HTML or templates into Go. It is a hard requirement — the user writes all HTML through gomponents, a pure-Go component library whose conventions (dot imports, `Node` composition, `Map`/`If`/`Iff`, `Group`, HTML5 documents) ordinary Go and HTML habits get wrong. Load it even when the Go skill also applies. Skip only when no HTML or view code is touched (pure database, handler, or business logic; plain `.css`/`.js`/`.html` files; conceptual questions with no code).
基于 SOC 职业分类
| name | gardeners |
| description | 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. |
| license | MIT |
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.
garden skill with coordination rulesUse TeamCreate to make a team named gardeners (or similar -- match to the session if helpful):
TeamCreate({team_name: "gardeners", description: "Gardeners running /garden in parallel, coordinating via shared task list"})
This gives the team a shared task list. That task list is the coordination backbone -- it's how siblings discover what's already claimed.
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 team_name: "gardeners" and a distinct name. 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:
Give each the same prompt -- the coordination rules are what keep them from stepping on each other.
Each gardener needs:
garden skill to completion and report back the PR URLThe 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.
Gardeners will:
SendMessage) if they detect a collision, citing earliest-claim-winsYou generally don't need to intervene. If a gardener seems stuck, send them a message or check the task list for blocked tasks.
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.
Review the PRs together. Look for:
Then:
garden/* branches that are left over from the team runSendMessage a shutdown_request to each gardener, then TeamDeleteTaskList for status; reserve SendMessage for collision alerts and direct asks.garden -- each gardener is just running garden with extra coordination. If the single-gardener flow changes, this one benefits automatically.