|
1
|
--- |
|
2
|
name: follow-up-tasks |
|
3
|
description: Propose follow-up tasks before marking your current task as complete. |
|
4
|
--- |
|
5
|
|
|
6
|
# Follow-Up Tasks |
|
7
|
|
|
8
|
As you work on your current task, watch for additional work that should be done as follow-up tasks — separate units of work related to your current task but outside its scope. |
|
9
|
|
|
10
|
Categorize each follow-up task using one of these categories: |
|
11
|
|
|
12
|
- **`incomplete_scope`**: Parts of the original request that you intentionally deferred to keep the current task focused |
|
13
|
- **`next_steps`**: Functionality or features users would want next, whether directly extending what you just built or addressing unmet needs in the project |
|
14
|
- **`tech_debt`**: Code quality issues, hardcoded values, shortcuts, or refactoring opportunities you noticed while working |
|
15
|
- **`test_gaps`**: Tests that should be written but aren't part of the current task's deliverable |
|
16
|
|
|
17
|
Write titles for non-technical users — lead with impact, not implementation - especially for tech debt and test gaps. |
|
18
|
|
|
19
|
Users decide from the title, so make each title name the concrete value or risk. Avoid generic implementation phrasing. |
|
20
|
|
|
21
|
Prefer titles like: |
|
22
|
|
|
23
|
- "Catch [specific regression] before it ships" |
|
24
|
- "Confirm [critical behavior] still works after [change]" |
|
25
|
- "Make sure [user-visible flow] cannot silently fail" |
|
26
|
- "Fix [broken type/build/check] blocking [reliability outcome]" |
|
27
|
- "Prevent [bad user outcome] when [edge case happens]" |
|
28
|
|
|
29
|
Avoid titles like: |
|
30
|
|
|
31
|
- "Add automated tests for [feature]" |
|
32
|
- "Improve coverage for [area]" |
|
33
|
- "Refactor [component] better" |
|
34
|
- "Add a dashboard/report/export" |
|
35
|
|
|
36
|
Before submitting, review each title by asking: "Would a non-technical user understand what this means and why they'd want it?" If not, rewrite it. Examples: |
|
37
|
|
|
38
|
- "Store recipes in a database with full CRUD support" -> "Let users add, edit, and delete their own recipes" |
|
39
|
- "Add server-side validation for recipe API endpoints" -> "Prevent broken recipes from being saved" |
|
40
|
|
|
41
|
Before marking your task as complete, propose up to 4 follow-up tasks by calling `proposeFollowUpTasks` — NOT `bulkCreateProjectTasks` or `createProjectTask`. The `proposeFollowUpTasks` callback automatically links follow-ups to your current task as the parent — required for correct task hierarchy. Submit them all in a single call with clear titles, descriptions, and a `category` (required). Keep only the highest-impact follow-ups. Each description should include relevant file paths and enough context for another agent to pick up the work independently. |
|
42
|
|
|
43
|
Only propose follow-ups that represent genuine, actionable work. |
|
44
|
|
|
45
|
- Do not propose follow-ups that overlap with tasks already visible in the project task list |
|
46
|
- Do not propose follow-ups for trivial items or things already in your current task's scope |
|
47
|
- Do not propose follow-ups for agent housekeeping (e.g. updating replit.md, adding comments, improving documentation — handle those inline) |
|
48
|
|
|
49
|
If your current task already has downstream tasks depending on it (listed in your task assignment), skip calling `proposeFollowUpTasks` entirely — those tasks already cover the planned next steps. |
|
50
|
|
|
51
|
`proposeFollowUpTasks` is **one-shot per assigned project task** — not per turn, not per subfeature, not per `mark_task_complete` cycle. The system rejects duplicate calls. If you're marking complete again after more work on the same assigned task, review your previously proposed follow-ups; if any are now stale, call `markFollowUpTaskObsolete` to retract them. |
|
52
|
|
|
53
|
## Examples |
|
54
|
|
|
55
|
```javascript |
|
56
|
// Log the result so you have taskRefs for later use with markFollowUpTaskObsolete |
|
57
|
const followUps = await proposeFollowUpTasks({ |
|
58
|
tasks: [ |
|
59
|
{ |
|
60
|
title: "Let users save favorite recipes to a personal collection", |
|
61
|
category: "next_steps", |
|
62
|
description: `# Let users save favorite recipes to a personal collection |
|
63
|
|
|
64
|
## What & Why |
|
65
|
Users currently can't keep track of recipes they like. A favorites collection is the natural next feature on top of the existing browsing flow — it gives the app stickiness and a reason to return. |
|
66
|
|
|
67
|
## Done looks like |
|
68
|
- Authenticated users can favorite / unfavorite a recipe from the list and detail pages |
|
69
|
- A "My favorites" page shows the user's collection |
|
70
|
- Favorites persist across sessions |
|
71
|
|
|
72
|
## Relevant files |
|
73
|
- \`src/pages/recipes/[id].tsx\` |
|
74
|
- \`src/components/RecipeCard.tsx\`` |
|
75
|
}, |
|
76
|
{ |
|
77
|
title: "Save recipes permanently so they aren't lost on refresh", |
|
78
|
category: "tech_debt", |
|
79
|
description: `# Save recipes permanently so they aren't lost on refresh |
|
80
|
|
|
81
|
## What & Why |
|
82
|
Recipe data is hardcoded in a static file. Users who add or edit recipes will lose their changes on page refresh. Moving data to the database ensures persistence. |
|
83
|
|
|
84
|
## Done looks like |
|
85
|
- Recipes are stored in the database and served via API |
|
86
|
- Users can add, edit, and delete recipes without losing data |
|
87
|
|
|
88
|
## Relevant files |
|
89
|
- \`src/data/recipes.ts\`` |
|
90
|
} |
|
91
|
] |
|
92
|
}); |
|
93
|
console.log(followUps.map(t => ({ taskRef: t.taskRef, title: t.title }))); |
|
94
|
|
|
95
|
// Remove an obsolete follow-up |
|
96
|
await markFollowUpTaskObsolete({ taskRef: "#12" }); |
|
97
|
``` |