Skip to content

Commit bf724c8

Browse files
v1truv1usclaude
v1truv1us
and
claude
committed
feat: implement interactive tmux ritual automation system
Transform Rune from basic command automation to sophisticated interactive development environment management using tmux and PTY integration. Major Features: • Interactive command execution with tmux session management • Template-based multi-pane development environment creation • PTY fallback for direct interactive terminal access • Session persistence across rune restarts with state management • Full backwards compatibility with existing ritual configurations Core Implementation: • Add tmux client wrapper with gotmux and session lifecycle management • Implement PTY command execution using creack/pty with proper TTY handling • Extend config system to support interactive commands and tmux templates • Add comprehensive template system for complex multi-window layouts • Integrate session persistence with automatic cleanup and restoration Technical Details: • Enhanced ritual engine to dispatch interactive vs standard commands • Added environment filtering to maintain security model • Cross-platform tmux detection with graceful degradation • Comprehensive test coverage including integration and unit tests • Template variable substitution ({{.Project}}, {{.User}}, etc.) Documentation: • Complete user guide for interactive ritual configuration • Developer API documentation for tmux client integration • Troubleshooting guide for common tmux setup issues • Migration examples from simple to interactive rituals All phases of the implementation plan completed successfully: - Phase 1: Enhanced command configuration ✅ - Phase 2: Go dependencies and basic tmux integration ✅ - Phase 3: Interactive execution engine with PTY integration ✅ - Phase 4: Template system and advanced features ✅ This enables developers to automate complex development environments while maintaining Rune's security-first design principles. 🤖 Generated with Claude Code (https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
1 parent b190018 commit bf724c8

40 files changed

+6655
-16
lines changed

‎.claude/claude_config.json‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
{
2+
"commands": {
3+
"enabled": true,
4+
"directory": "commands"
5+
}
6+
}

‎.claude/commands/commit.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
---
2+
description: Commits the local changes in multiple atomic commits
3+
---
4+
5+
# Commit Changes
6+
7+
You are tasked with creating git commits for the changes made during this session.
8+
9+
## Process:
10+
11+
1. **Think about what changed:**
12+
- Review the conversation history and understand what was accomplished
13+
- Review the <git-status> to get an idea of what files changed
14+
- Review the <git-diff> to understand the modifications
15+
- Consider whether changes should be one commit or multiple logical commits
16+
17+
2. **Plan your commit(s):**
18+
- Identify which files belong together
19+
- Draft clear, descriptive commit messages
20+
- Use imperative mood in commit messages
21+
- Focus on why the changes were made, not just what
22+
23+
3. **Present your plan to the user:**
24+
- List the files you plan to add for each commit
25+
- Show the commit message(s) you'll use
26+
- Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
27+
28+
4. **Execute upon confirmation:**
29+
- Use `git add` with specific files (never use `-A` or `.`)
30+
- Create commits with your planned messages
31+
- Show the result with `git log --oneline -n [number]`
32+
33+
## Remember:
34+
- You have the full context of what was done in this session
35+
- Group related changes together
36+
- Keep commits focused and atomic when possible
37+
- The user trusts your judgment - they asked you to commit
38+
39+
<git-status>
40+
`!git status -s`
41+
</git-status>
42+
43+
<git-diff>
44+
`!git diff`
45+
</git-diff>

‎.claude/commands/document.md‎

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
description: Create user, API, and technical documentation from code and plans
3+
---
4+
5+
# Document Feature
6+
7+
You are tasked with producing high-quality documentation based on the implemented feature, its plan, and the code. Deliver user-facing guides, API references, and developer notes as appropriate.
8+
9+
## Inputs
10+
- <audience>: user | api | developer | mixed
11+
- <plan>: optional path to implementation plan
12+
- <files>: key code files for reference
13+
- <changelog>: optional list of notable changes
14+
15+
## Process
16+
17+
1) Gather and read context
18+
- Read <plan> if provided
19+
- Read all <files> fully (no limit/offset)
20+
- Skim related modules to confirm behavior and constraints
21+
22+
2) Choose document set by audience
23+
- user: step-by-step how-to, screenshots/placeholders, troubleshooting
24+
- api: endpoint/CLI reference, request/response, error codes, examples
25+
- developer: architecture overview, data flow, invariants, extension points
26+
27+
3) Draft structure, then fill in details
28+
- Present a concise outline first if scope is broad
29+
- Keep sections short, scannable, and accurate to code
30+
31+
4) Validate correctness
32+
- Cross-check examples with real code/CLI outputs
33+
- Prefer copyable examples that run
34+
35+
5) Save docs
36+
- Use `thoughts/documentation/` with descriptive filenames
37+
- Keep one file per audience when possible
38+
39+
## Templates
40+
41+
### User Guide
42+
```markdown
43+
---
44+
title: <Feature Name> - User Guide
45+
audience: user
46+
version: <semver or commit>
47+
---
48+
49+
## Overview
50+
Short description of the value and when to use it.
51+
52+
## Prerequisites
53+
- ...
54+
55+
## Steps
56+
1. ...
57+
2. ...
58+
59+
## Troubleshooting
60+
- Symptom → Cause → Fix
61+
```
62+
63+
### API Reference
64+
```markdown
65+
---
66+
title: <Feature Name> - API Reference
67+
audience: api
68+
version: <semver or commit>
69+
---
70+
71+
## Endpoints / Commands
72+
- Method/Command: Path / Name
73+
- Request: fields and types
74+
- Response: fields and types
75+
- Errors: codes/messages
76+
- Examples:
77+
```bash
78+
curl ...
79+
```
80+
```
81+
82+
### Developer Notes
83+
```markdown
84+
---
85+
title: <Feature Name> - Developer Notes
86+
audience: developer
87+
version: <semver or commit>
88+
---
89+
90+
## Architecture
91+
- Components and data flow
92+
93+
## Key Decisions
94+
- Rationale and implications
95+
96+
## Extension Points
97+
- How to add/modify behavior safely
98+
```
99+
100+
## Deliverables
101+
- Files under `thoughts/documentation/`:
102+
- `YYYY-MM-DD-<feature>-user.md` (if audience includes user)
103+
- `YYYY-MM-DD-<feature>-api.md` (if audience includes api)
104+
- `YYYY-MM-DD-<feature>-dev.md` (if audience includes developer)
105+
106+
<audience>$ARGUMENTS</audience>

‎.claude/commands/execute.md‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
---
2+
description: Execute a specific implementation plan.
3+
---
4+
5+
# Implement Plan
6+
7+
You are tasked with implementing an approved technical plan from `thoughts/plans/`. These plans contain phases with specific changes and success criteria.
8+
9+
## Getting Started
10+
11+
- Read the plan completely and check for any existing checkmarks (- [x])
12+
- Read the original ticket and all files mentioned in the plan
13+
- **Read files fully** - never use limit/offset parameters, you need complete context
14+
- Think deeply about how the pieces fit together
15+
- Create a todo list to track your progress
16+
- Start implementing if you understand what needs to be done
17+
18+
## Implementation Philosophy
19+
20+
Plans are carefully designed, but reality can be messy. Your job is to:
21+
- Follow the plan's intent while adapting to what you find
22+
- Implement each phase fully before moving to the next
23+
- Verify your work makes sense in the broader codebase context
24+
- Update checkboxes in the plan as you complete sections
25+
26+
When things don't match the plan exactly, think about why and communicate clearly. The plan is your guide, but your judgment matters too.
27+
28+
If you encounter a mismatch:
29+
- STOP and think deeply about why the plan can't be followed
30+
- Present the issue clearly:
31+
```
32+
Issue in Phase [N]:
33+
Expected: [what the plan says]
34+
Found: [actual situation]
35+
Why this matters: [explanation]
36+
37+
How should I proceed?
38+
```
39+
40+
## Verification Approach
41+
42+
After implementing a phase:
43+
- Run the success criteria checks (usually `bun run check` covers everything)
44+
- Fix any issues before proceeding
45+
- Update your progress in both the plan and your todos
46+
- Check off completed items in the plan file itself using Edit
47+
48+
Don't let verification interrupt your flow - batch it at natural stopping points.
49+
50+
## If You Get Stuck
51+
52+
When something isn't working as expected:
53+
- First, make sure you've read and understood all the relevant code
54+
- Consider if the codebase has evolved since the plan was written
55+
- Present the mismatch clearly and ask for guidance
56+
57+
Use sub-tasks sparingly - mainly for targeted debugging or exploring unfamiliar territory.
58+
59+
## Resuming Work
60+
61+
If the plan has existing checkmarks:
62+
- Trust that completed work is done
63+
- Pick up from the first unchecked item
64+
- Verify previous work only if something seems off
65+
66+
Remember: You're implementing a solution, not just checking boxes. Keep the end goal in mind and maintain forward momentum.

0 commit comments

Comments
 (0)