opencode-bonfire 1.4.0 → 2.0.0

package/files/command/bonfire-strategic.md

@@ -0,0 +1,166 @@
+---
+description: Create strategic documents (RFC, PRD, POC)
+---
+
+# Create Strategic Document
+
+Create a strategic document of type **$1** for **$2**.
+
+---
+
+## Document Type Detection
+
+Parse $ARGUMENTS:
+- First word: document type (rfc, prd, poc)
+- Remaining: topic/subject
+
+Examples:
+- `/bonfire-strategic rfc authentication` → RFC about authentication
+- `/bonfire-strategic prd dark-mode` → PRD about dark mode feature
+- `/bonfire-strategic poc acme-corp` → POC plan for Acme Corp
+
+If type not recognized or missing, ask user to specify.
+
+---
+
+## Supported Types
+
+| Type | Full Name | Use Case |
+|------|-----------|----------|
+| `rfc` | Request for Comments | Technical decisions, architecture proposals |
+| `prd` | Product Requirements Document | Product specs, feature definitions |
+| `poc` | Proof of Concept Plan | Customer evaluations, technical validations |
+
+---
+
+## Shared Flow
+
+All document types follow the same research → interview → write pattern:
+
+### Phase 1: Research (Subagent)
+
+**Progress**: Tell the user "Researching codebase for context..."
+
+Use the Task tool to invoke the **codebase-explorer** agent.
+
+Research questions vary by type:
+
+**RFC**: Prior art, architecture, constraints, stakeholders
+**PRD**: Related features, user flows, data model, technical constraints
+**POC**: Relevant features, integration points, configuration, limitations
+
+**Wait for findings** before proceeding.
+
+### Phase 2: Interview (Main Context)
+
+**Progress**: Tell the user "Starting interview..."
+
+Interview rounds vary by type:
+
+**RFC** (3 rounds):
+1. Problem definition
+2. Proposed solutions
+3. Logistics & scope
+
+**PRD** (4 rounds):
+1. Problem & opportunity
+2. Target users
+3. Requirements & metrics
+4. Scope
+
+**POC** (4 rounds):
+1. Customer context
+2. Goals & success criteria
+3. Scope & timeline
+4. Risks & responsibilities
+
+Use the question tool with informed questions based on research.
+
+### Phase 3: Write (Subagent)
+
+**Progress**: Tell the user "Writing document..."
+
+Use the Task tool to invoke the **writer** agent.
+
+Provide:
+- Document type
+- Research findings
+- Interview Q&A
+- Output path
+- Template structure (type-specific)
+
+### Phase 4: Verify & Confirm
+
+Verify required sections are present (4 key sections per type).
+
+If incomplete, offer: proceed / retry / abort.
+
+---
+
+## Type-Specific Details
+
+### RFC (Request for Comments)
+
+**Interview rounds**:
+- Round 1: Problem definition (what problems, who experiences, evidence)
+- Round 2: Proposed solutions (approach, alternatives, tradeoffs)
+- Round 3: Logistics (reviewers, scope, timeline)
+
+**Required sections**:
+- `## Abstract`
+- `## Problems We Need To Solve`
+- `## Proposed Solution`
+- `## Alternatives Considered`
+
+**Naming**: `rfc-<topic>.md` or `rfc-<issue-id>-<topic>.md`
+
+---
+
+### PRD (Product Requirements Document)
+
+**Interview rounds**:
+- Round 1: Problem & opportunity (pain points, why now, business case)
+- Round 2: Target users (primary/secondary audiences, plan gating)
+- Round 3: Requirements & metrics (must-haves, success metrics)
+- Round 4: Scope (in/out of scope, dependencies)
+
+**Required sections**:
+- `## 2. Problem`
+- `## 5. Goals & Success Metrics`
+- `## 6. Product Requirements`
+- `## 9. Scope`
+
+**Naming**: `prd-<feature>.md` or `prd-<issue-id>-<feature>.md`
+
+---
+
+### POC (Proof of Concept Plan)
+
+**Interview rounds**:
+- Round 1: Customer context (who, current state, why evaluating)
+- Round 2: Goals & success criteria (what to prove, measurable outcomes)
+- Round 3: Scope & timeline (in/out scope, dates, deadlines)
+- Round 4: Risks & responsibilities (ownership, assumptions, risks)
+
+**Required sections**:
+- `## 2. Goals`
+- `## 3. Success Criteria`
+- `## 4. Scope`
+- `## 5. Plan & Timeline`
+
+**Naming**: `poc-<customer>.md` or `poc-<issue-id>-<customer>.md`
+
+---
+
+## File Locations
+
+- **Config**: `<git-root>/.bonfire/config.json` contains `docsLocation`
+- **Default**: `.bonfire/docs/` if not configured
+
+---
+
+## Post-Write
+
+1. **Verify** document has required sections
+2. **Link** to session context in `<git-root>/.bonfire/index.md`
+3. **Confirm** with user and offer next steps

package/files/opencode.json

@@ -7,9 +7,6 @@
     },
     {
       "directory": "skill/archive-bonfire-awareness"
-    },
-    {
-      "directory": "skill/handoff-awareness"
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-bonfire",
-  "version": "1.4.0",
+  "version": "2.0.0",
   "description": "OpenCode forgets everything between sessions. Bonfire remembers.",
   "type": "module",
   "bin": {

package/files/agent/doc-writer.md

@@ -1,120 +0,0 @@
----
-description: Synthesizes research findings into reference documentation
-mode: subagent
-hidden: true
-temperature: 0.1
-maxSteps: 25
-tools:
-  bash: false
-  glob: false
-  grep: false
-  todowrite: false
-  todoread: false
-permission:
-  task:
-    "*": deny
----
-
-You are a technical documentation writer. Given research findings about a codebase topic, produce clear, useful reference documentation.
-
-## Input Format
-
-You'll receive a structured prompt with these sections:
-
-```
-## Research Findings
-
-<structured markdown from codebase-explorer>
-
-## Doc Metadata
-
-- **Topic**: <what to document>
-- **Output Path**: </absolute/path/to/doc.md>
-- **Date**: <YYYY-MM-DD>
-```
-
-All sections are required. Write the documentation to the exact path specified in Output Path.
-
-**Mapping findings to doc sections:**
-- Architecture/Patterns → Architecture, How It Works
-- Key Files → Key Files table
-- Flow → How It Works (step-by-step)
-- Gotchas → Gotchas section
-- Constraints → noted throughout where relevant
-
-## Output
-
-Write a complete documentation file to the specified path. The doc must be:
-- **Clear** - Understandable by someone new to the codebase
-- **Grounded** - Based on discovered patterns, not assumptions
-- **Useful** - Answers "how does this work?" and "where do I look?"
-
-## Doc Template
-
-```markdown
-# [TOPIC]
-
-## Overview
-
-[What this is, why it exists, when you'd interact with it]
-
-## Architecture
-
-[How it's structured - components, layers, key relationships]
-
-```mermaid
-flowchart TD
-    A[Component A] --> B[Component B]
-    B --> C[Component C]
-```
-
-## Key Files
-
-| File | Purpose |
-|------|---------|
-| `path/to/file.ts` | [What it does] |
-| `path/to/other.ts` | [What it does] |
-
-## How It Works
-
-[Step-by-step flow, data transformations, control flow]
-
-1. **Step one**: [What happens]
-2. **Step two**: [What happens]
-3. **Step three**: [What happens]
-
-## Usage Examples
-
-[Code examples, CLI commands, common operations]
-
-```typescript
-// Example usage
-```
-
-## Gotchas
-
-- **[Issue]**: [Why it matters, how to avoid]
-- **[Edge case]**: [What to watch out for]
-
-## Related
-
-- [Related doc](other-doc.md)
-- [Code reference]: `path/to/file.ts`
-```
-
-## Rules
-
-1. **Ground in research** - Reference actual files and patterns discovered
-2. **Be specific** - Use real file paths, not placeholders
-3. **Don't invent** - If something wasn't in findings, don't guess
-4. **Keep it scannable** - Headers, tables, and lists over prose
-5. **Include code paths** - Always show where to look in the codebase
-
-## Quality Checklist
-
-Before finishing, verify:
-- [ ] Overview explains what and why
-- [ ] Key files table has real paths from research
-- [ ] How It Works section is step-by-step
-- [ ] Gotchas from research are captured
-- [ ] Mermaid diagram accurately reflects architecture (if included)

package/files/agent/spec-writer.md

@@ -1,142 +0,0 @@
----
-description: Synthesizes research findings and interview answers into implementation specs
-mode: subagent
-hidden: true
-temperature: 0.1
-maxSteps: 25
-tools:
-  bash: false
-  glob: false
-  grep: false
-  todowrite: false
-  todoread: false
-permission:
-  task:
-    "*": deny
----
-
-You are a technical specification writer. Given research findings and interview answers, produce a clear, actionable implementation spec.
-
-## Input Format
-
-You'll receive a structured prompt with these sections:
-
-```
-## Research Findings
-
-<structured markdown from codebase-explorer>
-
-## Interview Q&A
-
-### Core Decisions
-**Q**: <question about fundamental approach>
-**A**: <user's answer>
-
-### Edge Cases & Tradeoffs
-**Q**: <question about error handling, edge cases>
-**A**: <user's answer>
-
-### Scope & Boundaries
-**Q**: <question about what's in/out of scope>
-**A**: <user's answer>
-
-## Spec Metadata
-
-- **Topic**: <feature or task name>
-- **Issue**: <issue ID or N/A>
-- **Output Path**: </absolute/path/to/spec.md>
-- **Date**: <YYYY-MM-DD>
-```
-
-All sections are required. Write the spec to the exact path specified in Output Path.
-
-**Mapping Q&A to spec sections:**
-- Core Decisions → Decisions, Approach
-- Edge Cases & Tradeoffs → Edge Cases, Risks & Considerations
-- Scope & Boundaries → Out of Scope, Implementation Steps
-
-## Output
-
-Write a complete spec file to the specified path. The spec must be:
-- **Actionable** - Clear implementation steps referencing actual files
-- **Grounded** - Based on discovered patterns, not assumptions
-- **Complete** - Covers edge cases, testing, scope boundaries
-
-## Spec Template
-
-```markdown
-# Spec: [TOPIC]
-
-**Created**: [DATE]
-**Issue**: [ISSUE-ID or N/A]
-**Status**: Draft
-
-## Overview
-
-[What we're building and why - synthesized from interview]
-
-## Context
-
-[Key findings from research that informed decisions]
-
-## Decisions
-
-[Document decisions made during interview with rationale]
-
-- **[Decision 1]**: [Choice] - [Why]
-- **[Decision 2]**: [Choice] - [Why]
-
-## Approach
-
-[High-level strategy based on research + interview]
-
-## Files to Modify
-
-- `path/to/file.ts` - [what changes]
-
-## Files to Create
-
-- `path/to/new.ts` - [purpose]
-
-## Implementation Steps
-
-1. [ ] Step one (reference actual files)
-2. [ ] Step two
-3. [ ] Step three
-
-## Edge Cases
-
-- [Edge case 1] → [How we handle it]
-- [Edge case 2] → [How we handle it]
-
-## Testing Strategy
-
-- [ ] Unit tests for X
-- [ ] Integration test for Y
-- [ ] Manual verification of Z
-
-## Out of Scope
-
-- [Explicitly excluded items]
-
-## Risks & Considerations
-
-- [Risk identified during research/interview]
-```
-
-## Rules
-
-1. **Ground in research** - Reference actual files and patterns discovered
-2. **Honor interview answers** - Don't override user decisions
-3. **Be specific** - "Update UserService.ts" not "Update the service"
-4. **Don't invent** - If something wasn't discussed, don't add it
-5. **Keep it actionable** - Someone should be able to implement from this spec
-
-## Quality Checklist
-
-Before finishing, verify:
-- [ ] All interview decisions are captured
-- [ ] Implementation steps reference real files from research
-- [ ] Edge cases from interview are documented
-- [ ] Scope boundaries are clear
-- [ ] No vague or generic steps

package/files/command/bonfire-git-strategy.md

@@ -1,91 +0,0 @@
----
-description: Change how .bonfire/ is handled in git
----
-
-# Change Git Strategy
-
-## Step 1: Find Git Root
-
-Run `git rev-parse --show-toplevel` to locate the repository root.
-
-## Step 2: Read Current Config
-
-Read `<git-root>/.bonfire/config.json` to check current `specsLocation` and `docsLocation` settings.
-
-## Step 3: Explain Options
-
-Present the git strategy options:
-
-1. **Ignore all** - Keep sessions completely local
-   - Everything in .bonfire/ is gitignored
-   - Most private, nothing shared
-   - Good for: solo work, sensitive projects
-
-2. **Hybrid** - Commit docs/specs, keep notes private
-   - docs/ and specs/ are committed
-   - index.md and archive/ stay local
-   - Good for: teams that want shared docs but private notes
-
-3. **Commit all** - Share everything with team
-   - All session content is committed
-   - Only data/ and scratch/ ignored
-   - Good for: full transparency, team continuity
-
-## Step 4: Get User Choice
-
-Use the question tool to ask which strategy:
-
-"Which git strategy for `.bonfire/`?" (Header: "Git")
-- ignore-all (Recommended) - Keep sessions private/local
-- hybrid - Commit docs/specs, keep notes private
-- commit-all - Share everything with team
-
-## Step 5: Update .gitignore
-
-Write the appropriate `.gitignore` to `<git-root>/.bonfire/.gitignore`:
-
-**Ignore all**:
-```
-*
-!.gitignore
-```
-
-**Hybrid** (only include dirs that are inside .bonfire/):
-```
-*
-!.gitignore
-```
-If docsLocation is `.bonfire/docs/`, add:
-```
-!docs/
-!docs/**
-```
-If specsLocation is `.bonfire/specs/`, add:
-```
-!specs/
-!specs/**
-```
-
-**Commit all**:
-```
-data/
-scratch/
-```
-
-## Step 6: Handle Git Tracking
-
-If switching FROM commit/hybrid TO ignore:
-- Warn user that existing tracked files will remain tracked
-- Offer to run: `git rm -r --cached .bonfire/` (removes from git but keeps files)
-- They'll need to commit this change
-
-If switching TO commit/hybrid:
-- Files will be picked up on next commit
-- No special action needed
-
-## Step 7: Confirm
-
-Report:
-- New strategy applied
-- Any manual steps needed
-- How to verify the change

package/files/command/bonfire-handoff.md

@@ -1,168 +0,0 @@
----
-description: Hand off session to new Claude instance when approaching context limits
----
-
-# Session Handoff
-
-Hand off the current session to a fresh Claude instance, preserving work state.
-
-## Step 1: Verify Environment
-
-Check if running inside tmux:
-
-```bash
-[ -n "$TMUX" ] && echo "tmux: yes" || echo "tmux: no"
-```
-
-**If not in tmux**: Still generate handoff context, then provide manual instructions:
-
-1. Continue with Steps 2-8 (skip Step 9)
-2. Tell the user:
-
-> "Automatic session spawning requires tmux. I've saved the handoff context.
->
-> **To continue manually:**
-> 1. Open a new terminal in this directory
-> 2. Run: `opencode --append-system-prompt "$(cat .bonfire/handoff/context.md)"`
-> 3. In the new session, run `/bonfire-start` to load full history
->
-> The handoff context is saved at `.bonfire/handoff/context.md`"
-
-## Step 2: Find Git Root
-
-```bash
-git rev-parse --show-toplevel
-```
-
-## Step 3: Verify Bonfire Exists
-
-Check if `<git-root>/.bonfire/index.md` exists.
-
-**If not**: Abort with message:
-> "No .bonfire/ directory found. Run `/bonfire-start` first to initialize session tracking."
-
-## Step 4: Check for Uncommitted Changes
-
-```bash
-git status --porcelain
-```
-
-**If uncommitted changes exist**: Warn the user:
-> "Note: You have uncommitted changes. The new session will see them. Consider committing or stashing before handoff."
-
-Ask if they want to proceed anyway.
-
-## Step 5: Update index.md
-
-Read `<git-root>/.bonfire/index.md` and update the current session entry:
-
-1. **Add HANDOFF marker** to session title:
-   ```markdown
-   ### Session N - DATE (HANDOFF)
-   ```
-
-2. **Add "In Progress at Handoff"** section:
-   ```markdown
-   **In Progress at Handoff**:
-   - [What was actively being worked on]
-   - [Current state of that work]
-   ```
-
-3. **Add handoff metadata**:
-   ```markdown
-   **Handoff Reason**: Approaching context limit
-   **Continued In**: Next session
-   ```
-
-4. **Update "Next Session Priorities"** with the immediate work that needs to continue.
-
-5. **Update Codemap** "This Session's Key Files" with files relevant to current work.
-
-## Step 6: Generate Handoff Context
-
-Create `<git-root>/.bonfire/handoff/` directory if it doesn't exist.
-
-Write `<git-root>/.bonfire/handoff/context.md` with minimal context (~1K tokens max):
-
-```markdown
-# Session Handoff Context
-
-**Date**: [CURRENT_DATE]
-**Branch**: [current git branch]
-**Repository**: [repo name from package.json or directory name]
-
-## Current Task
-
-[1-2 sentences describing what was actively being worked on when handoff triggered]
-
-## Immediate Next Steps
-
-1. [First priority - most urgent continuation]
-2. [Second priority]
-3. [Third priority if applicable]
-
-## Key Context
-
-- [Critical decision or constraint affecting the work]
-- [Important file or component being modified]
-- [Any blockers or considerations for new session]
-
-## Uncommitted Changes
-
-[List modified files from git status, or "None" if clean]
-
----
-
-**Instructions for new session**: Run `/bonfire-start` to load full session context from `.bonfire/index.md`.
-```
-
-**Size guidance**: Keep this file under 1000 tokens (~150 words, ~750 characters). Focus on what's needed to continue immediately, not history. If the content exceeds this, trim the "Key Context" section to essential items only.
-
-## Step 7: Mark Session as Handed Off
-
-Create a marker file to prevent context corruption:
-
-```bash
-echo "$(date -Iseconds)" > <git-root>/.bonfire/handoff/handed-off
-```
-
-This marker tells other commands (like `/bonfire-end`) that this session has been handed off and should not update `index.md` again.
-
-## Step 8: Add handoff/ to .gitignore
-
-Read `<git-root>/.bonfire/.gitignore` and add `handoff/` if not present:
-
-```
-handoff/
-```
-
-Handoff context is transient and should not be committed.
-
-## Step 9: Spawn New Session
-
-Run the tmux command to spawn a new pane (horizontal split):
-
-```bash
-REPO_ROOT="$(git rev-parse --show-toplevel)"
-CONTEXT="$(cat "$REPO_ROOT/.bonfire/handoff/context.md")"
-tmux split-window -h -c "$REPO_ROOT" \
-  "opencode --append-system-prompt '$CONTEXT' 'Continuing from session handoff. Please run /bonfire-start to load the full session context.'"
-```
-
-**Verify spawn succeeded**: Check that the new pane exists. If tmux fails (e.g., terminal too small), warn the user and provide manual instructions from Step 1.
-
-This creates a new pane to the right of the current pane, keeping both sessions visible during handoff.
-
-## Step 10: Confirm Handoff
-
-Tell the user:
-
-> **Handoff complete.**
->
-> - Session state saved to `.bonfire/index.md`
-> - Handoff context written to `.bonfire/handoff/context.md`
-> - New session spawned in adjacent pane
->
-> The new session will run `/bonfire-start` to load your full session history.
->
-> You can close this pane when ready, or keep both visible during transition.