Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
antinomyhq avatar

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)
At a glance

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
From the docs

What debug-cli says it does

This skill provides a systematic workflow for debugging and verifying changes to the forge CLI application.
SKILL.md
Never commit**: This is for debugging only - don't commit changes
SKILL.md
npx skills add https://github.com/antinomyhq/forge --skill debug-cli

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs61
repo stars7.5k
Last updatedAugust 5, 2026
Repositoryantinomyhq/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

SKILL.mdMarkdownGitHub ↗

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 build

Never 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] --help

3. 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.json

5. 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 conversation

Why 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: dump automatically creates timestamped files (no > needed)
  • HTML exports: Use --html flag for human-readable conversation views
  • Use relative paths: Binary is at ./target/debug/forge from project root
  • Check exit codes: Use echo $? to verify exit codes
  • Watch for warnings: Build warnings often indicate issues

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.

Debuggingbackenddevops

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.