lkn
/
anvillm
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

session: reset initialPromptSent when context is set 

If context is written after the first mail nudge has already fired,
initialPromptSent was already true and the context would never be
injected. Resetting it on SetContext ensures the context is always
prepended to the next prompt regardless of timing.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Levi Neely 2026-03-07 12:30:21 +01:00
parent e4ea258c6a
commit 10d25a371a
16 changed files with 624 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
internal/backend/tmux/session.go
View File

@ -227,6 +227,7 @@ func (s *Session) SetContext(ctx string) {
s.mu.Lock()
defer s.mu.Unlock()
s.context = ctx
s.initialPromptSent = false
}
// GetContext gets the startup context (empty after first Send)

11
roles/conductor.md
View File

@ -28,16 +28,19 @@ You are NOT allowed to:
2. Read the bead and its existing children (if any)
3. Evaluate completeness: do the children fully cover the goal and acceptance criteria?
- If incomplete: add missing child beads, or send QUERY_REQUEST to user for clarification
4. For each ready child bead (dependencies met):
4. Before dispatching parallel implementation beads, verify orthogonality:
- Check that no two concurrently-dispatched beads modify the same files
- If beads overlap, sequence them (add dependency) rather than parallelizing
5. For each ready child bead (dependencies met):
- Find the appropriate bot via `list_sessions` by role
- Send the bead assignment directly (PROMPT_REQUEST, REVIEW_REQUEST, APPROVAL_REQUEST, etc.)
- Mark the child bead `in_progress`
5. As responses arrive:
6. As responses arrive:
- On success: mark child bead `closed`, unblock and dispatch dependent children
- On rejection: re-assign to the original bot for rework
- On blocker: send QUERY_REQUEST to user
6. When all children are `closed`, close the parent bead
7. Send PROMPT_RESPONSE to the user
7. When all children are `closed`, close the parent bead
8. Send PROMPT_RESPONSE to the user
## Response Format

26
workflows/audit.md Normal file
View File

@ -0,0 +1,26 @@
---
name: Audit
description: Code quality assessment of existing code with no changes made
roles: reviewer
---
Use this workflow to assess the quality, correctness, or security posture of
existing code without making any changes. Output is a findings report.
## Decomposition
| # | Title | Role | Depends On |
|---|------------------------|----------|------------|
| 1 | Audit: <description> | reviewer | — |
## Handoffs
None. Findings go directly to the conductor and user.
## Notes
- The reviewer must not make any changes to the codebase.
- The output should be a structured findings report, not a pass/fail verdict.
- If findings warrant fixes, track them as separate beads using an appropriate
workflow rather than folding them into this one.
- If any required role is not present in the session, block and report to the user.

49
workflows/bugfix.md Normal file
View File

@ -0,0 +1,49 @@
---
name: Bug Fix
description: Minimal workflow for a well-understood, self-contained bug fix
roles: developer, reviewer, tester
---
Use this workflow for bugs where the cause is already known and the fix is
straightforward. No research, no deployment step.
## Decomposition
| # | Title | Role | Depends On |
|---|---------------------------|-----------|------------|
| 1 | Fix: <description> | developer | — |
| 2 | Review: <description> | reviewer | 1 |
| 3 | Verify fix: <description> | tester | 2 |
## Handoffs
**1 → 2 (developer → reviewer)**
Conductor includes in REVIEW_REQUEST:
- Files modified
- Description of the fix and root cause
- Any edge cases or areas of concern
**2 rejected → 1 (reviewer → developer)**
Conductor includes in PROMPT_REQUEST:
- Reviewer findings
- Files and locations requiring changes
**2 → 3 (reviewer approved → tester)**
Conductor includes in APPROVAL_REQUEST:
- Files modified
- Description of the bug and expected correct behavior
- Reviewer findings and resolution summary
**3 failed → 1 (tester → developer)**
Conductor includes in PROMPT_REQUEST:
- Test failures and reproduction steps
- Files under test
## Notes
- The tester's job here is specifically to verify the bug is fixed, not
exhaustive regression testing.
- After rework, the full review and test cycle repeats from step 2.
- If the fix turns out to be non-trivial during implementation, escalate to
the `feature` workflow.
- If any required role is not present in the session, block and report to the user.

41
workflows/doc-research.md Normal file
View File

@ -0,0 +1,41 @@
---
name: Documentation (Research Required)
description: Documentation that requires technical investigation before writing
roles: researcher, author, technical-editor
---
Use this workflow when documentation cannot be written without first
researching the subject — e.g. a new architecture guide, an unfamiliar
API's reference docs, or documenting a system that is not yet well understood.
## Decomposition
| # | Title | Role | Depends On |
|---|------------------------|------------------|------------|
| 1 | Research: <description> | researcher | — |
| 2 | Write: <description> | author | 1 |
| 3 | Edit: <description> | technical-editor | 2 |
## Handoffs
**1 → 2 (researcher → author)**
Conductor includes in PROMPT_REQUEST:
- Research findings
- Relevant file paths, APIs, or external references
- Intended audience and purpose of the documentation
**2 → 3 (author → technical-editor)**
Conductor includes in REVIEW_REQUEST:
- Files written or modified
- Intended audience and purpose of the documentation
- Any sections the author flagged as uncertain
**3 rejected → 2 (technical-editor → author)**
Conductor includes in PROMPT_REQUEST:
- Editorial findings
- Locations and nature of each issue
## Notes
- After rework, the editorial review repeats from step 3.
- If any required role is not present in the session, block and report to the user.

35
workflows/doc.md Normal file
View File

@ -0,0 +1,35 @@
---
name: Documentation
description: Write and editorially review documentation
roles: author, technical-editor
---
Use this workflow for any documentation task: new guides, reference material,
API docs, README updates, or revisions to existing content.
## Decomposition
| # | Title | Role | Depends On |
|---|----------------------|------------------|------------|
| 1 | Write: <description> | author | — |
| 2 | Edit: <description> | technical-editor | 1 |
## Handoffs
**1 → 2 (author → technical-editor)**
Conductor includes in REVIEW_REQUEST:
- Files written or modified
- Intended audience and purpose of the documentation
- Any sections the author flagged as uncertain
**2 rejected → 1 (technical-editor → author)**
Conductor includes in PROMPT_REQUEST:
- Editorial findings
- Locations and nature of each issue
## Notes
- After rework, the editorial review repeats from step 2.
- If the author needs technical details from the codebase, that is within scope
of the author role and does not require a separate research bead.
- If any required role is not present in the session, block and report to the user.

65
workflows/feature-research.md Normal file
View File

@ -0,0 +1,65 @@
---
name: Feature (Research Required)
description: Complex feature where design or technical approach must be established before implementation
roles: researcher, developer, reviewer, tester, devops
---
Use this workflow when the implementation approach is unclear, the feature
touches unfamiliar territory, or the bead description lacks sufficient detail
to begin coding directly.
## Decomposition
| # | Title | Role | Depends On |
|---|--------------------------|------------|------------|
| 1 | Research: <description> | researcher | — |
| 2 | Implement: <description> | developer | 1 |
| 3 | Review: <description> | reviewer | 2 |
| 4 | Test: <description> | tester | 3 |
| 5 | Deploy: <description> | devops | 4 |
## Handoffs
**1 → 2 (researcher → developer)**
Conductor includes in PROMPT_REQUEST:
- Research findings and recommendation
- Chosen approach and rationale
- Relevant file paths, APIs, or external references
**2 → 3 (developer → reviewer)**
Conductor includes in REVIEW_REQUEST:
- Files modified
- Summary of implementation approach
- Any deviations from the research recommendation
**3 rejected → 2 (reviewer → developer)**
Conductor includes in PROMPT_REQUEST:
- Reviewer findings
- Files and locations requiring changes
**3 → 4 (reviewer approved → tester)**
Conductor includes in APPROVAL_REQUEST:
- Files modified
- Reviewer findings and resolution summary
- Acceptance criteria from the original bead
**4 failed → 2 (tester → developer)**
Conductor includes in PROMPT_REQUEST:
- Test failures and output
- Files under test
**4 → 5 (tester approved → devops)**
Conductor includes in PROMPT_REQUEST:
- Test results summary
- Files modified
- Any environment or configuration dependencies noted during testing
## Notes
- Multiple implementation beads may be dispatched in parallel if they are orthogonal (no shared files). If two beads touch the same files, sequence them with a dependency instead.
- After rework, the full review and test cycle repeats from step 3.
- The research bead should produce a concrete recommendation or design
decision, not an open-ended exploration. Scope it accordingly.
- If research reveals the feature is larger than expected, escalate to
the user before proceeding to implementation.
- If any required role is not present in the session, block and report to the user.

73
workflows/feature-with-docs.md Normal file
View File

@ -0,0 +1,73 @@
---
name: Feature with Documentation
description: Feature development followed by documentation of the new functionality
roles: developer, reviewer, tester, devops, author, technical-editor
---
Use this workflow for user-facing features where documentation must ship
alongside the code.
## Decomposition
| # | Title | Role | Depends On |
|---|--------------------------|------------------|------------|
| 1 | Implement: <description> | developer | — |
| 2 | Review: <description> | reviewer | 1 |
| 3 | Test: <description> | tester | 2 |
| 4 | Deploy: <description> | devops | 3 |
| 5 | Write: <description> | author | 4 |
| 6 | Edit: <description> | technical-editor | 5 |
## Handoffs
**1 → 2 (developer → reviewer)**
Conductor includes in REVIEW_REQUEST:
- Files modified
- Summary of implementation approach
- Any deviations from the original bead description
**2 rejected → 1 (reviewer → developer)**
Conductor includes in PROMPT_REQUEST:
- Reviewer findings
- Files and locations requiring changes
**2 → 3 (reviewer approved → tester)**
Conductor includes in APPROVAL_REQUEST:
- Files modified
- Reviewer findings and resolution summary
- Acceptance criteria from the original bead
**3 failed → 1 (tester → developer)**
Conductor includes in PROMPT_REQUEST:
- Test failures and output
- Files under test
**3 → 4 (tester approved → devops)**
Conductor includes in PROMPT_REQUEST:
- Test results summary
- Files modified
- Any environment or configuration dependencies noted during testing
**4 → 5 (devops → author)**
Conductor includes in PROMPT_REQUEST:
- Files modified
- Summary of the feature and its user-facing behavior
- Any deployment notes relevant to documentation
**5 → 6 (author → technical-editor)**
Conductor includes in REVIEW_REQUEST:
- Files written or modified
- Intended audience and purpose of the documentation
- Any sections the author flagged as uncertain
**6 rejected → 5 (technical-editor → author)**
Conductor includes in PROMPT_REQUEST:
- Editorial findings
- Locations and nature of each issue
## Notes
- After code rework, the full review and test cycle repeats from step 2.
- After doc rework, the editorial review repeats from step 6.
- Multiple implementation beads may be dispatched in parallel if they are orthogonal (no shared files). If two beads touch the same files, sequence them with a dependency instead.
- If any required role is not present in the session, block and report to the user.

54
workflows/feature.md Normal file
View File

@ -0,0 +1,54 @@
---
name: Feature
description: Standard feature development with review, testing, and deployment
roles: developer, reviewer, tester, devops
---
Use this workflow for well-understood features where requirements are clear
and no upfront research is needed.
## Decomposition
| # | Title | Role | Depends On |
|---|--------------------------|-----------|------------|
| 1 | Implement: <description> | developer | — |
| 2 | Review: <description> | reviewer | 1 |
| 3 | Test: <description> | tester | 2 |
| 4 | Deploy: <description> | devops | 3 |
## Handoffs
**1 → 2 (developer → reviewer)**
Conductor includes in REVIEW_REQUEST:
- Files modified
- Summary of implementation approach
- Any deviations from the original bead description
**2 rejected → 1 (reviewer → developer)**
Conductor includes in PROMPT_REQUEST:
- Reviewer findings
- Files and locations requiring changes
**2 → 3 (reviewer approved → tester)**
Conductor includes in APPROVAL_REQUEST:
- Files modified
- Reviewer findings and resolution summary
- Acceptance criteria from the original bead
**3 failed → 1 (tester → developer)**
Conductor includes in PROMPT_REQUEST:
- Test failures and output
- Files under test
**3 → 4 (tester approved → devops)**
Conductor includes in PROMPT_REQUEST:
- Test results summary
- Files modified
- Any environment or configuration dependencies noted during testing
## Notes
- Multiple implementation beads may be dispatched in parallel if they are orthogonal (no shared files). If two beads touch the same files, sequence them with a dependency instead.
- After rework, the full review and test cycle repeats from step 2.
- Deployment typically means opening a PR and verifying CI passes.
- If any required role is not present in the session, block and report to the user.

54
workflows/hotfix.md Normal file
View File

@ -0,0 +1,54 @@
---
name: Hotfix
description: Urgent bug fix that must be reviewed, tested, and deployed immediately
roles: developer, reviewer, tester, devops
---
Use this workflow for production bugs that require an immediate fix and
deployment. The full quality gate still applies — speed does not justify
skipping review or testing.
## Decomposition
| # | Title | Role | Depends On |
|---|---------------------------|-----------|------------|
| 1 | Fix: <description> | developer | — |
| 2 | Review: <description> | reviewer | 1 |
| 3 | Verify fix: <description> | tester | 2 |
| 4 | Deploy: <description> | devops | 3 |
## Handoffs
**1 → 2 (developer → reviewer)**
Conductor includes in REVIEW_REQUEST:
- Files modified
- Description of the fix and root cause
- Any edge cases or areas of concern
**2 rejected → 1 (reviewer → developer)**
Conductor includes in PROMPT_REQUEST:
- Reviewer findings
- Files and locations requiring changes
**2 → 3 (reviewer approved → tester)**
Conductor includes in APPROVAL_REQUEST:
- Files modified
- Description of the bug and expected correct behavior
- Reviewer findings and resolution summary
**3 failed → 1 (tester → developer)**
Conductor includes in PROMPT_REQUEST:
- Test failures and reproduction steps
- Files under test
**3 → 4 (tester approved → devops)**
Conductor includes in PROMPT_REQUEST:
- Test results summary
- Files modified
- Target environment and urgency context
## Notes
- After rework, the full review and test cycle repeats from step 2.
- Deployment should be expedited but must not bypass CI.
- If any required role is not present in the session, block and report to the user.

73
workflows/incident.md Normal file
View File

@ -0,0 +1,73 @@
---
name: Incident
description: Production hotfix followed by post-mortem documentation
roles: developer, reviewer, tester, devops, author, technical-editor
---
Use this workflow for production incidents: fix and ship the hotfix, then
document what happened, why, and how it was resolved.
## Decomposition
| # | Title | Role | Depends On |
|---|---------------------------|------------------|------------|
| 1 | Fix: <description> | developer | — |
| 2 | Review: <description> | reviewer | 1 |
| 3 | Verify fix: <description> | tester | 2 |
| 4 | Deploy: <description> | devops | 3 |
| 5 | Post-mortem: <description> | author | 4 |
| 6 | Edit: <description> | technical-editor | 5 |
## Handoffs
**1 → 2 (developer → reviewer)**
Conductor includes in REVIEW_REQUEST:
- Files modified
- Description of the fix and root cause
- Any edge cases or areas of concern
**2 rejected → 1 (reviewer → developer)**
Conductor includes in PROMPT_REQUEST:
- Reviewer findings
- Files and locations requiring changes
**2 → 3 (reviewer approved → tester)**
Conductor includes in APPROVAL_REQUEST:
- Files modified
- Description of the bug and expected correct behavior
- Reviewer findings and resolution summary
**3 failed → 1 (tester → developer)**
Conductor includes in PROMPT_REQUEST:
- Test failures and reproduction steps
- Files under test
**3 → 4 (tester approved → devops)**
Conductor includes in PROMPT_REQUEST:
- Test results summary
- Files modified
- Target environment and urgency context
**4 → 5 (devops → author)**
Conductor includes in PROMPT_REQUEST:
- Timeline of the incident and fix
- Root cause as identified by the developer
- Files modified and deployment details
**5 → 6 (author → technical-editor)**
Conductor includes in REVIEW_REQUEST:
- Files written or modified
- Post-mortem audience (internal team, stakeholders, etc.)
- Any sections the author flagged as uncertain
**6 rejected → 5 (technical-editor → author)**
Conductor includes in PROMPT_REQUEST:
- Editorial findings
- Locations and nature of each issue
## Notes
- After code rework, the full review and test cycle repeats from step 2.
- After post-mortem rework, the editorial review repeats from step 6.
- Deployment should be expedited but must not bypass CI.
- If any required role is not present in the session, block and report to the user.

37
workflows/refactor.md Normal file
View File

@ -0,0 +1,37 @@
---
name: Refactor
description: Structural code improvement with no behavior change
roles: developer, reviewer
---
Use this workflow for refactoring work: restructuring, renaming, extracting
abstractions, improving readability. No new behavior is introduced, so no
formal testing pass or deployment step is required.
## Decomposition
| # | Title | Role | Depends On |
|---|----------------------------|-----------|------------|
| 1 | Refactor: <description> | developer | — |
| 2 | Review: <description> | reviewer | 1 |
## Handoffs
**1 → 2 (developer → reviewer)**
Conductor includes in REVIEW_REQUEST:
- Files modified
- Description of structural changes made
- Confirmation that no behavior was changed and existing tests still pass
**2 rejected → 1 (reviewer → developer)**
Conductor includes in PROMPT_REQUEST:
- Reviewer findings
- Files and locations requiring changes
## Notes
- After rework, review repeats from step 2.
- Multiple implementation beads may be dispatched in parallel if they are orthogonal (no shared files). If two beads touch the same files, sequence them with a dependency instead.
- If the refactor reveals bugs or missing tests, those should be tracked as
separate beads rather than folded into this workflow.
- If any required role is not present in the session, block and report to the user.

25
workflows/release.md Normal file
View File

@ -0,0 +1,25 @@
---
name: Release
description: Package and ship already-completed, tested work
roles: devops
---
Use this workflow when development, review, and testing are complete and the
only remaining work is packaging, tagging, and deploying to production.
## Decomposition
| # | Title | Role | Depends On |
|---|-------------------------|--------|------------|
| 1 | Release: <description> | devops | — |
## Handoffs
None. Output goes directly to the conductor and user.
## Notes
- This workflow assumes all quality gates have already been passed. If there
is any doubt, use `hotfix` or `feature` instead.
- The devops bot should verify CI is green before releasing.
- If any required role is not present in the session, block and report to the user.

22
workflows/research.md Normal file
View File

@ -0,0 +1,22 @@
---
name: Research
description: Standalone research or investigation task with no implementation
roles: researcher
---
Use this workflow when the goal is purely to answer a question, evaluate an
approach, or produce a findings report — with no coding deliverable.
## Decomposition
| # | Title | Role | Depends On |
|---|-------------------------|------------|------------|
| 1 | Research: <description> | researcher | — |
## Notes
- The output of the research bead should be a written summary delivered to
the conductor, which passes it to the user.
- If the findings suggest follow-on implementation work, the conductor should
report that to the user rather than spawning additional beads unilaterally.
- If any required role is not present in the session, block and report to the user.

33
workflows/review-only.md Normal file
View File

@ -0,0 +1,33 @@
---
name: Review Only
description: Review and verify existing code with no implementation step
roles: reviewer, tester
---
Use this workflow when code already exists and only needs to be reviewed and
verified — e.g. an external PR, a branch written outside the system, or
work submitted for a second opinion.
## Decomposition
| # | Title | Role | Depends On |
|---|--------------------------|----------|------------|
| 1 | Review: <description> | reviewer | — |
| 2 | Test: <description> | tester | 1 |
## Handoffs
**1 → 2 (reviewer approved → tester)**
Conductor includes in APPROVAL_REQUEST:
- Files under review
- Reviewer findings and resolution summary
- Acceptance criteria or context from the original bead
**1 rejected → conductor**
Conductor reports findings to the user. No testing is performed on rejected code.
## Notes
- If review rejects, the workflow ends. It is the user's responsibility to
arrange rework and resubmit.
- If any required role is not present in the session, block and report to the user.

29
workflows/spike.md Normal file
View File

@ -0,0 +1,29 @@
---
name: Spike
description: Time-boxed exploratory investigation to determine whether and how to proceed
roles: researcher
---
Use this workflow when the goal is to evaluate an approach, assess feasibility,
or answer a strategic question — not to produce a design or implementation.
The output is a recommendation: proceed, don't proceed, or proceed differently.
## Decomposition
| # | Title | Role | Depends On |
|---|------------------------|------------|------------|
| 1 | Spike: <description> | researcher | — |
## Handoffs
None. Output goes directly to the conductor and user.
## Notes
- The researcher must time-box exploration. If the answer cannot be determined
within reasonable effort, that itself is the finding — report it and stop.
- The output must include a clear recommendation, not an open-ended summary.
- If the recommendation is to proceed, the conductor should report this to the
user and wait for a follow-on bead rather than spawning implementation work
unilaterally.
- If any required role is not present in the session, block and report to the user.