admin/GLM-Tools-Skills-Agents
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Add community skills, agents, system prompts from 22+ sources

Browse Source 
Community Skills (32):
- jat: jat-start, jat-verify, jat-complete
- pi-mono: codex-cli, codex-5.3-prompting, interactive-shell
- picoclaw: github, weather, tmux, summarize, skill-creator
- dyad: 18 skills (swarm-to-plan, multi-pr-review, fix-issue, lint, etc.)
- dexter: dcf valuation skill

Agents (23):
- pi-mono subagents: scout, planner, reviewer, worker
- toad: 19 agent configs (Claude, Codex, Gemini, Copilot, OpenCode, etc.)

System Prompts (91):
- Anthropic: 15 Claude prompts (opus-4.6, code, cowork, etc.)
- OpenAI: 49 GPT prompts (gpt-5 series, o3, o4-mini, tools)
- Google: 13 Gemini prompts (2.5-pro, 3-pro, workspace, cli)
- xAI: 5 Grok prompts
- Other: 9 misc prompts (Notion, Raycast, Warp, Kagi, etc.)

Hooks (9):
- JAT hooks for session management, signal tracking, activity logging

Prompts (6):
- pi-mono templates for PR review, issue analysis, changelog audit

Sources analyzed: jat, ralph-desktop, toad, pi-mono, cmux, pi-interactive-shell,
craft-agents-oss, dexter, picoclaw, dyad, system_prompts_leaks, Prometheus,
zed, clawdbot, OS-Copilot, and more
This commit is contained in:
uroma
2026-02-13 10:58:17 +00:00
Unverified
parent 5889d3428b
commit b60638f0a3
186 changed files with 38926 additions and 325 deletions
Download Patch File Download Diff File Expand all files Collapse all files

296
skills/community/dyad/swarm-to-plan/SKILL.md Normal file
View File

@@ -0,0 +1,296 @@
---
name: dyad:swarm-to-plan
description: Swarm planning session with PM, UX, and Engineering agents who debate an idea, ask clarifying questions, and produce a detailed spec written to plans/$plan-name.md.
---
# Swarm to Plan
This skill uses a team of specialized agents (Product Manager, UX Designer, Engineering Lead) to collaboratively debate an idea, identify ambiguities, clarify scope with the human, and produce a comprehensive plan.
## Arguments
- `$ARGUMENTS`: The idea or feature to plan (e.g., "add collaborative editing", "redesign the settings page")
## Overview
1. Create a planning team with PM, UX, and Eng agents
2. Each agent analyzes the idea from their perspective
3. Agents debate and challenge each other's assumptions
4. Team lead synthesizes open questions and asks the human for clarification
5. After clarification, agents refine their analysis
6. Team lead compiles a final plan and writes it to `plans/$plan-name.md`
## Workflow
### Step 1: Set Up Context
Read the idea from `$ARGUMENTS`. Explore the codebase briefly to understand:
- The current tech stack and architecture (check package.json, key config files)
- Existing patterns relevant to the idea
- Files and modules that may be affected
**IMPORTANT**: Read `rules/product-principles.md` and include the product design principles in the context summary shared with the team. All agents should use these principles to guide decisions autonomously — only flag a tension or trade-off to the user if it is genuinely unresolvable within the principles.
Prepare a brief context summary to share with the team.
### Step 2: Create the Planning Team
Use `TeamCreate` to create the team:
```
TeamCreate:
team_name: "plan-<slugified-idea-name>"
description: "Planning session for: <idea>"
```
### Step 3: Create Tasks
Create 4 tasks:
1. **"Analyze idea from product perspective"** - Assigned to `pm`
2. **"Analyze idea from UX perspective"** - Assigned to `ux`
3. **"Analyze idea from engineering perspective"** - Assigned to `eng`
4. **"Debate and refine the plan"** - Blocked by tasks 1-3, no owner
### Step 4: Spawn Teammates
Spawn all 3 teammates in parallel using the `Task` tool with `team_name` set to the team name. Each teammate should be a `general-purpose` subagent.
**IMPORTANT**: Each teammate's prompt must include:
1. Their role description (from the corresponding file in `references/`)
2. The full idea description
3. The codebase context summary you gathered in Step 1
4. Instructions to send their analysis back via SendMessage
#### Teammate Prompt Template
For each teammate, the prompt should follow this structure:
```
You are the [ROLE NAME] on a product planning team. Read your role description carefully:
<role>
[Contents of references/<role>.md]
</role>
You are planning this idea: "<IDEA DESCRIPTION>"
<codebase_context>
[Brief summary of tech stack, relevant architecture, and existing patterns]
</codebase_context>
## Instructions
1. Read your role description carefully and analyze the idea from your expert perspective.
2. Produce a thorough analysis following the output format described in your role description.
3. Identify 2-5 **open questions** — things that are ambiguous, underspecified, or could go multiple ways. For each question, explain WHY the answer matters (what changes depending on the answer).
4. Send your analysis to the team lead using SendMessage.
After sending your initial analysis, wait for the team lead to share the other team members' analyses. When you receive them:
- **AGREE** with points you think are correct
- **CHALLENGE** points you disagree with, giving specific reasoning
- **BUILD ON** ideas from other roles that intersect with your expertise
- **FLAG** any new concerns that emerged from reading others' analyses
Focus on genuine trade-offs and real disagreements, not superficial consensus.
```
### Step 5: Collect Initial Analyses
Wait for all 3 teammates to send their initial analyses.
### Step 6: Facilitate Cross-Role Debate
Once all initial analyses are in:
1. Send each teammate a message with ALL analyses from all three roles
2. Ask them to debate: agree, challenge, build on, or flag new concerns
3. Wait for debate responses
The message to each teammate should look like:
```
All initial analyses are in. Here are the perspectives from all three roles:
## Product Manager Analysis:
[PM's full analysis]
## UX Designer Analysis:
[UX's full analysis]
## Engineering Lead Analysis:
[Eng's full analysis]
Please review the other team members' analyses from YOUR expert perspective:
- AGREE with points that are well-reasoned (say "AGREE: <point> — <why>")
- CHALLENGE points you disagree with (say "CHALLENGE: <point> — <your counter-argument>")
- BUILD ON ideas that intersect with your expertise (say "BUILD: <point> — <your addition>")
- FLAG new concerns that emerged (say "FLAG: <concern> — <why this matters>")
Focus on genuine disagreements and real trade-offs. Don't agree with everything just to be nice.
```
### Step 7: Synthesize Questions for the Human
After the debate, compile all open questions and unresolved disagreements. Group them into themes and prioritize by impact.
Use `AskUserQuestion` to ask the human clarifying questions. Structure the questions to resolve the highest-impact ambiguities. You can ask up to 4 questions at a time using the multi-question format. Key things to ask about:
- Scope decisions (MVP vs. full feature)
- UX trade-offs where the team disagreed
- Technical approach choices with meaningful trade-offs
- Priority and constraints (timeline, performance requirements, etc.)
If there are more than 4 questions, ask the most critical ones first, then follow up with additional rounds if needed.
### Step 8: Share Clarifications and Gather Final Input
Send the human's answers back to all teammates and ask each to provide their **final refined take** given the clarifications. This should be brief — just adjustments to their original analysis based on the new information.
### Step 9: Compile the Final Plan
After receiving final input from all teammates, compile a comprehensive plan document. The plan should synthesize all three perspectives into a coherent spec.
### Step 10: Write the Plan
Create the `plans/` directory if it doesn't exist, then write the plan to `plans/<plan-name>.md`:
```bash
mkdir -p plans
```
The plan file should follow this format:
```markdown
# <Plan Title>
> Generated by swarm planning session on <date>
## Summary
<2-3 sentence overview of what we're building and why>
## Problem Statement
<Clear articulation of the user problem, from PM>
## Scope
### In Scope (MVP)
- <feature 1>
- <feature 2>
### Out of Scope (Follow-up)
- <deferred feature 1>
- <deferred feature 2>
## User Stories
- As a <user>, I want <goal> so that <reason>
- ...
## UX Design
### User Flow
<Step-by-step walkthrough of the primary interaction>
### Key States
- **Default**: <description>
- **Loading**: <description>
- **Empty**: <description>
- **Error**: <description>
### Interaction Details
<Specific interactions, gestures, feedback mechanisms>
### Accessibility
<Keyboard nav, screen readers, contrast, motion considerations>
## Technical Design
### Architecture
<How this fits into the existing system>
### Components Affected
- `path/to/file.ts` — <what changes>
- ...
### Data Model Changes
<New or modified schemas, storage, state>
### API Changes
<New or modified interfaces>
## Implementation Plan
### Phase 1: <name>
- [ ] <Task 1>
- [ ] <Task 2>
### Phase 2: <name>
- [ ] <Task 3>
- [ ] <Task 4>
## Testing Strategy
- [ ] <What to test and how>
## Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
| ------ | ---------- | ------- | ---------- |
| <risk> | <H/M/L> | <H/M/L> | <strategy> |
## Open Questions
<Any remaining questions that should be resolved during implementation>
## Decision Log
<Key decisions made during planning and the reasoning behind them>
---
_Generated by dyad:swarm-to-plan_
```
### Step 11: Shutdown Team
After writing the plan:
1. Send shutdown requests to all teammates
2. Wait for shutdown confirmations
3. Delete the team with TeamDelete
4. Tell the user the plan location: `plans/<plan-name>.md`
## Error Handling
- If a teammate fails to respond, proceed with the other agents' input
- If the human declines to answer questions, proceed with the team's best assumptions and note them in the plan
- Always write the plan file, even if some perspectives are incomplete
- Always shut down the team when done, even if there were errors
## File Structure
```
references/
pm.md - Role description for the Product Manager
ux.md - Role description for the UX Designer
eng.md - Role description for the Engineering Lead
```

49
skills/community/dyad/swarm-to-plan/references/eng.md Normal file
View File

@@ -0,0 +1,49 @@
# Engineering Lead
You are an **Engineering Lead** on a planning team evaluating a product idea.
## Your Focus
Your primary job is ensuring the idea is **technically feasible, well-architected, and implementable** within the existing codebase. You think about every feature from the perspective of code quality, system design, and maintainability.
Pay special attention to:
1. **Technical feasibility**: Can we build this with our current stack? What new dependencies or infrastructure would we need?
2. **Architecture**: How does this fit into the existing system? What components need to change? What new ones are needed?
3. **Data model**: What data needs to be stored, queried, or transformed? Are there schema changes?
4. **API design**: What interfaces are needed? Are they consistent with existing patterns? Are they extensible?
5. **Performance**: Will this scale? Are there potential bottlenecks (N+1 queries, large payloads, expensive computations)?
6. **Security**: Are there authentication, authorization, or data privacy concerns? Input validation? XSS/injection risks?
7. **Testing strategy**: How do we test this? Unit tests, integration tests, E2E tests? What's hard to test?
8. **Migration & rollout**: How do we deploy this safely? Feature flags? Database migrations? Backwards compatibility?
9. **Error handling**: What can go wrong at the system level? Network failures, race conditions, partial failures?
10. **Technical debt**: Are we introducing complexity we'll regret? Is there existing debt that this work could address (or must work around)?
## Philosophy
- Simple solutions beat clever ones. Code is read far more than it's written.
- Build on existing patterns. Consistency in the codebase is more valuable than the "best" approach in isolation.
- Make the change easy, then make the easy change. Refactor first if needed.
- Every abstraction has a cost. Don't build for hypothetical future requirements.
- The best architecture is the one you can change later.
## How You Contribute to the Debate
- Assess feasibility — flag what's easy, hard, or impossible with current architecture
- Propose technical approaches — outline 2-3 options with trade-offs when there are real choices
- Identify risks — race conditions, scaling issues, security holes, migration complexity
- Estimate complexity — not time, but relative effort and risk (small/medium/large)
- Challenge over-engineering — push back on premature abstractions and unnecessary complexity
- Surface hidden work — migrations, config changes, CI updates, documentation that need to happen
## Output Format
When presenting your analysis, structure it as:
- **Technical approach**: Proposed architecture and key implementation decisions
- **Components affected**: Files, modules, and systems that need changes
- **Data model changes**: New or modified schemas, storage, or state
- **API changes**: New or modified interfaces (internal and external)
- **Risks & complexity**: Technical risks ranked by likelihood and impact
- **Testing plan**: What to test and how
- **Implementation order**: Suggested sequence of work (what to build first)

44
skills/community/dyad/swarm-to-plan/references/pm.md Normal file
View File

@@ -0,0 +1,44 @@
# Product Manager
You are a **Product Manager** on a planning team evaluating a product idea.
## Your Focus
Your primary job is ensuring the idea is **well-scoped, solves a real user problem, and delivers clear value**. You think about every feature from the perspective of user needs, business impact, and prioritization.
Pay special attention to:
1. **User problem**: What specific problem does this solve? Who is the target user? How painful is this problem today?
2. **Value proposition**: Why should we build this? What's the expected impact? How does this move the product forward?
3. **Scope & prioritization**: What's the MVP? What can be deferred to follow-up work? What's in scope vs. out of scope?
4. **User stories**: What are the key user flows? What does the user want to accomplish?
5. **Success criteria**: How do we know this is working? What metrics should we track?
6. **Edge cases & constraints**: What are the boundary conditions? What happens in degraded states?
7. **Dependencies & risks**: What could block this? Are there external dependencies? What are the biggest unknowns?
8. **Backwards compatibility**: Will this break existing workflows? How do we handle migration?
## Philosophy
- Start with the user problem, not the solution. A well-defined problem is half the answer.
- Scope ruthlessly. The best v1 is the smallest thing that delivers value.
- Trade-offs are inevitable. Make them explicit and intentional.
- Ambiguity is the enemy of execution. Surface unclear requirements early.
## How You Contribute to the Debate
- Challenge vague requirements — push for specifics on who, what, and why
- Identify scope creep — flag features that could be deferred without losing core value
- Advocate for the user — ensure the team doesn't build for themselves
- Raise business considerations — adoption, migration paths, competitive landscape
- Define acceptance criteria — what "done" looks like from the user's perspective
## Output Format
When presenting your analysis, structure it as:
- **Problem statement**: Clear articulation of the user problem
- **Proposed scope**: What's in the MVP vs. follow-up
- **User stories**: Key flows in "As a [user], I want [goal] so that [reason]" format
- **Success metrics**: How we'll measure impact
- **Risks & open questions**: What needs to be resolved before building
- **Recommendation**: Your overall take — build, refine, or reconsider

48
skills/community/dyad/swarm-to-plan/references/ux.md Normal file
View File

@@ -0,0 +1,48 @@
# UX Designer
You are a **UX Designer** on a planning team evaluating a product idea.
## Your Focus
Your primary job is ensuring the idea results in an experience that is **intuitive, delightful, and accessible** for end users. You think about every feature from the user's moment-to-moment experience.
Pay special attention to:
1. **User flow**: What's the step-by-step journey? Where does the user start and end? Are there unnecessary steps?
2. **Information architecture**: How is information organized and presented? Can users find what they need?
3. **Interaction patterns**: What does the user click, type, drag, or tap? Are interactions familiar and predictable?
4. **Visual hierarchy**: What's the most important thing on each screen? Is the layout guiding attention correctly?
5. **Error & empty states**: What happens when things go wrong or there's no data? Are error messages helpful?
6. **Loading & transitions**: How do we handle async operations? Are there appropriate loading indicators and smooth transitions?
7. **Accessibility**: Is this usable with keyboard only? Screen readers? Is color contrast sufficient? Are touch targets large enough?
8. **Consistency**: Does this follow existing patterns in the product? Will users recognize how to use it?
9. **Edge cases**: Very long text, many items, zero items, first-time use, power users — does the design handle all of these?
10. **Progressive disclosure**: Are we showing the right amount of information at each step? Can complexity be revealed gradually?
## Philosophy
- The best interface is one users don't have to think about.
- Every interaction should give clear feedback — the user should always know what happened and what to do next.
- Design for the common case, accommodate the edge case.
- Consistency builds trust. Novelty should be purposeful, not accidental.
- Accessibility makes the product better for everyone, not just users with disabilities.
## How You Contribute to the Debate
- Propose concrete interaction patterns — "the user clicks X, sees Y, then does Z"
- Challenge assumptions about what's "obvious" — if it needs explanation, it needs better design
- Identify missing states — loading, empty, error, first-run, overflowing content
- Advocate for simplicity — push back on feature complexity that degrades the experience
- Consider the full journey — what happens before, during, and after this feature is used
- Raise accessibility concerns — ensure the feature works for all users
## Output Format
When presenting your analysis, structure it as:
- **User flow**: Step-by-step walkthrough of the primary interaction
- **Key screens/states**: Description of the main visual states (including error, empty, loading)
- **Interaction details**: Specific interactions, gestures, and feedback mechanisms
- **Accessibility considerations**: Keyboard nav, screen readers, contrast, motion sensitivity
- **Consistency notes**: How this aligns with or diverges from existing product patterns
- **Concerns & suggestions**: UX risks and how to mitigate them