mirror of
https://github.com/RooVetGit/Roo-Code.git
synced 2026-08-28 05:27:24 +00:00
Add some slash commands that are useful for cli development (#10586)
This commit is contained in:
parent
a4eb15b5a8
commit
237fa89b7e
4 changed files with 230 additions and 1 deletions
82
.roo/commands/cli-release.md
Normal file
82
.roo/commands/cli-release.md
Normal file
|
|
@ -0,0 +1,82 @@
|
|||
---
|
||||
description: "Create a new release of the Roo Code CLI"
|
||||
argument-hint: "[version-description]"
|
||||
mode: code
|
||||
---
|
||||
|
||||
1. Identify changes since the last CLI release:
|
||||
|
||||
- Get the last CLI release tag: `gh release list --limit 10 | grep "cli-v"`
|
||||
- View changes since last release: `git log cli-v<last-version>..HEAD -- apps/cli --oneline`
|
||||
- Or for uncommitted changes: `git diff --stat -- apps/cli`
|
||||
|
||||
2. Review and summarize the changes to determine an appropriate changelog entry. Group changes by type:
|
||||
|
||||
- **Added**: New features
|
||||
- **Changed**: Changes to existing functionality
|
||||
- **Fixed**: Bug fixes
|
||||
- **Removed**: Removed features
|
||||
- **Tests**: New or updated tests
|
||||
|
||||
3. Bump the version in `apps/cli/package.json`:
|
||||
|
||||
- Increment the patch version (e.g., 0.0.43 → 0.0.44) for bug fixes and minor changes
|
||||
- Increment the minor version (e.g., 0.0.43 → 0.1.0) for new features
|
||||
- Increment the major version (e.g., 0.0.43 → 1.0.0) for breaking changes
|
||||
|
||||
4. Update `apps/cli/CHANGELOG.md` with a new entry:
|
||||
|
||||
- Add a new section at the top (below the header) following this format:
|
||||
|
||||
```markdown
|
||||
## [X.Y.Z] - YYYY-MM-DD
|
||||
|
||||
### Added
|
||||
|
||||
- Description of new features
|
||||
|
||||
### Changed
|
||||
|
||||
- Description of changes
|
||||
|
||||
### Fixed
|
||||
|
||||
- Description of bug fixes
|
||||
```
|
||||
|
||||
- Use the current date in YYYY-MM-DD format
|
||||
- Include links to relevant source files where helpful
|
||||
- Describe changes from the user's perspective
|
||||
|
||||
5. Commit the version bump and changelog update:
|
||||
|
||||
```bash
|
||||
git add apps/cli/package.json apps/cli/CHANGELOG.md
|
||||
git commit -m "chore(cli): prepare release v<version>"
|
||||
```
|
||||
|
||||
6. Run the release script from the monorepo root:
|
||||
|
||||
```bash
|
||||
./apps/cli/scripts/release.sh
|
||||
```
|
||||
|
||||
The release script will automatically:
|
||||
|
||||
- Build the extension and CLI
|
||||
- Create a platform-specific tarball
|
||||
- Verify the installation works correctly (runs --help, --version, and e2e test)
|
||||
- Extract changelog content and include it in the GitHub release notes
|
||||
- Create the GitHub release with the tarball attached
|
||||
|
||||
7. After a successful release, verify:
|
||||
- Check the release page: https://github.com/RooCodeInc/Roo-Code/releases
|
||||
- Verify the "What's New" section contains the changelog content
|
||||
- Test installation: `curl -fsSL https://raw.githubusercontent.com/RooCodeInc/Roo-Code/main/apps/cli/install.sh | sh`
|
||||
|
||||
**Notes:**
|
||||
|
||||
- The release script requires GitHub CLI (`gh`) to be installed and authenticated
|
||||
- If a release already exists for the tag, the script will prompt to delete and recreate it
|
||||
- The script creates a tarball for the current platform only (darwin-arm64, darwin-x64, linux-arm64, or linux-x64)
|
||||
- Multi-platform releases require running the script on each platform and manually uploading additional tarballs
|
||||
80
.roo/commands/commit.md
Normal file
80
.roo/commands/commit.md
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
---
|
||||
description: "Commit and push changes with a descriptive message"
|
||||
argument-hint: "[optional-context]"
|
||||
mode: code
|
||||
---
|
||||
|
||||
1. Analyze the current changes to understand what needs to be committed:
|
||||
|
||||
```bash
|
||||
# Check for staged and unstaged changes
|
||||
git status --short
|
||||
|
||||
# View the diff of all changes (staged and unstaged)
|
||||
git diff HEAD
|
||||
```
|
||||
|
||||
2. Based on the diff output, formulate a commit message following conventional commit format:
|
||||
|
||||
- **feat**: New feature or functionality
|
||||
- **fix**: Bug fix
|
||||
- **refactor**: Code restructuring without behavior change
|
||||
- **docs**: Documentation changes
|
||||
- **test**: Adding or updating tests
|
||||
- **chore**: Maintenance tasks, dependencies, configs
|
||||
- **style**: Formatting, whitespace, no logic changes
|
||||
|
||||
Format: `type(scope): brief description`
|
||||
|
||||
Examples:
|
||||
|
||||
- `feat(api): add user authentication endpoint`
|
||||
- `fix(ui): resolve button alignment on mobile`
|
||||
- `refactor(core): simplify error handling logic`
|
||||
- `docs(readme): update installation instructions`
|
||||
|
||||
3. Stage all unstaged changes:
|
||||
|
||||
```bash
|
||||
git add -A
|
||||
```
|
||||
|
||||
4. Commit with the generated message:
|
||||
|
||||
```bash
|
||||
git commit -m "type(scope): brief description"
|
||||
```
|
||||
|
||||
**If pre-commit hooks fail:**
|
||||
|
||||
- Review the error output (linter errors, type checking errors, etc.)
|
||||
- Fix the identified issues in the affected files
|
||||
- Re-stage the fixes: `git add -A`
|
||||
- Retry the commit: `git commit -m "type(scope): brief description"`
|
||||
|
||||
5. Push to the remote repository:
|
||||
|
||||
```bash
|
||||
git push
|
||||
```
|
||||
|
||||
**If pre-push hooks fail:**
|
||||
|
||||
- Review the error output (test failures, linter errors, etc.)
|
||||
- Fix the identified issues in the affected files
|
||||
- Stage and commit the fixes using steps 3-4
|
||||
- Retry the push: `git push`
|
||||
|
||||
**Tips for good commit messages:**
|
||||
|
||||
- Keep the first line under 72 characters
|
||||
- Use imperative mood ("add", "fix", "update", not "added", "fixes", "updated")
|
||||
- Be specific but concise
|
||||
- If multiple unrelated changes exist, consider splitting into separate commits
|
||||
|
||||
**Common hook failures and fixes:**
|
||||
|
||||
- **Linter errors**: Run the project's linter (e.g., `npm run lint` or `pnpm lint`) to see all issues, then fix them
|
||||
- **Type checking errors**: Run type checker (e.g., `npx tsc --noEmit`) to identify type issues
|
||||
- **Test failures**: Run tests (e.g., `npm test` or `pnpm test`) to identify failing tests and fix them
|
||||
- **Format issues**: Run formatter (e.g., `npm run format` or `pnpm format`) to auto-fix formatting
|
||||
67
.roo/rules-debug/cli.md
Normal file
67
.roo/rules-debug/cli.md
Normal file
|
|
@ -0,0 +1,67 @@
|
|||
# CLI Debugging with File-Based Logging
|
||||
|
||||
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.
|
||||
|
||||
## File-Based Logging Strategy
|
||||
|
||||
1. **Write logs to a temporary file instead of console**:
|
||||
|
||||
- Create a log file at a known location, e.g., `/tmp/roo-cli-debug.log`
|
||||
- Use `fs.appendFileSync()` to write timestamped log entries
|
||||
- Example logging utility:
|
||||
|
||||
```typescript
|
||||
import fs from "fs"
|
||||
const DEBUG_LOG = "/tmp/roo-cli-debug.log"
|
||||
|
||||
function debugLog(message: string, data?: unknown) {
|
||||
const timestamp = new Date().toISOString()
|
||||
const entry = data
|
||||
? `[${timestamp}] ${message}: ${JSON.stringify(data, null, 2)}\n`
|
||||
: `[${timestamp}] ${message}\n`
|
||||
fs.appendFileSync(DEBUG_LOG, entry)
|
||||
}
|
||||
```
|
||||
|
||||
2. **Clear the log file before each debugging session**:
|
||||
- Run `echo "" > /tmp/roo-cli-debug.log` or use `fs.writeFileSync(DEBUG_LOG, "")` at app startup during debugging
|
||||
|
||||
## Iterative Debugging Workflow
|
||||
|
||||
Follow this feedback loop to systematically narrow down issues:
|
||||
|
||||
1. **Add targeted logging** at suspected problem areas based on your hypotheses
|
||||
2. **Instruct the user** to reproduce the issue using the CLI normally
|
||||
3. **Read the log file** after the user completes testing:
|
||||
- Run `cat /tmp/roo-cli-debug.log` to retrieve the captured output
|
||||
4. **Analyze the log output** to gather clues about:
|
||||
- Execution flow and timing
|
||||
- Variable values at key points
|
||||
- Which code paths were taken
|
||||
- Error conditions or unexpected states
|
||||
5. **Refine your logging** based on findings—add more detail where needed, remove noise
|
||||
6. **Ask the user to test again** with updated logging
|
||||
7. **Repeat** until the root cause is identified
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Log entry/exit points of functions under investigation
|
||||
- Include relevant variable values and state information
|
||||
- Use descriptive prefixes to categorize logs: `[STATE]`, `[EVENT]`, `[ERROR]`, `[FLOW]`
|
||||
- Log both the "happy path" and error handling branches
|
||||
- When dealing with async operations, log before and after `await` statements
|
||||
- For user interactions, log the received input and the resulting action
|
||||
|
||||
## Example Debug Session
|
||||
|
||||
```typescript
|
||||
// Add logging to investigate a picker selection issue
|
||||
debugLog("[FLOW] PickerSelect onSelect called", { selectedIndex, item })
|
||||
debugLog("[STATE] Current selection state", { currentValue, isOpen })
|
||||
|
||||
// After async operation
|
||||
const result = await fetchOptions()
|
||||
debugLog("[FLOW] fetchOptions completed", { resultCount: result.length })
|
||||
```
|
||||
|
||||
Then ask: "Please reproduce the issue by [specific steps]. When you're done, let me know and I'll analyze the debug logs."
|
||||
|
|
@ -5,7 +5,7 @@
|
|||
* which would break TUI applications. The log format is timestamped JSON.
|
||||
*
|
||||
* Usage:
|
||||
* import { debugLog, DebugLogger } from "@roo-code/core/debug-log"
|
||||
* import { debugLog, DebugLogger } from "@roo-code/core/cli"
|
||||
*
|
||||
* // Simple logging
|
||||
* debugLog("handleModeSwitch", { mode: newMode, configId })
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue