vibe-forge 0.8.3 → 0.8.6

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.
@@ -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.