Awesome-omni-skill flow-engineer-subagent
Guide for creating effective Subagents (custom agent definitions). Use when users want to create a new subagent, set up task-specific agents, configure code reviewers, debuggers, or domain-specific assistants. Works across IDEs (Cursor, OpenCode).
git clone https://github.com/diegosouzapw/awesome-omni-skill
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data-ai/flow-engineer-subagent" ~/.claude/skills/diegosouzapw-awesome-omni-skill-flow-engineer-subagent-20690f && rm -rf "$T"
skills/data-ai/flow-engineer-subagent/SKILL.mdSubagent Creator
This skill guides through creating effective Subagents — custom agent definitions that provide specialized AI assistants with focused system prompts.
About Subagents
Subagents are specialized AI assistants that extend agent capabilities with:
- Focused behavior — custom system prompts for specific domains or tasks
- Context isolation — separate conversations that preserve your main context
- Reusable configurations — shareable agent definitions across projects or users
IDE Detection and Subagent Placement
Subagents work across multiple IDEs. Before creating a subagent, determine the current environment and ask the user where to place it.
Control Primitives Map by IDE
| Primitive | Scope | Cursor | Claude Code | OpenCode |
|---|---|---|---|---|
| Custom Agents (Subagents) | User | | | |
| Project | | | |
Subagent-Specific Paths
| IDE | Personal Subagents | Project Subagents |
|---|---|---|
| Cursor | | |
| Claude Code | | |
| OpenCode | | |
Detection Strategy
- Check for IDE-specific markers in the project:
directory → Cursor.cursor/
directory → Claude Code.claude/
directory or.opencode/
→ OpenCodeopencode.json
- If multiple detected or none → ask the user
- Ask: personal subagent (user-level) or project subagent (shared via repo)?
IMPORTANT: Never create subagents in
~/.cursor/agents-cursor/ (reserved for Cursor internals) or other IDE-reserved directories.
Core Principles
Focused Specialization
Each subagent should excel at one specific task.
- Good:
— focused on reviewing code qualitycode-reviewer - Bad:
— too broad, overlaps with default agenthelper
Clear Delegation Triggers
The description determines when the main agent delegates to this subagent.
| Freedom Level | When to Use | Example |
|---|---|---|
| High (manual) | User explicitly requests | "Use the data-analyst to..." |
| Medium (suggested) | Agent suggests based on context | "Consider using debugger for errors" |
| Low (proactive) | Automatic delegation on pattern match | "Use code-reviewer after code changes" |
Anatomy of a Subagent
Every subagent is a
.md file with YAML frontmatter and a markdown body:
my-agent.md ├── Frontmatter (YAML) # Metadata: name, description, mode, etc. └── Body (Markdown) # System prompt: behavior, workflow, constraints
Frontmatter Structure
Cursor Format
--- name: code-reviewer description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code. model: inherit readonly: false ---
Cursor Additional Fields
| Field | Description | Default |
|---|---|---|
| Agent name | Required |
| Task description and role definition | Required |
| Suggested model (, , , or model ID) | Inherits from conversation |
| If , restricts agent to read-only tools (no file edits, shell writes) | |
OpenCode Format
--- description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code. mode: subagent model: gpt-4o temperature: 0.3 permission: auto ---
OpenCode Additional Fields
| Field | Description | Default |
|---|---|---|
| / / | |
| Specific model string | Inherits from conversation |
| Creativity (0.0-2.0) | Inherits |
| Nucleus sampling (0.0-1.0) | Inherits |
| Max reasoning steps | Inherits |
| Allowed tools | Inherits |
| / / | Inherits |
| UI color code | Inherited |
| Hide from UI | |
| Disable subagent | |
Writing Effective Descriptions
The description is critical - the AI uses it to decide when to delegate.
Rules
-
Third person (injected into system prompt):
- Good: "Reviews code for quality and best practices"
- Bad: "I review code for quality and best practices"
-
Specific with trigger terms:
- Good: "Debugging specialist for errors, test failures, and unexpected behavior. Use proactively when encountering any issues."
- Bad: "Helps with debugging"
-
Include WHAT and WHEN:
- WHAT: specific capabilities
- WHEN: trigger scenarios (proactive, suggested, manual)
-
Action verbs: Start with verbs describing what the subagent does.
Examples
# ❌ Too vague description: Helps with code # ❌ Not specific enough description: Code reviewer # ✅ Specific and actionable description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
Common Subagent Types
Code Reviewer
--- name: code-reviewer description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code. --- You are a senior code reviewer ensuring high standards of code quality and security. When invoked: 1. Run git diff to see recent changes 2. Focus on modified files 3. Begin review immediately Review checklist: - Code is clear and readable - Functions and variables are well-named - No duplicated code - Proper error handling - No exposed secrets or API keys - Input validation implemented - Good test coverage - Performance considerations addressed Provide feedback organized by priority: - Critical issues (must fix) - Warnings (should fix) - Suggestions (consider improving) Include specific examples of how to fix issues.
Debugger
--- name: debugger description: Debugging specialist for errors, test failures, and unexpected behavior. Use proactively when encountering any issues. --- You are an expert debugger specializing in root cause analysis. When invoked: 1. Capture error message and stack trace 2. Identify reproduction steps 3. Isolate the failure location 4. Implement minimal fix 5. Verify solution works Debugging process: - Analyze error messages and logs - Check recent code changes - Form and test hypotheses - Add strategic debug logging - Inspect variable states For each issue, provide: - Root cause explanation - Evidence supporting the diagnosis - Specific code fix - Testing approach - Prevention recommendations Focus on fixing the underlying issue, not the symptoms.
Data Scientist
--- name: data-scientist description: Data analysis expert for SQL queries, BigQuery operations, and data insights. Use proactively for data analysis tasks and queries. --- You are a data scientist specializing in SQL and BigQuery analysis. When invoked: 1. Understand the data analysis requirement 2. Write efficient SQL queries 3. Use BigQuery command line tools (bq) when appropriate 4. Analyze and summarize results 5. Present findings clearly Key practices: - Write optimized SQL queries with proper filters - Use appropriate aggregations and joins - Include comments explaining complex logic - Format results for readability - Provide data-driven recommendations For each analysis: - Explain the query approach - Document any assumptions - Highlight key findings - Suggest next steps based on data Always ensure queries are efficient and cost-effective.
Documentation Specialist
--- name: docs-specialist description: Technical documentation expert for API docs, README files, and inline comments. Use proactively when writing or updating documentation. --- You are a technical documentation specialist focused on clarity and completeness. When invoked: 1. Understand the code or feature being documented 2. Identify target audience (developers, users, etc.) 3. Structure documentation logically 4. Write clear, concise explanations 5. Include examples and use cases Documentation principles: - Start with user's goal, not implementation - Provide concrete examples - Keep explanations simple and direct - Use consistent terminology - Link to related topics For each documentation piece: - Overview (what and why) - Quick start (minimal example) - Reference (detailed parameters) - Examples (common use cases) - Troubleshooting (common issues)
Subagent Creation Workflow
Phase 1: Discovery
Gather from user:
- Purpose and primary use case
- Target IDE and storage location (personal vs project)
- Delegation behavior (proactive, suggested, or manual)
- Domain knowledge the agent needs
- Workflow or process to follow
- Output format preferences
If context from prior conversation exists, infer the subagent from discussed workflows or specialized tasks.
Phase 2: Design
- Draft subagent name (lowercase letters and hyphens only)
- Write specific, third-person description with WHAT + WHEN
- Define workflow process (checklists, steps)
- Identify constraints or guidelines
- Determine delegation triggers
Phase 3: Implementation
-
Create the file in the IDE-appropriate location:
# Cursor (project-level) mkdir -p .cursor/agents && touch .cursor/agents/my-agent.md # Claude Code (project-level) mkdir -p .claude/agents && touch .claude/agents/my-agent.md # OpenCode (project-level) mkdir -p .opencode/agents && touch .opencode/agents/my-agent.md -
Write the frontmatter with required fields:
- Cursor:
,name
; optionaldescription
,modelreadonly - Claude Code:
,name
; optionaldescriptionmodel - OpenCode:
, optionaldescription
,mode
, etc.model
- Cursor:
-
Write the system prompt body:
- Purpose and role
- When/how to invoke
- Workflow process
- Output format
- Constraints and guidelines
Phase 4: Verification
Test the subagent:
# Test by asking the main agent to use it "Use the my-agent subagent to [task description]"
Checklist:
- Description is specific, includes trigger terms, WHAT + WHEN
- Written in third person
- Consistent terminology
- Clear workflow or process
- Appropriate delegation behavior (proactive/suggested/manual)
- File placed in correct location
- YAML frontmatter is valid
Phase 5: Iterate
- Use subagent on real tasks
- Notice struggles or inefficiencies
- Update description or system prompt
- Test again
Best Practices
- One task per subagent: Each should excel at one specific task
- Write detailed descriptions: Include trigger terms so the AI knows when to delegate
- Check into version control: Share project subagents with your team
- Use proactive language: Include "use proactively" in descriptions for automatic delegation
- Define clear workflows: Use checklists or step-by-step processes
- Provide examples: Show what good output looks like
Anti-Patterns
- Overly broad scope:
notgeneral-helpercode-reviewer - Vague descriptions: "Helps with code" vs "Reviews code for quality and best practices"
- Missing delegation triggers: No "use proactively" or trigger terms
- Too many options: Provide a preferred approach with escape hatch
- Inconsistent terminology: Pick one term, use throughout
- Windows paths: Use
, notscripts/helper.pyscripts\helper.py
Comparison with Skills
| Aspect | Skills | Subagents |
|---|---|---|
| Purpose | Teach agent how to do something | Define a specialized assistant |
| Format | Directory with | Single file |
| Context | Loaded as reference when triggered | Isolated conversation context |
| Use case | Reusable workflows and patterns | Specialized behavior or domain expertise |
| Scope | Procedural knowledge | Behavioral specialization |
Choose Skills when you want to extend the main agent's capabilities with new workflows or knowledge.
Choose Subagents when you want a separate assistant with a focused role and isolated context.