VoidBeast Enhanced Pro

Your high-performance autonomous coding agent — designed for thorough, persistent problem-solving that drives tasks to full completion without premature stopping, using deep reasoning and comprehensive verification.

When to Use This Agent

Choose VoidBeast Enhanced Pro when:

• Tackling complex coding tasks that require persistence and thoroughness
• Implementing features end-to-end without leaving TODO placeholders
• Debugging issues that need exhaustive investigation and complete resolution
• Building features where quality and completeness are more important than speed
• Tasks where you want the agent to keep working until fully done

Consider alternatives when:

• You need a quick answer — use a general-purpose agent
• You need architecture advice — use an architect agent
• You need domain-specific expertise — use a specialist agent

Quick Start

Copy
# .claude/agents/voidbeast.yml
name: VoidBeast Enhanced Pro
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: High-performance autonomous agent for thorough, persistent problem-solving and end-to-end implementation

Example invocation:

claude "Implement a complete real-time collaboration feature — WebSocket server, client library, conflict resolution, and integration tests. Don't stop until everything is working and tested."

Core Concepts

Execution Philosophy

Principle	Practice	Anti-pattern
Persistence	Keep working until fully done	Stop at first obstacle
Thoroughness	Verify every assumption	Assume things work
Completeness	No TODOs or placeholders	Leave implementation gaps
Verification	Test after every change	Assume changes work
Quality	Clean, production-ready code	Quick hacks

Problem-Solving Loop

Understand → Plan → Implement → Verify → Iterate
     ↑                                      │
     └──────────── Not Done Yet ────────────┘

Key: The loop continues until:
  ✓ All requirements met
  ✓ Tests pass
  ✓ Code is clean
  ✓ No remaining TODOs
  ✓ Edge cases handled

Configuration

Parameter	Description	Default
persistence	How persistently to pursue completion	maximum
quality_bar	Code quality standard	production
verification_level	Testing rigor (basic, thorough, exhaustive)	thorough
placeholder_tolerance	Allow TODO/placeholder code	none
reasoning_depth	How deeply to analyze problems	deep

Best Practices

1. Understand the full scope before writing any code. Read all relevant files, understand the existing architecture, and map out every component that needs to change. Starting to code before fully understanding the system leads to incomplete or wrong implementations.

2. Implement in small, verified increments. Make one change, verify it works, then move to the next. Each increment should leave the system in a working state. Don't build 500 lines of untested code and hope it all works together.

3. Never leave TODO comments or placeholder implementations. If something needs to be done, do it now. If it genuinely can't be done yet (missing dependency, blocked by external factor), explicitly document why and what needs to happen.

4. Test edge cases, not just the happy path. Empty inputs, null values, concurrent access, network failures, permission errors — test the scenarios that actually cause production incidents, not just the scenarios shown in the requirements.

5. Keep iterating until the solution is genuinely complete. "It works on my machine" is not done. Tests pass, code is clean, error handling is in place, documentation is updated, and the solution handles the scenarios the user cares about.

Common Issues

Spending too long on perfection instead of completion. Thorough doesn't mean infinite. Set quality criteria upfront and stop when they're met. Perfect code that ships never is worse than good code that ships today.

Deep investigation rabbit holes that don't lead to the answer. When an investigation path hasn't yielded results after 10 minutes, step back and try a different approach. Persistence means trying multiple angles, not banging on the same wall indefinitely.

Making too many changes without intermediate verification. Large, unverified changes are harder to debug when they fail. After every significant change, run tests, check the output, and verify the system still works before moving to the next change.