|
| 1 | +--- |
| 2 | +name: plan-and-execute |
| 3 | +description: Automatically plan and execute tasks from issue documents. Reads issue requirements, creates a task list at the end of the document, and systematically executes each task while updating progress. Use when working with issue documents, task planning, or when you need to break down and execute complex multi-step requirements. |
| 4 | +--- |
| 5 | + |
| 6 | +# Plan and Execute |
| 7 | + |
| 8 | +This Skill helps you automatically plan and execute tasks based on issue documents. It reads your requirements, creates a structured task list directly in the document, and systematically works through each task while keeping the document updated with progress. |
| 9 | + |
| 10 | +## Quick Start |
| 11 | + |
| 12 | +When you need to work through an issue document: |
| 13 | + |
| 14 | +1. The Skill will first ask you for the issue document path |
| 15 | +2. It reads the document to understand requirements |
| 16 | +3. Creates a task list at the end of the document |
| 17 | +4. Executes tasks one by one, updating status in real-time |
| 18 | + |
| 19 | +## Instructions |
| 20 | + |
| 21 | +### Step 1: Get the issue document path |
| 22 | + |
| 23 | +Ask the user for the path to their issue document: |
| 24 | + |
| 25 | +``` |
| 26 | +What is the path to your issue document? |
| 27 | +``` |
| 28 | + |
| 29 | +The document can be in any text format (.md, .txt, etc.) that contains task requirements or feature descriptions. |
| 30 | + |
| 31 | +### Step 2: Read and analyze the issue document |
| 32 | + |
| 33 | +Use the Read tool to load the document content and analyze: |
| 34 | + |
| 35 | +- What are the main requirements? |
| 36 | +- What tasks need to be completed? |
| 37 | +- Are there dependencies between tasks? |
| 38 | +- What is the complexity level? |
| 39 | + |
| 40 | +### Step 3: Create the task list |
| 41 | + |
| 42 | +Create a structured task list at the END of the issue document using this format: |
| 43 | + |
| 44 | +```markdown |
| 45 | +## Task List |
| 46 | + |
| 47 | +- [ ] Task 1 description |
| 48 | +- [ ] Task 2 description |
| 49 | +- [ ] Task 3 description |
| 50 | + |
| 51 | +### Task Status Legend |
| 52 | +- [ ] Pending |
| 53 | +- [>] In Progress |
| 54 | +- [x] Completed |
| 55 | +``` |
| 56 | + |
| 57 | +Use the Edit tool to append this section to the document. Break down complex requirements into specific, actionable tasks. |
| 58 | + |
| 59 | +### Step 4: Execute tasks systematically |
| 60 | + |
| 61 | +For each task in the list: |
| 62 | + |
| 63 | +1. **Mark as in progress**: Update the task in the document from `[ ]` to `[>]` |
| 64 | +2. **Execute the task**: Use appropriate tools to complete the work |
| 65 | +3. **Mark as completed**: Update the task from `[>]` to `[x]` when finished |
| 66 | +4. **Move to next task**: Only ONE task should be in progress at a time |
| 67 | + |
| 68 | +Important rules: |
| 69 | +- Always update the document BEFORE starting work on a task |
| 70 | +- Always update the document IMMEDIATELY after completing a task |
| 71 | +- Never work on multiple tasks simultaneously |
| 72 | +- If you encounter errors, keep the task as `[>]` and create new tasks to resolve blockers |
| 73 | + |
| 74 | +### Step 5: Handle task breakdown |
| 75 | + |
| 76 | +If during execution you discover a task is more complex than expected: |
| 77 | + |
| 78 | +1. Keep the current task as `[>]` |
| 79 | +2. Add new sub-tasks below it with indentation: |
| 80 | + ```markdown |
| 81 | + - [>] Main task |
| 82 | + - [ ] Sub-task 1 |
| 83 | + - [ ] Sub-task 2 |
| 84 | + ``` |
| 85 | +3. Complete sub-tasks first, then mark the main task as complete |
| 86 | + |
| 87 | +### Step 6: Final verification |
| 88 | + |
| 89 | +After all tasks are completed (`[x]`): |
| 90 | + |
| 91 | +1. Review the issue requirements to ensure everything is addressed |
| 92 | +2. Run any final checks (tests, builds, linting) |
| 93 | +3. Add a completion summary at the end of the document |
| 94 | + |
| 95 | +## Task State Symbols |
| 96 | + |
| 97 | +- `[ ]` - **Pending**: Not started yet |
| 98 | +- `[>]` - **In Progress**: Currently working on this |
| 99 | +- `[x]` - **Completed**: Finished successfully |
| 100 | +- `[!]` - **Blocked**: Cannot proceed (optional, for blocked tasks) |
| 101 | + |
| 102 | +## Examples |
| 103 | + |
| 104 | +### Example 1: Simple feature request |
| 105 | + |
| 106 | +**Issue document (before):** |
| 107 | +```markdown |
| 108 | +# Feature: Add dark mode toggle |
| 109 | + |
| 110 | +Users should be able to switch between light and dark themes. |
| 111 | +The toggle should be in the settings page. |
| 112 | +``` |
| 113 | + |
| 114 | +**Issue document (after task list added):** |
| 115 | +```markdown |
| 116 | +# Feature: Add dark mode toggle |
| 117 | + |
| 118 | +Users should be able to switch between light and dark themes. |
| 119 | +The toggle should be in the settings page. |
| 120 | + |
| 121 | +## Task List |
| 122 | + |
| 123 | +- [ ] Create dark mode toggle component in Settings page |
| 124 | +- [ ] Add dark mode state management (context/store) |
| 125 | +- [ ] Implement CSS-in-JS styles for dark theme |
| 126 | +- [ ] Update existing components to support theme switching |
| 127 | +- [ ] Run tests and verify functionality |
| 128 | + |
| 129 | +### Task Status Legend |
| 130 | +- [ ] Pending |
| 131 | +- [>] In Progress |
| 132 | +- [x] Completed |
| 133 | +``` |
| 134 | + |
| 135 | +**During execution:** |
| 136 | +```markdown |
| 137 | +## Task List |
| 138 | + |
| 139 | +- [x] Create dark mode toggle component in Settings page |
| 140 | +- [>] Add dark mode state management (context/store) |
| 141 | +- [ ] Implement CSS-in-JS styles for dark theme |
| 142 | +- [ ] Update existing components to support theme switching |
| 143 | +- [ ] Run tests and verify functionality |
| 144 | +``` |
| 145 | + |
| 146 | +### Example 2: Bug fix with investigation |
| 147 | + |
| 148 | +**Issue document:** |
| 149 | +```markdown |
| 150 | +# Bug: Login form crashes on submit |
| 151 | + |
| 152 | +When users click submit, the app crashes. |
| 153 | +Error message: "Cannot read property 'email' of undefined" |
| 154 | +``` |
| 155 | + |
| 156 | +**Task list created:** |
| 157 | +```markdown |
| 158 | +## Task List |
| 159 | + |
| 160 | +- [ ] Reproduce the bug locally |
| 161 | +- [ ] Investigate the error in login form component |
| 162 | +- [ ] Identify root cause of undefined email property |
| 163 | +- [ ] Implement fix |
| 164 | +- [ ] Add validation to prevent similar issues |
| 165 | +- [ ] Test the fix with various inputs |
| 166 | +- [ ] Update error handling |
| 167 | + |
| 168 | +### Task Status Legend |
| 169 | +- [ ] Pending |
| 170 | +- [>] In Progress |
| 171 | +- [x] Completed |
| 172 | +``` |
| 173 | + |
| 174 | +## When to Use This Skill |
| 175 | + |
| 176 | +Use this Skill when: |
| 177 | + |
| 178 | +1. **Complex multi-step tasks** - Issue requires 3+ distinct steps |
| 179 | +2. **Feature implementation** - Building new functionality from requirements |
| 180 | +3. **Bug fixing** - Need to investigate, fix, and verify |
| 181 | +4. **Refactoring** - Multiple files or components need changes |
| 182 | +5. **User provides requirements** - Issue document contains specifications |
| 183 | +6. **Need progress tracking** - Want visible progress in the document itself |
| 184 | + |
| 185 | +## When NOT to Use This Skill |
| 186 | + |
| 187 | +Skip this Skill when: |
| 188 | + |
| 189 | +1. **Single simple task** - Just one straightforward action needed |
| 190 | +2. **Trivial changes** - Quick fixes that don't need planning |
| 191 | +3. **Informational requests** - User just wants explanation, not execution |
| 192 | +4. **No document provided** - User hasn't created an issue document |
| 193 | + |
| 194 | +## Best Practices |
| 195 | + |
| 196 | +1. **Be specific with tasks**: "Add login button to navbar" not "Update UI" |
| 197 | +2. **Keep tasks atomic**: Each task should be independently completable |
| 198 | +3. **Update immediately**: Don't batch status updates, do them in real-time |
| 199 | +4. **One task at a time**: Never mark multiple tasks as `[>]` |
| 200 | +5. **Handle blockers**: If stuck, create new tasks to resolve the blocker |
| 201 | +6. **Verify completion**: Only mark `[x]` when task is fully done |
| 202 | + |
| 203 | +## Advanced Usage |
| 204 | + |
| 205 | +### Handling dependencies |
| 206 | + |
| 207 | +When tasks have dependencies, order them properly: |
| 208 | + |
| 209 | +```markdown |
| 210 | +- [ ] Create database schema |
| 211 | +- [ ] Implement API endpoints (depends on schema) |
| 212 | +- [ ] Build frontend forms (depends on API) |
| 213 | +``` |
| 214 | + |
| 215 | +### Using sub-tasks |
| 216 | + |
| 217 | +For complex tasks, break them down: |
| 218 | + |
| 219 | +```markdown |
| 220 | +- [>] Implement authentication system |
| 221 | + - [x] Set up JWT library |
| 222 | + - [>] Create login endpoint |
| 223 | + - [ ] Create logout endpoint |
| 224 | + - [ ] Add token refresh logic |
| 225 | +``` |
| 226 | + |
| 227 | +### Adding notes |
| 228 | + |
| 229 | +Add implementation notes or findings: |
| 230 | + |
| 231 | +```markdown |
| 232 | +- [x] Investigate performance issue |
| 233 | + - Note: Found N+1 query in user loader |
| 234 | + - Solution: Added dataloader batching |
| 235 | +``` |
| 236 | + |
| 237 | +## Requirements |
| 238 | + |
| 239 | +This Skill uses standard Deep Code tools: |
| 240 | + |
| 241 | +- **Read**: To read the issue document |
| 242 | +- **Edit**: To update task status in the document |
| 243 | +- **Bash**: To run tests, builds, or other commands |
| 244 | +- **Write**: To create new files if needed |
| 245 | + |
| 246 | +No additional dependencies required. |
| 247 | + |
| 248 | +## Workflow Summary |
| 249 | + |
| 250 | +1. Ask user for issue document path |
| 251 | +2. Read and analyze the document |
| 252 | +3. Append structured task list to document |
| 253 | +4. For each task: |
| 254 | + - Update to `[>]` in document |
| 255 | + - Execute the task |
| 256 | + - Update to `[x]` in document |
| 257 | +5. Add completion summary when done |
| 258 | + |
| 259 | +This approach keeps all planning and progress tracking in one place - the issue document itself - making it easy for users to see what's been done and what's remaining. |
0 commit comments