Skip to content

Commit f3fdfa9

Browse files
ctecte
committed
Add some slash commands that are useful for cli development
1 parent a4eb15b commit f3fdfa9

File tree

4 files changed

+230
-1
lines changed

4 files changed

+230
-1
lines changed

‎.roo/commands/cli-release.md‎

Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
---
2+
description: "Create a new release of the Roo Code CLI"
3+
argument-hint: "[version-description]"
4+
mode: code
5+
---
6+
7+
1. Identify changes since the last CLI release:
8+
9+
- Get the last CLI release tag: `gh release list --limit 10 | grep "cli-v"`
10+
- View changes since last release: `git log cli-v<last-version>..HEAD -- apps/cli --oneline`
11+
- Or for uncommitted changes: `git diff --stat -- apps/cli`
12+
13+
2. Review and summarize the changes to determine an appropriate changelog entry. Group changes by type:
14+
15+
- **Added**: New features
16+
- **Changed**: Changes to existing functionality
17+
- **Fixed**: Bug fixes
18+
- **Removed**: Removed features
19+
- **Tests**: New or updated tests
20+
21+
3. Bump the version in `apps/cli/package.json`:
22+
23+
- Increment the patch version (e.g., 0.0.43 → 0.0.44) for bug fixes and minor changes
24+
- Increment the minor version (e.g., 0.0.43 → 0.1.0) for new features
25+
- Increment the major version (e.g., 0.0.43 → 1.0.0) for breaking changes
26+
27+
4. Update `apps/cli/CHANGELOG.md` with a new entry:
28+
29+
- Add a new section at the top (below the header) following this format:
30+
31+
```markdown
32+
## [X.Y.Z] - YYYY-MM-DD
33+
34+
### Added
35+
36+
- Description of new features
37+
38+
### Changed
39+
40+
- Description of changes
41+
42+
### Fixed
43+
44+
- Description of bug fixes
45+
```
46+
47+
- Use the current date in YYYY-MM-DD format
48+
- Include links to relevant source files where helpful
49+
- Describe changes from the user's perspective
50+
51+
5. Commit the version bump and changelog update:
52+
53+
```bash
54+
git add apps/cli/package.json apps/cli/CHANGELOG.md
55+
git commit -m "chore(cli): prepare release v<version>"
56+
```
57+
58+
6. Run the release script from the monorepo root:
59+
60+
```bash
61+
./apps/cli/scripts/release.sh
62+
```
63+
64+
The release script will automatically:
65+
66+
- Build the extension and CLI
67+
- Create a platform-specific tarball
68+
- Verify the installation works correctly (runs --help, --version, and e2e test)
69+
- Extract changelog content and include it in the GitHub release notes
70+
- Create the GitHub release with the tarball attached
71+
72+
7. After a successful release, verify:
73+
- Check the release page: https://github.com/RooCodeInc/Roo-Code/releases
74+
- Verify the "What's New" section contains the changelog content
75+
- Test installation: `curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh`
76+
77+
**Notes:**
78+
79+
- The release script requires GitHub CLI (`gh`) to be installed and authenticated
80+
- If a release already exists for the tag, the script will prompt to delete and recreate it
81+
- The script creates a tarball for the current platform only (darwin-arm64, darwin-x64, linux-arm64, or linux-x64)
82+
- Multi-platform releases require running the script on each platform and manually uploading additional tarballs

‎.roo/commands/commit.md‎

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
---
2+
description: "Commit and push changes with a descriptive message"
3+
argument-hint: "[optional-context]"
4+
mode: code
5+
---
6+
7+
1. Analyze the current changes to understand what needs to be committed:
8+
9+
```bash
10+
# Check for staged and unstaged changes
11+
git status --short
12+
13+
# View the diff of all changes (staged and unstaged)
14+
git diff HEAD
15+
```
16+
17+
2. Based on the diff output, formulate a commit message following conventional commit format:
18+
19+
- **feat**: New feature or functionality
20+
- **fix**: Bug fix
21+
- **refactor**: Code restructuring without behavior change
22+
- **docs**: Documentation changes
23+
- **test**: Adding or updating tests
24+
- **chore**: Maintenance tasks, dependencies, configs
25+
- **style**: Formatting, whitespace, no logic changes
26+
27+
Format: `type(scope): brief description`
28+
29+
Examples:
30+
31+
- `feat(api): add user authentication endpoint`
32+
- `fix(ui): resolve button alignment on mobile`
33+
- `refactor(core): simplify error handling logic`
34+
- `docs(readme): update installation instructions`
35+
36+
3. Stage all unstaged changes:
37+
38+
```bash
39+
git add -A
40+
```
41+
42+
4. Commit with the generated message:
43+
44+
```bash
45+
git commit -m "type(scope): brief description"
46+
```
47+
48+
**If pre-commit hooks fail:**
49+
50+
- Review the error output (linter errors, type checking errors, etc.)
51+
- Fix the identified issues in the affected files
52+
- Re-stage the fixes: `git add -A`
53+
- Retry the commit: `git commit -m "type(scope): brief description"`
54+
55+
5. Push to the remote repository:
56+
57+
```bash
58+
git push
59+
```
60+
61+
**If pre-push hooks fail:**
62+
63+
- Review the error output (test failures, linter errors, etc.)
64+
- Fix the identified issues in the affected files
65+
- Stage and commit the fixes using steps 3-4
66+
- Retry the push: `git push`
67+
68+
**Tips for good commit messages:**
69+
70+
- Keep the first line under 72 characters
71+
- Use imperative mood ("add", "fix", "update", not "added", "fixes", "updated")
72+
- Be specific but concise
73+
- If multiple unrelated changes exist, consider splitting into separate commits
74+
75+
**Common hook failures and fixes:**
76+
77+
- **Linter errors**: Run the project's linter (e.g., `npm run lint` or `pnpm lint`) to see all issues, then fix them
78+
- **Type checking errors**: Run type checker (e.g., `npx tsc --noEmit`) to identify type issues
79+
- **Test failures**: Run tests (e.g., `npm test` or `pnpm test`) to identify failing tests and fix them
80+
- **Format issues**: Run formatter (e.g., `npm run format` or `pnpm format`) to auto-fix formatting

‎.roo/rules-debug/cli.md‎

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
# CLI Debugging with File-Based Logging
2+
3+
When debugging the CLI, `console.log` will break the TUI (Terminal User Interface). Use file-based logging to capture debug output without interfering with the application's display.
4+
5+
## File-Based Logging Strategy
6+
7+
1. **Write logs to a temporary file instead of console**:
8+
9+
- Create a log file at a known location, e.g., `/tmp/roo-cli-debug.log`
10+
- Use `fs.appendFileSync()` to write timestamped log entries
11+
- Example logging utility:
12+
13+
```typescript
14+
import fs from "fs"
15+
const DEBUG_LOG = "/tmp/roo-cli-debug.log"
16+
17+
function debugLog(message: string, data?: unknown) {
18+
const timestamp = new Date().toISOString()
19+
const entry = data
20+
? `[${timestamp}] ${message}: ${JSON.stringify(data, null, 2)}\n`
21+
: `[${timestamp}] ${message}\n`
22+
fs.appendFileSync(DEBUG_LOG, entry)
23+
}
24+
```
25+
26+
2. **Clear the log file before each debugging session**:
27+
- Run `echo "" > /tmp/roo-cli-debug.log` or use `fs.writeFileSync(DEBUG_LOG, "")` at app startup during debugging
28+
29+
## Iterative Debugging Workflow
30+
31+
Follow this feedback loop to systematically narrow down issues:
32+
33+
1. **Add targeted logging** at suspected problem areas based on your hypotheses
34+
2. **Instruct the user** to reproduce the issue using the CLI normally
35+
3. **Read the log file** after the user completes testing:
36+
- Run `cat /tmp/roo-cli-debug.log` to retrieve the captured output
37+
4. **Analyze the log output** to gather clues about:
38+
- Execution flow and timing
39+
- Variable values at key points
40+
- Which code paths were taken
41+
- Error conditions or unexpected states
42+
5. **Refine your logging** based on findings—add more detail where needed, remove noise
43+
6. **Ask the user to test again** with updated logging
44+
7. **Repeat** until the root cause is identified
45+
46+
## Best Practices
47+
48+
- Log entry/exit points of functions under investigation
49+
- Include relevant variable values and state information
50+
- Use descriptive prefixes to categorize logs: `[STATE]`, `[EVENT]`, `[ERROR]`, `[FLOW]`
51+
- Log both the "happy path" and error handling branches
52+
- When dealing with async operations, log before and after `await` statements
53+
- For user interactions, log the received input and the resulting action
54+
55+
## Example Debug Session
56+
57+
```typescript
58+
// Add logging to investigate a picker selection issue
59+
debugLog("[FLOW] PickerSelect onSelect called", { selectedIndex, item })
60+
debugLog("[STATE] Current selection state", { currentValue, isOpen })
61+
62+
// After async operation
63+
const result = await fetchOptions()
64+
debugLog("[FLOW] fetchOptions completed", { resultCount: result.length })
65+
```
66+
67+
Then ask: "Please reproduce the issue by [specific steps]. When you're done, let me know and I'll analyze the debug logs."

‎packages/core/src/debug-log/index.ts‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@
55
* which would break TUI applications. The log format is timestamped JSON.
66
*
77
* Usage:
8-
* import { debugLog, DebugLogger } from "@roo-code/core/debug-log"
8+
* import { debugLog, DebugLogger } from "@roo-code/core/cli"
99
*
1010
* // Simple logging
1111
* debugLog("handleModeSwitch", { mode: newMode, configId })

0 commit comments

Comments
 (0)