agentleFS
KilimiaoSixKilimiaoSix/agent-skills/skills/autonomous-multi-agent-development/SKILL.md

autonomous-multi-agent-development

Skill1 starsChanged 4 months agoMITView on GitHub

Autonomous multi-agent style development workflow for complex software tasks. Use when a request involves substantial feature work, cross-stack changes, debugging plus implementation, refactoring with validation, CI/deploy fixes, architecture/spec-to-code execution, or explicit requests for multi-agent, parallel, autonomous, dev-first, minimal-interruption delivery. Compatible with Codex and Claude Code: use real subagent/Task tools when available, otherwise emulate agents as named work lanes and parallel tool calls without inventing unavailable tools.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 11 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈11

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to run complex engineering work as an autonomous, development-first collaboration workflow.

    line 8
  2. Distinctive:

    Prefer implementation and verification over long plans.

    line 12
  3. Distinctive:

    Ask only for decisions that are destructive, high-cost, production-facing, or likely to cause major rework.

    line 13
  4. Very specific:

    Use available subagent or Task tools if the runtime provides them.

    line 14
  5. Distinctive:

    Do not claim to have launched or closed real agents unless the environment actually provides those operations.

    line 15
  6. Distinctive:

    Keep one writer per file. Parallel lanes may inspect the same file, but only one lane owns edits to a file.

    line 16
  7. Distinctive:

    Only include lanes that are relevant.

    line 33
  8. Distinctive:

    Implement: run independent reads/tool calls in parallel where possible.

    line 39
  9. Distinctive:

    Verify: run targeted tests/builds and any user-facing smoke checks.

    line 41
  10. Distinctive:

    When asking, keep it to the smallest concrete decision needed.

    line 52
  11. Very specific:

    When creating reusable documents, create directories as needed.

    line 56
  12. Distinctive:

    Use Chinese by default. Keep it concise and factual.

    line 80
  13. Distinctive:

    Read references/workflow.md when the task is large, explicitly asks for multi-agent orchestration, involves more than two domains, or needs …

    line 95

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Autonomous Multi-Agent Development

Use this skill to run complex engineering work as an autonomous, development-first collaboration workflow. Optimize for a runnable result, local verification, and concise Chinese reporting.

Operating Rules

  1. Prefer implementation and verification over long plans. Produce only the minimum plan needed to coordinate safely.
  2. Ask only for decisions that are destructive, high-cost, production-facing, or likely to cause major rework.
  3. Use available subagent or Task tools if the runtime provides them. If not, emulate agents as named work lanes such as Agent-API, Agent-UI, and Agent-QA.
  4. Do not claim to have launched or closed real agents unless the environment actually provides those operations.
  5. Keep one writer per file. Parallel lanes may inspect the same file, but only one lane owns edits to a file.
  6. For code tasks, land a smallest runnable slice first, then improve quality where it matters.
  7. For document, plan, research, decision, report, or release artifacts, write files under the workspace docs tree unless the user says otherwise.
  8. Report truthfully: success, partial success, blocked, or not run, with the reason.

0-60 Second Start

For complex tasks, quickly create 3-7 work lanes before deep implementation:

Agent-0 主控: scope, dependencies, conflict control, final integration
Agent-1 定位: relevant files, impact surface, shortest fix path
Agent-2 后端: API, business logic, persistence, services
Agent-3 前端: UI, state, client integration
Agent-4 验证: tests, build, regression, delivery notes

Only include lanes that are relevant. For each lane, state: owner, files/directories, output, acceptance standard. Then proceed without waiting for user approval unless a confirmation threshold is hit.

Execution Workflow

  1. Discover: inspect repo structure, docs, OpenSpec specs, tests, and current behavior.
  2. Split: assign named lanes by ownership boundary and file responsibility.
  3. Implement: run independent reads/tool calls in parallel where possible; serialize writes that touch the same files.
  4. Integrate: reconcile lane outputs, resolve conflicts, and keep changes scoped.
  5. Verify: run targeted tests/builds and any user-facing smoke checks. Use browser/UI automation when applicable.
  6. Deliver: summarize result, changed files/commands, verification, risks, rollback notes, and next steps.

Confirmation Threshold

Continue without asking unless the next action is one of:

  • destructive or hard-to-recover changes, such as mass deletion or history rewrite
  • high-cost work, such as long full regression, heavy build, or production deploy
  • irreversible architecture, public API, or data model decision

When asking, keep it to the smallest concrete decision needed.

Documentation Output

When creating reusable documents, create directories as needed. Use openspec/ only for Spec/OpenSpec artifacts; use docs/ for supporting plans, reports, decisions, research, and release notes:

docs/plan
docs/meeting
docs/research
openspec/
docs/report
docs/decision
docs/release

Use timestamped filenames:

yyyyMMddHHmmssfff_<topic>.md

Include the actual path in the final report.

Reporting Format

Use Chinese by default. Keep it concise and factual.

结果: 一句话总体状态
Agent进度: A0-A4 或语义化 Agent 的完成项,每个 1 行
改动: 文件/命令/配置变化,按 Agent 标注
验证: 执行项与结果,按 Agent 标注
管理件: 决策记录、任务看板、风险清单,需要时提供
下一步: 最多 3 条

For small tasks, compress the format while preserving result, changes, and verification.

Detailed Reference

Read references/workflow.md when the task is large, explicitly asks for multi-agent orchestration, involves more than two domains, or needs document/spec routing.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.