377 lines
12 KiB
Markdown
377 lines
12 KiB
Markdown
# Infinite Agentic Loop Variant Specification
|
|
|
|
## Core Challenge
|
|
|
|
Create a **complete, self-contained infinite agentic loop repository** that implements a novel variation or enhancement of the core infinite loop pattern. Each iteration should be a fully functional Claude Code project that can orchestrate parallel agents to generate iterative content.
|
|
|
|
## Output Requirements
|
|
|
|
**Directory Naming**: `infinite_variant_[iteration_number]/`
|
|
|
|
**Complete Repository Structure**:
|
|
```
|
|
infinite_variant_[iteration_number]/
|
|
├── .claude/
|
|
│ ├── commands/
|
|
│ │ ├── infinite.md # Main orchestration command
|
|
│ │ ├── [variant-specific].md # Additional commands
|
|
│ │ └── ...
|
|
│ ├── settings.json # Permissions and configuration
|
|
│ └── [state/ or config/] # Optional: state management
|
|
├── specs/
|
|
│ ├── example_spec.md # Example specification
|
|
│ ├── [variant]_spec.md # Variant-specific specs
|
|
│ └── [url_strategy.json] # Optional: URL strategies
|
|
├── README.md # Clear documentation
|
|
├── CLAUDE.md # Project instructions for Claude Code
|
|
├── [auxiliary files] # Scripts, validators, helpers
|
|
└── [example_output/] # Optional: demo output
|
|
|
|
TOTAL: Complete working repository (15-30 files typical)
|
|
```
|
|
|
|
**File Naming**:
|
|
- Directory: `infinite_variant_[number]` (e.g., `infinite_variant_1`)
|
|
- Internal files follow standard conventions
|
|
|
|
## Innovation Dimensions
|
|
|
|
Each variant should explore one or more enhancement vectors:
|
|
|
|
### **Architectural Innovations**
|
|
- **Modular Command Composition**: Reusable command fragments
|
|
- **State Management Systems**: JSON-based tracking, persistence
|
|
- **Configuration-Driven Orchestration**: External config files
|
|
- **Pluggable Agent Templates**: Parameterized task patterns
|
|
- **Multi-Stage Pipelines**: Generation → Validation → Synthesis
|
|
- **Hierarchical Agent Systems**: Meta-agents coordinating sub-agents
|
|
|
|
### **Quality & Intelligence**
|
|
- **Automated Evaluation**: Scoring, ranking, quality metrics
|
|
- **Cross-Iteration Learning**: Pattern synthesis across waves
|
|
- **Adaptive Orchestration**: Dynamic batch sizing, difficulty adjustment
|
|
- **Self-Improvement Loops**: Variants that evolve their own commands
|
|
- **Quality Feedback Systems**: Results inform next generation strategy
|
|
- **A/B Testing Frameworks**: Multiple strategies compared automatically
|
|
|
|
### **Developer Experience**
|
|
- **Rich Utility Commands**: Analysis, validation, debugging tools
|
|
- **Interactive Configuration**: Wizard-style setup commands
|
|
- **Comprehensive Documentation**: Guides, examples, tutorials
|
|
- **Debugging & Monitoring**: Progress tracking, error reporting
|
|
- **Template Libraries**: Quick-start templates for common patterns
|
|
- **Visual Progress Indicators**: Dashboard generation, status reports
|
|
|
|
### **Specialized Applications**
|
|
- **Domain-Specific Variants**: Code generation, documentation, testing
|
|
- **Multi-Modal Content**: Images, audio, video integration
|
|
- **Collaborative Modes**: Team-based generation workflows
|
|
- **Production-Ready Patterns**: Error handling, logging, recovery
|
|
- **Research Oriented**: Experiment tracking, hypothesis testing
|
|
- **Educational Focus**: Learning progressions, concept building
|
|
|
|
### **Meta-Level Capabilities**
|
|
- **Self-Documenting**: Generates its own documentation
|
|
- **Self-Testing**: Validates its own outputs
|
|
- **Self-Extending**: Can generate new specs and commands
|
|
- **Variant Generation**: Can spawn new variants of itself
|
|
- **Pattern Discovery**: Analyzes successful patterns
|
|
- **Capability Mapping**: Documents what it can/cannot do
|
|
|
|
## Content Requirements
|
|
|
|
### **1. .claude/commands/ (Required)**
|
|
|
|
**Main Orchestration Command** (`infinite.md` or variant name):
|
|
```markdown
|
|
**[VARIANT NAME] INFINITE AGENTIC LOOP**
|
|
|
|
[Clear description of this variant's innovation]
|
|
|
|
**PHASE 0: [VARIANT-SPECIFIC INITIALIZATION]**
|
|
[Any setup unique to this variant]
|
|
|
|
**PHASE 1: SPECIFICATION ANALYSIS**
|
|
[How this variant reads and processes specs]
|
|
|
|
**PHASE 2: [VARIANT-SPECIFIC PREPARATION]**
|
|
[Directory recon, state loading, config reading, etc.]
|
|
|
|
**PHASE 3: ITERATION STRATEGY**
|
|
[Planning approach unique to this variant]
|
|
|
|
**PHASE 4: PARALLEL AGENT COORDINATION**
|
|
[Agent deployment strategy with variant enhancements]
|
|
|
|
**PHASE 5: [VARIANT-SPECIFIC POST-PROCESSING]**
|
|
[Quality checks, synthesis, evaluation, etc.]
|
|
|
|
**EXECUTION PRINCIPLES:**
|
|
[How this variant improves on the base pattern]
|
|
|
|
**ULTRA-THINKING DIRECTIVE:**
|
|
[Considerations specific to this variant]
|
|
```
|
|
|
|
**Utility Commands** (recommended, 2-5 commands):
|
|
- Analysis commands (`/analyze`, `/evaluate`)
|
|
- Validation commands (`/validate-spec`, `/test-output`)
|
|
- Setup commands (`/init`, `/configure`)
|
|
- Debugging commands (`/debug`, `/status`)
|
|
|
|
**settings.json** (required):
|
|
```json
|
|
{
|
|
"allowedTools": ["Write", "Edit", "Read", "Bash", "Task"],
|
|
"customInstructions": "[Variant-specific guidance]"
|
|
}
|
|
```
|
|
|
|
### **2. specs/ (Required)**
|
|
|
|
**Example Specification** (at least 1):
|
|
- Demonstrates how to write specs for this variant
|
|
- Shows all features and capabilities
|
|
- Includes quality standards
|
|
- Documents expected output format
|
|
|
|
**Variant-Specific Templates** (optional):
|
|
- Specialized specs for this variant's domain
|
|
- Progressive difficulty examples
|
|
- URL strategy files if web-enhanced
|
|
|
|
### **3. Documentation (Required)**
|
|
|
|
**README.md**:
|
|
```markdown
|
|
# [Variant Name] - Infinite Agentic Loop
|
|
|
|
## Innovation
|
|
[What makes this variant unique]
|
|
|
|
## Quick Start
|
|
[How to use this variant immediately]
|
|
|
|
## Architecture
|
|
[Key components and how they work]
|
|
|
|
## Usage Examples
|
|
[Concrete examples with commands]
|
|
|
|
## Comparison
|
|
[How this differs from base infinite loop]
|
|
|
|
## Extension Points
|
|
[How to customize or extend this variant]
|
|
```
|
|
|
|
**CLAUDE.md**:
|
|
```markdown
|
|
# Project Overview
|
|
[What this repository does]
|
|
|
|
## Key Commands
|
|
[All slash commands available]
|
|
|
|
## Architecture
|
|
[Command system, specs, auxiliary files]
|
|
|
|
## Best Practices
|
|
[How to use this variant effectively]
|
|
```
|
|
|
|
### **4. Auxiliary Files (Optional but Recommended)**
|
|
|
|
Examples based on variant:
|
|
- Validation scripts (`.sh`, `.py`)
|
|
- Configuration templates (`.json`, `.yaml`)
|
|
- State management utilities
|
|
- Analysis tools
|
|
- Template generators
|
|
- Quality checkers
|
|
- Pattern extractors
|
|
|
|
### **5. Example Output (Optional but Valuable)**
|
|
|
|
- `example_output/` directory with 2-3 sample generations
|
|
- Demonstrates the variant's capabilities
|
|
- Shows quality standards in practice
|
|
- Helps users understand expectations
|
|
|
|
## Quality Standards
|
|
|
|
### **Completeness**
|
|
- Can be cloned and used immediately
|
|
- All required files present
|
|
- No broken references or missing dependencies
|
|
- Clear, actionable documentation
|
|
|
|
### **Functionality**
|
|
- Commands actually work as documented
|
|
- Specs are valid and produce good results
|
|
- Auxiliary tools function correctly
|
|
- Error cases handled gracefully
|
|
|
|
### **Innovation Value**
|
|
- Genuinely improves on base infinite loop
|
|
- Solves real problems or adds meaningful capabilities
|
|
- Novel approach, not superficial variation
|
|
- Demonstrates clear use cases
|
|
|
|
### **Documentation Quality**
|
|
- README explains the innovation clearly
|
|
- Usage examples are concrete and helpful
|
|
- CLAUDE.md guides Claude Code effectively
|
|
- Code comments explain non-obvious logic
|
|
|
|
### **Code Quality**
|
|
- Well-structured markdown commands
|
|
- Clear variable naming and flow
|
|
- Proper error handling
|
|
- Reusable patterns
|
|
|
|
### **Usability**
|
|
- Easy to understand and get started
|
|
- Good defaults with customization options
|
|
- Helpful error messages
|
|
- Progressive disclosure of complexity
|
|
|
|
## Web Learning Integration
|
|
|
|
Each iteration should research and incorporate web knowledge about:
|
|
|
|
### **Agent Orchestration Patterns**
|
|
- Multi-agent system design
|
|
- Coordination strategies
|
|
- Parallel execution patterns
|
|
- State management in distributed systems
|
|
- Error handling and recovery
|
|
|
|
### **Prompt Engineering**
|
|
- Meta-prompting techniques
|
|
- Chain-of-thought patterns
|
|
- Role-based prompting
|
|
- Context optimization
|
|
- Self-reflection prompts
|
|
|
|
### **Claude Code Best Practices**
|
|
- Slash command design
|
|
- Tool usage patterns
|
|
- Project memory management
|
|
- MCP integration
|
|
- Workflow optimization
|
|
|
|
### **Software Architecture**
|
|
- Modular design patterns
|
|
- Configuration management
|
|
- Plugin architectures
|
|
- Template systems
|
|
- Testing frameworks
|
|
|
|
### **Domain-Specific Knowledge**
|
|
- Based on variant focus (code gen, docs, testing, etc.)
|
|
- Relevant frameworks and tools
|
|
- Industry best practices
|
|
- Common patterns and anti-patterns
|
|
|
|
## Iteration Evolution Strategy
|
|
|
|
### **Foundation (Iterations 1-2)**
|
|
- Core architectural innovations
|
|
- Single clear improvement over base
|
|
- Well-documented and tested
|
|
- Focus: Reliability and usability
|
|
|
|
### **Intermediate (Iterations 3-5)**
|
|
- Multi-dimensional enhancements
|
|
- Combination of features
|
|
- Advanced capabilities
|
|
- Focus: Power and flexibility
|
|
|
|
### **Advanced (Iterations 6-7)**
|
|
- Meta-level capabilities
|
|
- Self-modifying or self-improving
|
|
- Novel paradigms
|
|
- Focus: Innovation and research
|
|
|
|
## Success Criteria
|
|
|
|
An excellent infinite loop variant:
|
|
|
|
1. **Works Out of Box**: Clone, run command, get results
|
|
2. **Solves Real Problem**: Addresses actual pain point or limitation
|
|
3. **Well Documented**: Clear README, CLAUDE.md, comments
|
|
4. **Demonstrates Innovation**: Shows unique approach with evidence
|
|
5. **Includes Examples**: Specs and outputs show capabilities
|
|
6. **Production Quality**: Error handling, validation, robustness
|
|
7. **Extensible**: Easy to customize and build upon
|
|
8. **Learns from Web**: Incorporates research into design
|
|
|
|
## Web Research Directive
|
|
|
|
Before generating each variant:
|
|
|
|
**Research Focus:**
|
|
- How do other multi-agent systems handle [variant focus]?
|
|
- What prompt patterns enable [capability]?
|
|
- How do production systems implement [feature]?
|
|
- What are best practices for [architecture choice]?
|
|
|
|
**Application Strategy:**
|
|
- Extract 2-3 specific techniques from web source
|
|
- Adapt to infinite loop context
|
|
- Document source and learning in README
|
|
- Demonstrate technique in implementation
|
|
|
|
**Knowledge Synthesis:**
|
|
- Combine web learnings with base infinite loop pattern
|
|
- Balance innovation with proven practices
|
|
- Cite sources where applicable
|
|
- Show clear improvement from research
|
|
|
|
## Ultra-Thinking Directive
|
|
|
|
Before generating each variant, deeply consider:
|
|
|
|
**Innovation Selection:**
|
|
- Which enhancement dimension has the most impact?
|
|
- What problem does this variant solve?
|
|
- How does this differ meaningfully from base pattern?
|
|
- What makes this variant worth creating?
|
|
|
|
**Architecture Decisions:**
|
|
- How should this variant structure its commands?
|
|
- What auxiliary files would add real value?
|
|
- How can this be both powerful and usable?
|
|
- What's the right balance of complexity?
|
|
|
|
**Web Learning Strategy:**
|
|
- What knowledge would most benefit this variant?
|
|
- Which sources provide actionable techniques?
|
|
- How to synthesize research with implementation?
|
|
- What proves the web learning was valuable?
|
|
|
|
**User Experience:**
|
|
- How will users discover this variant's value?
|
|
- What makes it easy to get started?
|
|
- How to handle errors gracefully?
|
|
- What documentation is essential vs. nice-to-have?
|
|
|
|
**Quality & Testing:**
|
|
- How to verify this variant works correctly?
|
|
- What examples demonstrate capabilities best?
|
|
- How to ensure maintainability?
|
|
- What could go wrong and how to prevent it?
|
|
|
|
**Generate variants that are:**
|
|
- **Immediately Useful**: Solve real problems from day one
|
|
- **Well Architected**: Clean, modular, extensible design
|
|
- **Thoroughly Documented**: Users can succeed without guessing
|
|
- **Genuinely Innovative**: Meaningful improvements over base
|
|
- **Production Ready**: Robust error handling and edge cases
|
|
- **Self-Contained**: Everything needed is included
|
|
- **Web-Enhanced**: Demonstrates learning from research
|
|
- **Evolvable**: Can be extended and customized easily
|
|
|
|
Each variant should feel like a polished open-source project ready for others to use and learn from.
|