vibe-forge 0.8.2 → 0.8.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/clear-attention.md +63 -63
- package/.claude/commands/compact-context.md +52 -52
- package/.claude/commands/need-help.md +77 -77
- package/.claude/commands/update-status.md +64 -64
- package/.claude/commands/worker-loop.md +106 -106
- package/.claude/scripts/setup-worker-loop.sh +45 -45
- package/LICENSE +21 -21
- package/README.md +211 -211
- package/bin/cli.js +127 -33
- package/bin/dashboard/api/agents.js +333 -333
- package/bin/dashboard/api/dispatch.js +507 -507
- package/bin/dashboard/api/tasks.js +416 -416
- package/bin/dashboard/public/assets/index-Dm2PgE2m.js +2 -0
- package/bin/dashboard/public/index.html +13 -13
- package/bin/dashboard/server.js +574 -645
- package/config/agent-manifest.yaml +237 -237
- package/config/agents.json +207 -207
- package/config/task-types.yaml +111 -111
- package/context/agent-overrides/README.md +41 -41
- package/context/architecture.md +42 -42
- package/context/modern-conventions.md +129 -129
- package/docs/agents.md +473 -473
- package/docs/architecture.md +194 -194
- package/docs/commands.md +451 -451
- package/docs/security.md +195 -195
- package/package.json +2 -3
- package/src/lib/database.sh +1 -1
- package/bin/dashboard/public/assets/index-BpHfsx1r.js +0 -2
|
@@ -1,63 +1,63 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Clear an attention signal after helping a worker
|
|
3
|
-
argument-hint: [agent-name | all]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Clear Attention Command
|
|
7
|
-
|
|
8
|
-
Use this command to clear attention signals after you've helped a blocked worker.
|
|
9
|
-
|
|
10
|
-
## Usage
|
|
11
|
-
|
|
12
|
-
```
|
|
13
|
-
/clear-attention anvil # Clear Anvil's attention signal
|
|
14
|
-
/clear-attention all # Clear all attention signals
|
|
15
|
-
/clear-attention # List current attention signals
|
|
16
|
-
```
|
|
17
|
-
|
|
18
|
-
## Implementation
|
|
19
|
-
|
|
20
|
-
Based on `$ARGUMENTS`:
|
|
21
|
-
|
|
22
|
-
### If no argument or empty
|
|
23
|
-
|
|
24
|
-
List all current attention signals from `tasks/attention/`:
|
|
25
|
-
|
|
26
|
-
```
|
|
27
|
-
🔔 Current Attention Signals:
|
|
28
|
-
|
|
29
|
-
1. Anvil (5 min ago): Need clarification on auth implementation
|
|
30
|
-
2. Crucible (2 min ago): Tests failing, unsure of expected behavior
|
|
31
|
-
|
|
32
|
-
Use /clear-attention <agent> to resolve.
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
### If argument is "all"
|
|
36
|
-
|
|
37
|
-
Remove all files from `tasks/attention/` and confirm:
|
|
38
|
-
|
|
39
|
-
```
|
|
40
|
-
✅ Cleared all attention signals (2 resolved)
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
### If argument is an agent name
|
|
44
|
-
|
|
45
|
-
1. Find and remove files matching that agent in `tasks/attention/`
|
|
46
|
-
2. Confirm removal:
|
|
47
|
-
|
|
48
|
-
```
|
|
49
|
-
✅ Cleared attention signal for Anvil
|
|
50
|
-
```
|
|
51
|
-
|
|
52
|
-
If no matching signal found:
|
|
53
|
-
|
|
54
|
-
```
|
|
55
|
-
No attention signal found for Anvil
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
## Notes
|
|
59
|
-
|
|
60
|
-
- Attention files are created by workers using `/need-help`
|
|
61
|
-
- The daemon watches this folder and sends notifications
|
|
62
|
-
- Clearing signals is a way to acknowledge you've responded
|
|
63
|
-
- Workers can also clear their own signals when unblocked
|
|
1
|
+
---
|
|
2
|
+
description: Clear an attention signal after helping a worker
|
|
3
|
+
argument-hint: [agent-name | all]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Clear Attention Command
|
|
7
|
+
|
|
8
|
+
Use this command to clear attention signals after you've helped a blocked worker.
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
/clear-attention anvil # Clear Anvil's attention signal
|
|
14
|
+
/clear-attention all # Clear all attention signals
|
|
15
|
+
/clear-attention # List current attention signals
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
## Implementation
|
|
19
|
+
|
|
20
|
+
Based on `$ARGUMENTS`:
|
|
21
|
+
|
|
22
|
+
### If no argument or empty
|
|
23
|
+
|
|
24
|
+
List all current attention signals from `tasks/attention/`:
|
|
25
|
+
|
|
26
|
+
```
|
|
27
|
+
🔔 Current Attention Signals:
|
|
28
|
+
|
|
29
|
+
1. Anvil (5 min ago): Need clarification on auth implementation
|
|
30
|
+
2. Crucible (2 min ago): Tests failing, unsure of expected behavior
|
|
31
|
+
|
|
32
|
+
Use /clear-attention <agent> to resolve.
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
### If argument is "all"
|
|
36
|
+
|
|
37
|
+
Remove all files from `tasks/attention/` and confirm:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
✅ Cleared all attention signals (2 resolved)
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### If argument is an agent name
|
|
44
|
+
|
|
45
|
+
1. Find and remove files matching that agent in `tasks/attention/`
|
|
46
|
+
2. Confirm removal:
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
✅ Cleared attention signal for Anvil
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
If no matching signal found:
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
No attention signal found for Anvil
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
## Notes
|
|
59
|
+
|
|
60
|
+
- Attention files are created by workers using `/need-help`
|
|
61
|
+
- The daemon watches this folder and sends notifications
|
|
62
|
+
- Clearing signals is a way to acknowledge you've responded
|
|
63
|
+
- Workers can also clear their own signals when unblocked
|
|
@@ -1,52 +1,52 @@
|
|
|
1
|
-
# Compact Context
|
|
2
|
-
|
|
3
|
-
Compress the current conversation to free up context window space while preserving all essential information.
|
|
4
|
-
|
|
5
|
-
## When to Use
|
|
6
|
-
|
|
7
|
-
Use this when:
|
|
8
|
-
- You notice response quality degrading (repetitive, forgetting earlier decisions)
|
|
9
|
-
- A task is running long and you want to continue without starting fresh
|
|
10
|
-
- The conversation history is getting unwieldy
|
|
11
|
-
- Before picking up a new task in the same session
|
|
12
|
-
|
|
13
|
-
## How to Compact
|
|
14
|
-
|
|
15
|
-
Summarize the current conversation into a dense brief using this format:
|
|
16
|
-
|
|
17
|
-
```
|
|
18
|
-
## Context Compact — [timestamp]
|
|
19
|
-
|
|
20
|
-
### Work In Progress
|
|
21
|
-
- Task: [task ID and title]
|
|
22
|
-
- Status: [what's done, what's not]
|
|
23
|
-
- Files touched: [list]
|
|
24
|
-
|
|
25
|
-
### Key Decisions Made
|
|
26
|
-
- [decision 1 and the reason behind it]
|
|
27
|
-
- [decision 2 and the reason behind it]
|
|
28
|
-
|
|
29
|
-
### Architecture Constraints Discovered
|
|
30
|
-
- [any patterns, restrictions, or conventions learned from reading code]
|
|
31
|
-
|
|
32
|
-
### Tests Written
|
|
33
|
-
- [test file: X tests passing]
|
|
34
|
-
|
|
35
|
-
### Blockers / Open Questions
|
|
36
|
-
- [anything unresolved]
|
|
37
|
-
|
|
38
|
-
### Next Step
|
|
39
|
-
[Exactly what to do next when work resumes]
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
After writing the summary, respond with:
|
|
43
|
-
|
|
44
|
-
> Context compacted. Summary above replaces prior conversation history.
|
|
45
|
-
> Ready to continue with: [next step].
|
|
46
|
-
|
|
47
|
-
## Rules
|
|
48
|
-
|
|
49
|
-
- Never lose acceptance criteria state -- list any unchecked ACs explicitly
|
|
50
|
-
- Never lose test counts -- the DoD requires accurate numbers
|
|
51
|
-
- Keep the summary under 400 words -- longer defeats the purpose
|
|
52
|
-
- If mid-task: the summary IS the handoff. Make it complete enough to resume cold.
|
|
1
|
+
# Compact Context
|
|
2
|
+
|
|
3
|
+
Compress the current conversation to free up context window space while preserving all essential information.
|
|
4
|
+
|
|
5
|
+
## When to Use
|
|
6
|
+
|
|
7
|
+
Use this when:
|
|
8
|
+
- You notice response quality degrading (repetitive, forgetting earlier decisions)
|
|
9
|
+
- A task is running long and you want to continue without starting fresh
|
|
10
|
+
- The conversation history is getting unwieldy
|
|
11
|
+
- Before picking up a new task in the same session
|
|
12
|
+
|
|
13
|
+
## How to Compact
|
|
14
|
+
|
|
15
|
+
Summarize the current conversation into a dense brief using this format:
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
## Context Compact — [timestamp]
|
|
19
|
+
|
|
20
|
+
### Work In Progress
|
|
21
|
+
- Task: [task ID and title]
|
|
22
|
+
- Status: [what's done, what's not]
|
|
23
|
+
- Files touched: [list]
|
|
24
|
+
|
|
25
|
+
### Key Decisions Made
|
|
26
|
+
- [decision 1 and the reason behind it]
|
|
27
|
+
- [decision 2 and the reason behind it]
|
|
28
|
+
|
|
29
|
+
### Architecture Constraints Discovered
|
|
30
|
+
- [any patterns, restrictions, or conventions learned from reading code]
|
|
31
|
+
|
|
32
|
+
### Tests Written
|
|
33
|
+
- [test file: X tests passing]
|
|
34
|
+
|
|
35
|
+
### Blockers / Open Questions
|
|
36
|
+
- [anything unresolved]
|
|
37
|
+
|
|
38
|
+
### Next Step
|
|
39
|
+
[Exactly what to do next when work resumes]
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
After writing the summary, respond with:
|
|
43
|
+
|
|
44
|
+
> Context compacted. Summary above replaces prior conversation history.
|
|
45
|
+
> Ready to continue with: [next step].
|
|
46
|
+
|
|
47
|
+
## Rules
|
|
48
|
+
|
|
49
|
+
- Never lose acceptance criteria state -- list any unchecked ACs explicitly
|
|
50
|
+
- Never lose test counts -- the DoD requires accurate numbers
|
|
51
|
+
- Keep the summary under 400 words -- longer defeats the purpose
|
|
52
|
+
- If mid-task: the summary IS the handoff. Make it complete enough to resume cold.
|
|
@@ -1,77 +1,77 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Signal that you need human attention/input
|
|
3
|
-
argument-hint: <brief reason>
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Need Help Command
|
|
7
|
-
|
|
8
|
-
Use this command when you're blocked and need human input. This will:
|
|
9
|
-
|
|
10
|
-
1. Create an attention file in `tasks/attention/`
|
|
11
|
-
2. Ring the terminal bell for immediate notification
|
|
12
|
-
3. Trigger a system toast notification (if daemon is running)
|
|
13
|
-
4. Show in the Planning Hub's status display
|
|
14
|
-
|
|
15
|
-
## Usage
|
|
16
|
-
|
|
17
|
-
```
|
|
18
|
-
/need-help Need clarification on auth implementation approach
|
|
19
|
-
/need-help Blocked on API design decision - REST vs GraphQL?
|
|
20
|
-
/need-help Tests failing, need guidance on expected behavior
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
## Implementation
|
|
24
|
-
|
|
25
|
-
Based on `$ARGUMENTS`:
|
|
26
|
-
|
|
27
|
-
1. Determine your agent identity from your system prompt or context
|
|
28
|
-
2. Create an attention file at `tasks/attention/<agent>-<timestamp>.md`:
|
|
29
|
-
|
|
30
|
-
```markdown
|
|
31
|
-
---
|
|
32
|
-
agent: <your-agent-name>
|
|
33
|
-
created: <ISO timestamp>
|
|
34
|
-
status: pending
|
|
35
|
-
---
|
|
36
|
-
|
|
37
|
-
# Attention Needed
|
|
38
|
-
|
|
39
|
-
**Agent:** <icon> <display-name>
|
|
40
|
-
**Time:** <human-readable time>
|
|
41
|
-
|
|
42
|
-
## Issue
|
|
43
|
-
|
|
44
|
-
$ARGUMENTS
|
|
45
|
-
|
|
46
|
-
## Context
|
|
47
|
-
|
|
48
|
-
<Brief context about what you were working on>
|
|
49
|
-
```
|
|
50
|
-
|
|
51
|
-
3. Ring the terminal bell:
|
|
52
|
-
|
|
53
|
-
```bash
|
|
54
|
-
printf '\a'
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
4. Announce that you've signaled for help and will wait.
|
|
58
|
-
|
|
59
|
-
## Resolving Attention
|
|
60
|
-
|
|
61
|
-
When a human responds (via Hub or directly), they can:
|
|
62
|
-
- Delete the attention file to clear the flag
|
|
63
|
-
- Move it to a resolved folder
|
|
64
|
-
- Or just respond - the worker can delete their own attention file once unblocked
|
|
65
|
-
|
|
66
|
-
## Example Output
|
|
67
|
-
|
|
68
|
-
After running `/need-help Need decision on caching strategy`:
|
|
69
|
-
|
|
70
|
-
```
|
|
71
|
-
🔔 Attention signal sent!
|
|
72
|
-
|
|
73
|
-
I've created tasks/attention/anvil-20240115-143022.md
|
|
74
|
-
The Planning Hub and daemon have been notified.
|
|
75
|
-
|
|
76
|
-
I'll wait for guidance. You can respond here or via the Hub.
|
|
77
|
-
```
|
|
1
|
+
---
|
|
2
|
+
description: Signal that you need human attention/input
|
|
3
|
+
argument-hint: <brief reason>
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Need Help Command
|
|
7
|
+
|
|
8
|
+
Use this command when you're blocked and need human input. This will:
|
|
9
|
+
|
|
10
|
+
1. Create an attention file in `tasks/attention/`
|
|
11
|
+
2. Ring the terminal bell for immediate notification
|
|
12
|
+
3. Trigger a system toast notification (if daemon is running)
|
|
13
|
+
4. Show in the Planning Hub's status display
|
|
14
|
+
|
|
15
|
+
## Usage
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
/need-help Need clarification on auth implementation approach
|
|
19
|
+
/need-help Blocked on API design decision - REST vs GraphQL?
|
|
20
|
+
/need-help Tests failing, need guidance on expected behavior
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## Implementation
|
|
24
|
+
|
|
25
|
+
Based on `$ARGUMENTS`:
|
|
26
|
+
|
|
27
|
+
1. Determine your agent identity from your system prompt or context
|
|
28
|
+
2. Create an attention file at `tasks/attention/<agent>-<timestamp>.md`:
|
|
29
|
+
|
|
30
|
+
```markdown
|
|
31
|
+
---
|
|
32
|
+
agent: <your-agent-name>
|
|
33
|
+
created: <ISO timestamp>
|
|
34
|
+
status: pending
|
|
35
|
+
---
|
|
36
|
+
|
|
37
|
+
# Attention Needed
|
|
38
|
+
|
|
39
|
+
**Agent:** <icon> <display-name>
|
|
40
|
+
**Time:** <human-readable time>
|
|
41
|
+
|
|
42
|
+
## Issue
|
|
43
|
+
|
|
44
|
+
$ARGUMENTS
|
|
45
|
+
|
|
46
|
+
## Context
|
|
47
|
+
|
|
48
|
+
<Brief context about what you were working on>
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
3. Ring the terminal bell:
|
|
52
|
+
|
|
53
|
+
```bash
|
|
54
|
+
printf '\a'
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
4. Announce that you've signaled for help and will wait.
|
|
58
|
+
|
|
59
|
+
## Resolving Attention
|
|
60
|
+
|
|
61
|
+
When a human responds (via Hub or directly), they can:
|
|
62
|
+
- Delete the attention file to clear the flag
|
|
63
|
+
- Move it to a resolved folder
|
|
64
|
+
- Or just respond - the worker can delete their own attention file once unblocked
|
|
65
|
+
|
|
66
|
+
## Example Output
|
|
67
|
+
|
|
68
|
+
After running `/need-help Need decision on caching strategy`:
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
🔔 Attention signal sent!
|
|
72
|
+
|
|
73
|
+
I've created tasks/attention/anvil-20240115-143022.md
|
|
74
|
+
The Planning Hub and daemon have been notified.
|
|
75
|
+
|
|
76
|
+
I'll wait for guidance. You can respond here or via the Hub.
|
|
77
|
+
```
|
|
@@ -1,64 +1,64 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Update your agent status for the forge dashboard
|
|
3
|
-
argument-hint: <status> [task-id]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Update Status Command
|
|
7
|
-
|
|
8
|
-
Report your current status to the forge daemon and Planning Hub. This enables real-time visibility into what each worker is doing.
|
|
9
|
-
|
|
10
|
-
## Usage
|
|
11
|
-
|
|
12
|
-
```
|
|
13
|
-
/update-status working TASK-001 # Working on a specific task
|
|
14
|
-
/update-status idle # Waiting for tasks
|
|
15
|
-
/update-status blocked # Stuck, may need help
|
|
16
|
-
/update-status reviewing PR-123 # Reviewing something
|
|
17
|
-
/update-status testing TASK-001 # Running tests
|
|
18
|
-
```
|
|
19
|
-
|
|
20
|
-
## Status Values
|
|
21
|
-
|
|
22
|
-
| Status | Meaning |
|
|
23
|
-
|--------|---------|
|
|
24
|
-
| `idle` | No current task, ready for work |
|
|
25
|
-
| `working` | Actively working on a task |
|
|
26
|
-
| `blocked` | Stuck, needs input (consider `/need-help`) |
|
|
27
|
-
| `reviewing` | Reviewing code or PR |
|
|
28
|
-
| `testing` | Running tests |
|
|
29
|
-
| `waiting` | Waiting for external dependency |
|
|
30
|
-
|
|
31
|
-
## Implementation
|
|
32
|
-
|
|
33
|
-
Based on `$ARGUMENTS`:
|
|
34
|
-
|
|
35
|
-
1. Parse the status and optional task ID from arguments
|
|
36
|
-
2. Determine your agent identity from your system prompt
|
|
37
|
-
3. Write status file to `context/agent-status/<agent>.json`:
|
|
38
|
-
|
|
39
|
-
```json
|
|
40
|
-
{
|
|
41
|
-
"agent": "anvil",
|
|
42
|
-
"status": "working",
|
|
43
|
-
"task": "TASK-001",
|
|
44
|
-
"message": "Implementing user authentication",
|
|
45
|
-
"updated": "2026-01-15T14:30:22Z" // ISO 8601 timestamp (auto-generated)
|
|
46
|
-
}
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
4. The daemon reads these files and includes them in `forge-state.yaml`
|
|
50
|
-
5. The Planning Hub sees your status in the dashboard
|
|
51
|
-
|
|
52
|
-
## Auto-Status Updates
|
|
53
|
-
|
|
54
|
-
Workers should update their status at these key moments:
|
|
55
|
-
|
|
56
|
-
1. **On startup**: `/update-status idle` (or working if picking up a task)
|
|
57
|
-
2. **When picking up a task**: `/update-status working TASK-XXX`
|
|
58
|
-
3. **When completing a task**: `/update-status idle`
|
|
59
|
-
4. **When blocked**: `/update-status blocked` (then `/need-help` if needed)
|
|
60
|
-
5. **Before exiting**: Status file can remain (daemon marks stale after timeout)
|
|
61
|
-
|
|
62
|
-
## Stale Status
|
|
63
|
-
|
|
64
|
-
The daemon considers a status stale if not updated for 5+ minutes. Stale statuses are shown with a warning indicator in the dashboard.
|
|
1
|
+
---
|
|
2
|
+
description: Update your agent status for the forge dashboard
|
|
3
|
+
argument-hint: <status> [task-id]
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Update Status Command
|
|
7
|
+
|
|
8
|
+
Report your current status to the forge daemon and Planning Hub. This enables real-time visibility into what each worker is doing.
|
|
9
|
+
|
|
10
|
+
## Usage
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
/update-status working TASK-001 # Working on a specific task
|
|
14
|
+
/update-status idle # Waiting for tasks
|
|
15
|
+
/update-status blocked # Stuck, may need help
|
|
16
|
+
/update-status reviewing PR-123 # Reviewing something
|
|
17
|
+
/update-status testing TASK-001 # Running tests
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
## Status Values
|
|
21
|
+
|
|
22
|
+
| Status | Meaning |
|
|
23
|
+
|--------|---------|
|
|
24
|
+
| `idle` | No current task, ready for work |
|
|
25
|
+
| `working` | Actively working on a task |
|
|
26
|
+
| `blocked` | Stuck, needs input (consider `/need-help`) |
|
|
27
|
+
| `reviewing` | Reviewing code or PR |
|
|
28
|
+
| `testing` | Running tests |
|
|
29
|
+
| `waiting` | Waiting for external dependency |
|
|
30
|
+
|
|
31
|
+
## Implementation
|
|
32
|
+
|
|
33
|
+
Based on `$ARGUMENTS`:
|
|
34
|
+
|
|
35
|
+
1. Parse the status and optional task ID from arguments
|
|
36
|
+
2. Determine your agent identity from your system prompt
|
|
37
|
+
3. Write status file to `context/agent-status/<agent>.json`:
|
|
38
|
+
|
|
39
|
+
```json
|
|
40
|
+
{
|
|
41
|
+
"agent": "anvil",
|
|
42
|
+
"status": "working",
|
|
43
|
+
"task": "TASK-001",
|
|
44
|
+
"message": "Implementing user authentication",
|
|
45
|
+
"updated": "2026-01-15T14:30:22Z" // ISO 8601 timestamp (auto-generated)
|
|
46
|
+
}
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
4. The daemon reads these files and includes them in `forge-state.yaml`
|
|
50
|
+
5. The Planning Hub sees your status in the dashboard
|
|
51
|
+
|
|
52
|
+
## Auto-Status Updates
|
|
53
|
+
|
|
54
|
+
Workers should update their status at these key moments:
|
|
55
|
+
|
|
56
|
+
1. **On startup**: `/update-status idle` (or working if picking up a task)
|
|
57
|
+
2. **When picking up a task**: `/update-status working TASK-XXX`
|
|
58
|
+
3. **When completing a task**: `/update-status idle`
|
|
59
|
+
4. **When blocked**: `/update-status blocked` (then `/need-help` if needed)
|
|
60
|
+
5. **Before exiting**: Status file can remain (daemon marks stale after timeout)
|
|
61
|
+
|
|
62
|
+
## Stale Status
|
|
63
|
+
|
|
64
|
+
The daemon considers a status stale if not updated for 5+ minutes. Stale statuses are shown with a warning indicator in the dashboard.
|