
Debug Cli
- 61 installs
- 7.5k repo stars
- Updated August 5, 2026
- antinomyhq/forge
Debug-cli is a Forge skill providing a systematic workflow to debug, verify, and extend the code-forge CLI application's commands, argument parsing, and behavior.
About
Debug-cli provides a systematic workflow for debugging and verifying changes to the code-forge CLI application. It builds in debug mode, checks the latest --help, tests tasks non-interactively with the -p flag, and clones conversations before reproducing bugs. A developer uses it to debug, modify, or extend the forge CLI's commands and behavior.
- Systematic workflow to debug and verify changes to the forge CLI
- Build in debug mode, check --help, test tasks with the -p flag
- Clone conversations before reproducing bugs to preserve original evidence; never commit
Debug Cli by the numbers
- 61 all-time installs (skills.sh)
- Ranked #291 of 596 Debugging skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
debug-cli capabilities & compatibility
Free skill; requires the forge Rust source and cargo to build in debug mode.
- Capabilities
- cli debugging
- Use cases
- debugging · testing
- Pricing
- Free
What debug-cli says it does
This skill provides a systematic workflow for debugging and verifying changes to the forge CLI application.
Never commit**: This is for debugging only - don't commit changes
npx skills add https://github.com/antinomyhq/forge --skill debug-cliAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 61 |
|---|---|
| repo stars | ★ 7.5k |
| Last updated | August 5, 2026 |
| Repository | antinomyhq/forge ↗ |
What it does
Debug and verify forge CLI changes by building in debug mode, checking help, and testing tasks with the -p flag.
Who is it for?
Developers debugging, modifying, or extending the code-forge CLI's commands and behavior.
Skip if: Users not working on the forge CLI source, or workflows needing committed changes (this is debug-only).
When should I use this skill?
Users need to debug, modify, or extend the code-forge application's CLI commands, argument parsing, or CLI behavior.
What you get
A verified forge CLI change, tested via debug builds, --help checks, and -p task runs without committing.
- Verified forge CLI change (debugging only, no commits)
By the numbers
- 4 core principles including 'Never commit'
- Tests via cargo build (debug) and the -p flag
Files
CLI Debug Skill
This skill provides a systematic workflow for debugging and verifying changes to the forge CLI application.
Core Principles
1. Always get latest docs first: Run --help to see current commands and options 2. Use `-p` for testing: Test forge by giving it tasks with the -p flag 3. Never commit: This is for debugging only - don't commit changes 4. Clone conversations: When debugging conversation bugs, clone the source conversation before reproducing
Workflow
1. Build the Application
Always build in debug mode after making changes:
cargo buildNever use cargo build --release for debugging - it's significantly slower and unnecessary for verification.
2. Get Latest Documentation
Always start by checking the latest help to understand current commands and options:
# Main help - do this first
./target/debug/forge --help
# Command-specific help
./target/debug/forge [COMMAND] --help
# Subcommand help
./target/debug/forge [COMMAND] [SUBCOMMAND] --help3. Test with -p Flag
Use the -p flag to give forge a task to complete without interactive mode:
# Test with a simple prompt
./target/debug/forge -p "create a hello world rust program"
# Test with specific functionality
./target/debug/forge -p "read the README.md file and summarize it"
# Test with complex tasks
./target/debug/forge -p "analyze the code structure and suggest improvements"4. Debug with Conversation Dumps
When debugging prompts or conversation issues, use conversation dump to export conversations. The command automatically creates a timestamped file:
# Dump conversation as JSON (creates: YYYY-MM-DD_HH-MM-SS-dump.json)
./target/debug/forge conversation dump <conversation-id>
# Export as HTML for human-readable format (creates: YYYY-MM-DD_HH-MM-SS-dump.html)
./target/debug/forge conversation dump --html <conversation-id>
# Use dumped JSON to reproduce issues
./target/debug/forge --conversation 2025-11-23_12-28-52-dump.json5. Clone Before Reproducing Bugs
Critical: When a user provides a conversation with a bug, always clone it first:
# Clone the conversation
./target/debug/forge conversation clone <source-conversation-id>
# This creates a new conversation ID - use that for testing
./target/debug/forge --conversation-id <new-cloned-id>
# Keep cloning the source until the fix is verified
# Never modify the original conversationWhy clone?
- Preserves original bug evidence
- Allows multiple reproduction attempts
- Enables A/B testing of fixes
- Keeps source conversation clean
Common Testing Patterns
Test New Features
# Build and test new command
cargo build
./target/debug/forge --help # Verify new command appears
./target/debug/forge new-command --help # Check command docs
./target/debug/forge -p "test the new feature"Reproduce Reported Bugs
# 1. Dump the conversation (creates timestamped JSON file)
./target/debug/forge conversation dump <bug-conversation-id>
# 2. Clone it for testing (preserves original)
./target/debug/forge conversation clone <bug-conversation-id>
# 3. Reproduce with the cloned conversation
./target/debug/forge --conversation-id <cloned-id> -p "reproduce the issue"
# 4. After fix, verify with new clone
./target/debug/forge conversation clone <bug-conversation-id>
./target/debug/forge --conversation-id <new-clone-id> -p "verify fix"Test Edge Cases
# Test with missing arguments
./target/debug/forge command
# Test with invalid input
./target/debug/forge -p "invalid task with special chars: <>|&"
# Test with boundary values
./target/debug/forge -p "create a file with a very long name..."Debug Prompt Optimization
# 1. Dump conversation to analyze prompts (creates timestamped JSON)
./target/debug/forge conversation dump <id>
# 2. Review the conversation structure
cat 2025-11-23_12-28-52-dump.json | jq '.messages[] | {role, content}'
# 3. Export as HTML for easier reading
./target/debug/forge conversation dump --html <id>
# 4. Test modified prompts
./target/debug/forge -p "your optimized prompt here"Integration with Development Workflow
After Code Changes
1. Build: cargo build 2. Docs: ./target/debug/forge --help (verify documentation) 3. Test: ./target/debug/forge -p "relevant task" 4. Verify: Check output matches expectations
Debugging a Bug Report
1. Clone: ./target/debug/forge conversation clone <source-id> 2. Build: cargo build (with potential fixes) 3. Test: ./target/debug/forge --conversation-id <cloned-id> -p "reproduce" 4. Iterate: Repeat until verified 5. Never commit during debugging - only after full verification
Quick Reference
# Standard debug workflow
cargo build
./target/debug/forge --help # Always check docs first
./target/debug/forge -p "your test task"
# Dump conversation (creates timestamped file)
./target/debug/forge conversation dump <id>
# Output: 2025-11-23_12-28-52-dump.json
# Export as HTML for review
./target/debug/forge conversation dump --html <id>
# Output: 2025-11-23_12-28-52-dump.html
# Use dumped conversation
./target/debug/forge --conversation 2025-11-23_12-28-52-dump.json
# Clone and test bug
./target/debug/forge conversation clone <source-id>
./target/debug/forge --conversation-id <cloned-id> -p "reproduce bug"
# Debug prompts with jq (use actual filename)
cat 2025-11-23_12-28-52-dump.json | jq '.messages[] | {role, content}'
# Test with verbose output
./target/debug/forge --verbose -p "test task"Tips
- Always `--help` first: Get latest docs before testing
- Use `-p` for testing: Don't test interactively, use prompts
- Clone conversations: Never modify original bug conversations
- Never commit: This is for debugging only
- Dump creates files:
dumpautomatically creates timestamped files (no>needed) - HTML exports: Use
--htmlflag for human-readable conversation views - Use relative paths: Binary is at
./target/debug/forgefrom project root - Check exit codes: Use
echo $?to verify exit codes - Watch for warnings: Build warnings often indicate issues
Scripts
This directory contains helper scripts for CLI debugging and testing.
test_cli.sh
Basic smoke test script that:
- Builds the forge CLI
- Tests main help command
- Tests version command
- Tests help for various subcommands
Usage:
./scripts/test_cli.sh#!/bin/bash
# Smoke test script for verifying forge CLI functionality
# Usage: ./scripts/test_cli.sh
set -e # Exit on error
echo "=== Building forge CLI ==="
cargo build
echo ""
echo "=== Step 1: Get latest documentation ==="
./target/debug/forge --help
echo ""
echo "=== Step 2: Test with -p flag ==="
./target/debug/forge -p "echo 'CLI test successful'" || echo "Note: -p test may require valid context"
echo ""
echo "=== Step 3: Verify subcommand help ==="
./target/debug/forge list --help
./target/debug/forge conversation --help
./target/debug/forge config --help
echo ""
echo "=== Step 4: Test conversation commands ==="
./target/debug/forge conversation list || echo "No conversations yet (expected)"
echo ""
echo "✅ All smoke tests passed!"
echo ""
echo "Next steps:"
echo " 1. Always run --help first to get latest docs"
echo " 2. Test features with -p flag: ./target/debug/forge -p 'your task'"
echo " 3. Clone conversations before debugging: forge conversation clone <id>"
echo " 4. Never commit during debugging"
Related skills
FAQ
Which build mode should be used?
Always build in debug mode with cargo build; never use cargo build --release for debugging as it is significantly slower.
Why clone a conversation before reproducing a bug?
Cloning preserves original bug evidence, allows multiple reproduction attempts, and keeps the source conversation clean.