Phase 2 - Deep Analysis:
- Algorithm correctness
- Edge case handling
- Error handling completeness
- Resource management
Phase 3 - Context Evaluation:
- Breaking changes to public APIs
- Side effects on existing functionality
- Dependency compatibility
Phase 4 - Standards Compliance:
- Naming conventions
- Documentation requirements
- Test coverage
</example>
Security:
- Input validation
- Authentication/authorization
- Data sanitization
- Secrets handling
Performance:
- Algorithm efficiency
- Resource usage
- Memory leaks
- N+1 queries
Maintainability:
- Clear naming
- Appropriate comments
- Single responsibility
- DRY principle
Testability:
- Test coverage adequate
- Tests meaningful
- Edge cases tested
</example>
Important: Should fix before merge
- Logic errors
- Missing error handling
- Performance issues
Suggestion: Nice to have improvements
- Code style
- Refactoring opportunities
- Documentation
Positive: What was done well
- Good patterns
- Clever solutions
- Thorough testing
</example>
1---2name: execution-workflow3description: This skill should be used when the user asks to "execute task", "implement feature", "delegate work", "run workflow", "review code", "code quality check", or needs task orchestration and code review guidance. Provides execution, delegation, and code review patterns.4---5
6<purpose>
7 Provide structured workflow for task execution through delegation to specialized sub-agents, and comprehensive code review standards.
8</purpose>
9
10<tools>
11 <tool name="agent_groups">Specialized sub-agents: quality_assurance (quality, security - parallel), implementation (test, refactor, docs - parallel if independent), review (sequential after implementation)</tool>
12 <tool name="delegation">Provide scope, file paths, Serena/Context7 tool instructions, reference implementations, memory checks</tool>
13 <tool name="tool_selection">Coding: Codex MCP → Serena MCP → Context7 → Basic tools; Non-coding: Serena MCP → Context7 → Basic tools</tool>
14</tools>
15
16<concepts>
17 <concept name="parallel_execution">Execute independent tasks concurrently; quality+security can run in parallel, test+docs can run in parallel when independent</concept>
18 <concept name="sequential_dependencies">Tasks with data dependencies must run in order; verify outputs before dependent tasks start</concept>
19 <concept name="delegation_context">Sub-agents need: specific scope, file paths, tool usage instructions, reference implementations, memory patterns</concept>
20 <concept name="review_phases">Four phases: Initial scan (syntax), Deep analysis (logic), Context evaluation (impact), Standards compliance (naming/docs)</concept>
21</concepts>
22
23<patterns>
24 <pattern name="code_review_phases">
25 <description>Systematic code review process</description>
26 <decision_tree name="when_to_use">
27 <question>Has code been modified or newly created?</question>
28 <if_yes>Apply code review phases systematically to ensure quality</if_yes>
29 <if_no>Skip review and proceed to next task</if_no>
30 </decision_tree>
31 <example>
32 Phase 1 - Initial Scan:
33 - Syntax errors and typos
34 - Missing imports or dependencies
35 - Obvious logic errors
36 - Code style violations
37
38 Phase 2 - Deep Analysis:
39
40 - Algorithm correctness
41 - Edge case handling
42 - Error handling completeness
43 - Resource management
44
45 Phase 3 - Context Evaluation:
46
47 - Breaking changes to public APIs
48 - Side effects on existing functionality
49 - Dependency compatibility
50
51 Phase 4 - Standards Compliance:
52
53 - Naming conventions
54 - Documentation requirements
55 - Test coverage
56 </example>
57 </pattern>
58
59 <pattern name="quality_criteria">
60 <description>Evaluation criteria for code quality</description>
61 <decision_tree name="when_to_use">
62 <question>Is this a code review or quality assessment task?</question>
63 <if_yes>Apply quality criteria across all dimensions</if_yes>
64 <if_no>Focus on implementation patterns instead</if_no>
65 </decision_tree>
66 <example>
67 Correctness:
68 - Logic matches requirements
69 - Edge cases handled
70 - Error conditions covered
71
72 Security:
73
74 - Input validation
75 - Authentication/authorization
76 - Data sanitization
77 - Secrets handling
78
79 Performance:
80
81 - Algorithm efficiency
82 - Resource usage
83 - Memory leaks
84 - N+1 queries
85
86 Maintainability:
87
88 - Clear naming
89 - Appropriate comments
90 - Single responsibility
91 - DRY principle
92
93 Testability:
94
95 - Test coverage adequate
96 - Tests meaningful
97 - Edge cases tested
98 </example>
99 </pattern>
100
101 <pattern name="feedback_categories">
102 <description>Categorization of review feedback by priority</description>
103 <decision_tree name="when_to_use">
104 <question>Have you identified issues during code review?</question>
105 <if_yes>Apply feedback categories to prioritize by severity</if_yes>
106 <if_no>Continue code review phases</if_no>
107 </decision_tree>
108 <example>
109 Critical: Must fix before merge
110 - Security vulnerabilities
111 - Data corruption risks
112 - Breaking changes
113
114 Important: Should fix before merge
115
116 - Logic errors
117 - Missing error handling
118 - Performance issues
119
120 Suggestion: Nice to have improvements
121
122 - Code style
123 - Refactoring opportunities
124 - Documentation
125
126 Positive: What was done well
127
128 - Good patterns
129 - Clever solutions
130 - Thorough testing
131 </example>
132 </pattern>
133
134 <pattern name="review_output_format">
135 <description>Standard format for code review results</description>
136 <decision_tree name="when_to_use">
137 <question>Is it time to communicate code review findings?</question>
138 <if_yes>Apply review output format for structured communication</if_yes>
139 <if_no>Continue analyzing code through review phases</if_no>
140 </decision_tree>
141 <example>
142 <summary>Overall assessment and recommendation</summary>
143 <critical_issues>Must-fix items with file:line references</critical_issues>
144 <important_issues>Should-fix items</important_issues>
145 <suggestions>Optional improvements</suggestions>
146 <positive_feedback>Good practices observed</positive_feedback>
147 <questions>Clarifications needed</questions>
148 </example>
149 </pattern>
150</patterns>
151
152<anti_patterns>
153 <avoid name="nitpicking_style">
154 <description>Focusing on code style issues when functionality is broken</description>
155 <instead>Address critical and important issues first, style suggestions last</instead>
156 </avoid>
157 <avoid name="rubber_stamping">
158 <description>Approving changes without thorough review</description>
159 <instead>Systematically review all phases: scan, deep analysis, context, standards</instead>
160 </avoid>
161 <avoid name="only_negatives">
162 <description>Providing only critical feedback without acknowledging good work</description>
163 <instead>Balance feedback with positive observations of good practices</instead>
164 </avoid>
165 <avoid name="vague_feedback">
166 <description>Giving feedback without specific, actionable suggestions</description>
167 <instead>Provide file:line references and concrete improvement suggestions</instead>
168 </avoid>
169 <avoid name="sequential_when_parallel">
170 <description>Executing independent tasks sequentially</description>
171 <instead>Identify and execute independent tasks in parallel for efficiency</instead>
172 </avoid>
173 <avoid name="parallel_when_dependent">
174 <description>Attempting to parallelize tasks with data dependencies</description>
175 <instead>Analyze dependencies and execute dependent tasks sequentially</instead>
176 </avoid>
177</anti_patterns>
178
179<workflow>
180 <phase name="analyze">
181 <description>Understand requirements and identify scope</description>
182 <step>Parse task description for key objectives</step>
183 <step>Identify affected files and components</step>
184 <step>Check Serena memories for existing patterns</step>
185 </phase>
186 <phase name="break_down">
187 <description>Split into manageable units</description>
188 <step>Identify atomic tasks</step>
189 <step>Estimate complexity of each task</step>
190 <step>Assign to appropriate sub-agents</step>
191 </phase>
192 <phase name="organize">
193 <description>Identify parallel vs sequential execution</description>
194 <step>Map task dependencies</step>
195 <step>Group independent tasks for parallel execution</step>
196 <step>Order dependent tasks sequentially</step>
197 </phase>
198 <phase name="delegate">
199 <description>Assign to sub-agents with detailed instructions</description>
200 <step>Provide specific scope and expected deliverables</step>
201 <step>Include target file paths</step>
202 <step>Specify MCP tool usage instructions</step>
203 <step>Reference existing implementations</step>
204 </phase>
205 <phase name="integrate">
206 <description>Verify and combine results</description>
207 <step>Review sub-agent outputs</step>
208 <step>Resolve conflicts between outputs</step>
209 <step>Ensure consistency across changes</step>
210 </phase>
211</workflow>
212
213<best_practices>
214 <practice priority="critical">Analyze task dependencies before execution to determine parallel vs sequential execution model</practice>
215 <practice priority="critical">Provide comprehensive context to sub-agents including file paths, tool usage, and reference implementations</practice>
216 <practice priority="critical">Systematically review all phases: initial scan, deep analysis, context evaluation, standards compliance</practice>
217 <practice priority="high">Balance critical feedback with positive observations of good practices</practice>
218 <practice priority="high">Provide file:line references and concrete improvement suggestions</practice>
219 <practice priority="medium">Check Serena memories for existing patterns before delegating implementation tasks</practice>
220</best_practices>
221
222<rules priority="critical">
223 <rule>Execute independent tasks in parallel</rule>
224 <rule>Never parallelize tasks with data dependencies</rule>
225 <rule>Verify sub-agent outputs before integration</rule>
226 <rule>Run quality checks after changes</rule>
227</rules>
228
229<rules priority="standard">
230 <rule>quality + security: Concurrent checks</rule>
231 <rule>test + docs: Simultaneous creation when independent</rule>
232 <rule>Ensure no regression in existing functionality</rule>
233 <rule>Confirm all acceptance criteria met</rule>
234</rules>
235
236<error_escalation>
237 <level severity="low">
238 <example>Sub-agent returns partial results</example>
239 <action>Note in report, proceed</action>
240 </level>
241 <level severity="medium">
242 <example>Sub-agent task fails</example>
243 <action>Document issue, use AskUserQuestion for clarification</action>
244 </level>
245 <level severity="high">
246 <example>Critical task cannot be completed</example>
247 <action>STOP, present options to user</action>
248 </level>
249 <level severity="critical">
250 <example>Sub-agent introduces breaking change</example>
251 <action>BLOCK operation, require explicit user acknowledgment</action>
252 </level>
253</error_escalation>
254
255<related_agents>
256 <agent name="execute">Primary agent for implementing features with sub-agent delegation</agent>
257 <agent name="feedback">Use for post-implementation code review and quality assessment</agent>
258 <agent name="bug">Delegate debugging tasks when critical issues are identified during review</agent>
259</related_agents>
260
261<related_skills>
262 <skill name="serena-usage">Use for memory checks and symbol operations during delegation</skill>
263 <skill name="investigation-patterns">Use when code review reveals unclear implementation details</skill>
264 <skill name="testing-patterns">Use to verify test coverage and quality during review</skill>
265</related_skills>
266
267<constraints>
268 <must>Delegate detailed work to sub-agents</must>
269 <must>Execute independent tasks in parallel</must>
270 <must>Verify outputs before integration</must>
271 <avoid>Implementing detailed logic directly</avoid>
272 <avoid>Sequential execution of independent tasks</avoid>
273 <avoid>Skipping verification of sub-agent outputs</avoid>
274</constraints>
majiayu000