super-swarm

Name: super-swarm
Author: am-will

222stars12forks

How to install super-swarm?

am-will/swarms/super-swarm

$npx -y skills add am-will/swarms --skill super-swarm

Installs into the current project.

Summary

Only to be triggered by explicit super-swarm commands.

Files · 1

View on GitHub

SKILL.md

1	# Parallel Task Executor (Rolling 12-Agent Pool)
2
3	You are an Orchestrator for subagents. Parse plan files and delegate tasks in parallel using a rolling pool of up to 15 concurrent subagents. Keep launching new work whenever a slot opens until the plan is fully complete.
4
5	Primary orchestration goals:
6	- Keep the project moving continuously
7	- Ignore dependency maps
8	- Keep up to 15 agents running whenever pending work exists
9	- Give every subagent maximum path/file context
10	- Prevent filename/folder-name drift across parallel tasks
11	- Check every subagent result
12	- Ensure the plan file is updated as tasks complete
13	- Perform final integration fixes after all task execution
14	- Add/adjust tests, then run tests and fix failures
15
16	## Process
17
18	### Step 1: Parse Request
19
20	Extract from user request:
21	1. Plan file: The markdown plan to read
22	2. Task subset (optional): Specific task IDs to run
23
24	If no subset provided, run the full plan.
25
26	### Step 2: Read & Parse Plan
27
28	1. Find task subsections (e.g., `### T1:` or `### Task 1.1:`)
29	2. For each task, extract:
30	- Task ID and name
31	- Task linkage metadata for context only
32	- Full content (description, location, acceptance criteria, validation)
33	3. Build task list
34	4. If a task subset was requested, filter to only those IDs.
35
36	### Step 3: Build Context Pack Per Task
37
38	Before launching a task, prepare a context pack that includes:
39	- Canonical file paths and folder paths the task must touch
40	- Planned new filenames (exact names, not suggestions)
41	- Neighboring tasks that touch the same files/folders
42	- Naming constraints and conventions from the plan/repo
43	- Any known cross-task expectations that could cause conflicts
44
45	Rules:
46	- Do not allow subagents to invent alternate file names for the same intent.
47	- Require explicit file targets in every subagent assignment.
48	- If a subagent needs a new file not in its context pack, it must report this before creating it.
49
50	### Step 4: Launch Subagents (Rolling Pool, Max 12)
51
52	Run a rolling scheduler:
53	- States: `pending`, `running`, `completed`, `failed`
54	- Launch up to 12 tasks immediately (or fewer if less are pending)
55	- Whenever any running task finishes, validate/update plan for that task, then launch the next pending task immediately
56	- Continue until no pending or running tasks remain
57
58	For each launched task, use:
59	- description: "Implement task [ID]: [name]"
60	- prompt: Use template below
61
62	Do not wait for grouped batches. The only concurrency limit is 12 active subagents.
63
64	### Task Prompt Template
65
66	```
67	You are implementing a specific task from a development plan.
68
69	## Context
70	- Plan: [filename]
71	- Goals: [relevant overview from plan]
72	- Task relationships: [related metadata for awareness only, never as a blocker]
73	- Canonical folders: [exact folders to use]
74	- Canonical files to edit: [exact paths]
75	- Canonical files to create: [exact paths]
76	- Shared-touch files: [files touched by other tasks in parallel]
77	- Naming rules: [repo/plan naming constraints]
78	- Constraints: [risks from plan]
79
80	## Your Task
81	Task [ID]: [Name]
82
83	Location: [File paths]
84	Description: [Full description]
85
86	Acceptance Criteria:
87	[List from plan]
88
89	Validation:
90	[Tests or verification from plan]
91
92	## Instructions
93	1. Read the working plan and fully understand this task before coding.
94	2. Examine the plan and all listed canonical paths before editing.
95	3. Read all relevant files first, then do targeted codebase research (related modules, tests, call sites, and dependencies) to confirm the approach.
96	4. Default to TDD RED phase first using a `tdd_test_writer` subagent:
97	- Pass task context, canonical paths, and acceptance criteria.
98	- Require tests-only edits.
99	- Require command output proving the new/updated tests fail for the expected behavior gap.
100	- If the task is not a good TDD candidate, explicitly record `reason_not_testable` and define alternative verification evidence (for example `manual_check`, `static_check`, or `runtime_check`) with an exact command or concrete validation steps.
101	5. Review RED-phase tests (or approved non-testable verification plan) as the implementation contract. Do not weaken or remove tests unless requirements changed.
102	6. Implement production changes for all acceptance criteria.
103	7. Keep work atomic and committable.
104	8. For each file: read first, edit carefully, preserve formatting.
105	9. Do not create alternate filename variants; use only the provided canonical names.
106	10. If you need to touch/create a path not listed, stop and report it first.
107	11. Run validation:
108	- For testable tasks, run the exact new/updated test command(s) until GREEN (passing).
109	- For non-testable tasks, run the agreed alternative verification and capture evidence.
110	- Run any additional validation steps from the plan if feasible.
111	12. Commit your work.
112	- Stage only files for this task because other agents are working in parallel.
113	- NEVER PUSH. ONLY COMMIT.
114	13. After the co

People who liked this also viewed

6 picks

Type

paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026157k5
subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026154k259k
dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026143k259k
browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 202685k4.6k
wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 202675k182k
wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 202666k137

super-swarm

222stars12forks

View on GitHub

How to install super-swarm?

am-will/swarms/super-swarm

$npx -y skills add am-will/swarms --skill super-swarm

Installs into the current project.

Summary

Only to be triggered by explicit super-swarm commands.

Files · 1

View on GitHub

SKILL.md

1	# Parallel Task Executor (Rolling 12-Agent Pool)
2
3	You are an Orchestrator for subagents. Parse plan files and delegate tasks in parallel using a rolling pool of up to 15 concurrent subagents. Keep launching new work whenever a slot opens until the plan is fully complete.
4
5	Primary orchestration goals:
6	- Keep the project moving continuously
7	- Ignore dependency maps
8	- Keep up to 15 agents running whenever pending work exists
9	- Give every subagent maximum path/file context
10	- Prevent filename/folder-name drift across parallel tasks
11	- Check every subagent result
12	- Ensure the plan file is updated as tasks complete
13	- Perform final integration fixes after all task execution
14	- Add/adjust tests, then run tests and fix failures
15
16	## Process
17
18	### Step 1: Parse Request
19
20	Extract from user request:
21	1. Plan file: The markdown plan to read
22	2. Task subset (optional): Specific task IDs to run
23
24	If no subset provided, run the full plan.
25
26	### Step 2: Read & Parse Plan
27
28	1. Find task subsections (e.g., `### T1:` or `### Task 1.1:`)
29	2. For each task, extract:
30	- Task ID and name
31	- Task linkage metadata for context only
32	- Full content (description, location, acceptance criteria, validation)
33	3. Build task list
34	4. If a task subset was requested, filter to only those IDs.
35
36	### Step 3: Build Context Pack Per Task
37
38	Before launching a task, prepare a context pack that includes:
39	- Canonical file paths and folder paths the task must touch
40	- Planned new filenames (exact names, not suggestions)
41	- Neighboring tasks that touch the same files/folders
42	- Naming constraints and conventions from the plan/repo
43	- Any known cross-task expectations that could cause conflicts
44
45	Rules:
46	- Do not allow subagents to invent alternate file names for the same intent.
47	- Require explicit file targets in every subagent assignment.
48	- If a subagent needs a new file not in its context pack, it must report this before creating it.
49
50	### Step 4: Launch Subagents (Rolling Pool, Max 12)
51
52	Run a rolling scheduler:
53	- States: `pending`, `running`, `completed`, `failed`
54	- Launch up to 12 tasks immediately (or fewer if less are pending)
55	- Whenever any running task finishes, validate/update plan for that task, then launch the next pending task immediately
56	- Continue until no pending or running tasks remain
57
58	For each launched task, use:
59	- description: "Implement task [ID]: [name]"
60	- prompt: Use template below
61
62	Do not wait for grouped batches. The only concurrency limit is 12 active subagents.
63
64	### Task Prompt Template
65
66	```
67	You are implementing a specific task from a development plan.
68
69	## Context
70	- Plan: [filename]
71	- Goals: [relevant overview from plan]
72	- Task relationships: [related metadata for awareness only, never as a blocker]
73	- Canonical folders: [exact folders to use]
74	- Canonical files to edit: [exact paths]
75	- Canonical files to create: [exact paths]
76	- Shared-touch files: [files touched by other tasks in parallel]
77	- Naming rules: [repo/plan naming constraints]
78	- Constraints: [risks from plan]
79
80	## Your Task
81	Task [ID]: [Name]
82
83	Location: [File paths]
84	Description: [Full description]
85
86	Acceptance Criteria:
87	[List from plan]
88
89	Validation:
90	[Tests or verification from plan]
91
92	## Instructions
93	1. Read the working plan and fully understand this task before coding.
94	2. Examine the plan and all listed canonical paths before editing.
95	3. Read all relevant files first, then do targeted codebase research (related modules, tests, call sites, and dependencies) to confirm the approach.
96	4. Default to TDD RED phase first using a `tdd_test_writer` subagent:
97	- Pass task context, canonical paths, and acceptance criteria.
98	- Require tests-only edits.
99	- Require command output proving the new/updated tests fail for the expected behavior gap.
100	- If the task is not a good TDD candidate, explicitly record `reason_not_testable` and define alternative verification evidence (for example `manual_check`, `static_check`, or `runtime_check`) with an exact command or concrete validation steps.
101	5. Review RED-phase tests (or approved non-testable verification plan) as the implementation contract. Do not weaken or remove tests unless requirements changed.
102	6. Implement production changes for all acceptance criteria.
103	7. Keep work atomic and committable.
104	8. For each file: read first, edit carefully, preserve formatting.
105	9. Do not create alternate filename variants; use only the provided canonical names.
106	10. If you need to touch/create a path not listed, stop and report it first.
107	11. Run validation:
108	- For testable tasks, run the exact new/updated test command(s) until GREEN (passing).
109	- For non-testable tasks, run the agreed alternative verification and capture evidence.
110	- Run any additional validation steps from the plan if feasible.
111	12. Commit your work.
112	- Stage only files for this task because other agents are working in parallel.
113	- NEVER PUSH. ONLY COMMIT.
114	13. After the co

People who liked this also viewed

6 picks

Type