# Doc Accurate Codegen

> Generate code that references actual documentation, preventing hallucination bugs. ALWAYS loads docs first, validates against API signatures, and verifies correctness. Use for ANY code generation, API usage, or configuration creation.

- Skill: `modbender/doc-accurate-codegen` (Agent Skill)
- Install (CLI): `npx skillmds@latest add modbender/doc-accurate-codegen`
- Raw SKILL.md: https://api.skillmd.com/api/skills/modbender/doc-accurate-codegen/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: modbender (https://skillmd.com/u/modbender)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/modbender/doc-accurate-codegen

---


# Documentation-Accurate Code Generation

**CRITICAL**: This skill prevents LLM hallucination by enforcing documentation reference.

## When to Use
- **ALWAYS** when generating code
- **ALWAYS** when using APIs
- **ALWAYS** when creating configurations
- **ALWAYS** when implementing features

## Core Philosophy

**NEVER generate code from memory. ALWAYS reference documentation.**

### The Problem
- LLMs hallucinate APIs that don't exist
- Methods get renamed or removed
- Parameters change or get deprecated
- Return types shift unexpectedly
- Configuration formats evolve

### The Solution
1. **Load documentation FIRST** — Before writing any code
2. **Extract API signatures** — Get actual method signatures
3. **Generate from docs** — Use real API data
4. **Validate against docs** — Check generated code matches
5. **Reference tracking** — Document which docs were used

## Workflow

```
1. IDENTIFY → What code/API/tool is needed?
2. LOCATE → Find documentation source
3. LOAD → Fetch and parse documentation
4. EXTRACT → Pull API signatures, parameters, examples
5. GENERATE → Create code using actual docs
6. VALIDATE → Check code matches documentation
7. REFERENCE → Track what docs were used
```

## Documentation Sources

### 1. OpenClaw Internal Docs
- Location: `C:\Users\clipp\AppData\Roaming\npm\node_modules\openclaw\docs`
- Access: `read` tool
- Use: For OpenClaw-specific APIs, tools, skills

### 2. Tool Documentation
- Tool help: `--help` flags
- Man pages: `man <command>`
- Official docs: Use `web_fetch` to get docs

### 3. API Documentation
- Official docs: Use `web_fetch`
- OpenAPI specs: Parse and reference
- Package docs: npm, pip, cargo docs

### 4. Code Examples
- Existing code: Read similar implementations
- Tests: Check test files for usage patterns
- Examples: Find working code samples

## Process for Code Generation

### Step 1: Documentation Discovery
```bash
# For OpenClaw tools
read("openclaw-docs-path/tool-name.md")

# For external tools
web_fetch("https://docs.tool.com/api")

# For local tools
exec("tool --help")
```

### Step 2: API Signature Extraction
```markdown
# Extract:
- Method names
- Parameters (names, types, required/optional)
- Return types
- Error handling
- Examples
- Version information
```

### Step 3: Code Generation
```python
# Generate code using actual API data
def generate_from_docs(api_docs):
    # Use real method names
    # Use real parameter names
    # Use real return types
    # Include error handling from docs
    # Add docstrings from docs
    pass
```

### Step 4: Validation
```python
def validate_against_docs(code, api_docs):
    # Check method names match
    # Check parameter names match
    # Check types match
    # Check return types match
    # Verify no hallucinated methods
    pass
```

## Quick Actions

- `codegen <api>` — Generate code with doc reference
- `validate <code>` — Check code against docs
- `doc-lookup <api>` — Load and display documentation
- `api-extract <tool>` — Extract API signatures

## Usage Examples

```
"Generate code to use the OpenClaw sessions_spawn tool"
# Process: Load docs → Extract API → Generate → Validate

"Create a Python script using the requests library"
# Process: Fetch requests docs → Extract API → Generate → Validate

"Write configuration for OpenClaw channels"
# Process: Load config docs → Extract format → Generate → Validate
```

## Validation Rules

### 1. Method Name Validation
- Check method exists in docs
- Verify spelling matches exactly
- Confirm method is not deprecated

### 2. Parameter Validation
- All required parameters present
- Parameter names match docs exactly
- Parameter types match docs
- Optional parameters marked correctly

### 3. Return Type Validation
- Return type matches docs
- Error types match docs
- Edge cases handled

### 4. Configuration Validation
- Keys match documentation
- Value types match schema
- Required fields present
- Format matches specification

## Error Prevention

### Common Hallucination Patterns
1. **Non-existent methods** — Methods that don't exist
2. **Wrong parameter names** — Hallucinated parameter names
3. **Wrong types** — Incorrect parameter/return types
4. **Missing error handling** — Ignoring documented errors
5. **Wrong configuration format** — Incorrect config structure

### Prevention Strategies
1. **Always load docs first** — Never generate from memory
2. **Extract actual signatures** — Don't guess API shape
3. **Validate everything** — Check against real docs
4. **Reference tracking** — Know which docs were used
5. **Test with real APIs** — Verify code actually works

## Integration Points

### With Other Skills
- **Coding skill**: Use this for doc-accurate code
- **Self-evolution**: Update skills with doc validation
- **Content generation**: Generate accurate code examples
- **Research**: Research APIs from actual docs

### With OpenClaw Tools
- **read**: Load internal documentation
- **web_fetch**: Fetch external documentation
- **exec**: Run tools with `--help` for docs
- **edit/write**: Create validated code

## Reference Tracking

### Format
```markdown
# Code Generation Reference

## Generated Code
- File: path/to/file.py
- Generated: 2026-02-23
- Tool: doc-accurate-codegen

## Documentation Sources
1. OpenClaw Tool Docs: /docs/tools/exec.md
2. API Reference: https://docs.example.com/api
3. Examples: /examples/exec-usage.py

## Validation
- ✅ Method names validated
- ✅ Parameters validated
- ✅ Return types validated
- ✅ Error handling validated

## Notes
- Using exec tool with sandbox mode
- All parameters from official docs
- Error handling from API reference
```

## Output Template

When generating code, always include:

```python
# Code generated with documentation reference
# Source: [documentation URL or path]
# Validated: [timestamp]
# API Version: [version if available]

def function_name():
    """
    [Docstring from actual documentation]
    
    Source: [link to docs]
    Parameters: [from docs]
    Returns: [from docs]
    """
    # Implementation using actual API
    pass
```

## Best Practices

1. **Docs First, Always** — Never generate without loading docs
2. **Exact Matches** — Use exact names, types, formats from docs
3. **Validate Everything** — Check all generated code
4. **Track References** — Document which docs were used
5. **Test Real APIs** — Actually run the code to verify
6. **Update Regularly** — Re-check docs as APIs evolve
7. **Error Handling** — Include all documented errors
8. **Examples** — Reference working examples from docs

## Common Pitfalls

1. **Assuming API stability** — APIs change, always re-check docs
2. **Memory over docs** — Trust docs, not memory
3. **Partial loading** — Load complete documentation
4. **No validation** — Always validate generated code
5. **Missing references** — Always track doc sources

## Success Metrics

- **Hallucination rate**: 0% (all code references actual docs)
- **Validation rate**: 100% (all code validated)
- **Reference tracking**: 100% (all code has doc sources)
- **Error rate**: 0% (no API misuse)
- **Test pass rate**: 100% (all generated code works)

## Advanced Features

### 1. Automatic Doc Loading
- Detect what APIs are needed
- Automatically fetch relevant docs
- Cache for future use

### 2. API Change Detection
- Monitor docs for changes
- Alert when APIs change
- Suggest code updates

### 3. Multi-Source Validation
- Cross-reference multiple doc sources
- Detect conflicts between sources
- Use most authoritative source

### 4. Example Extraction
- Extract working examples from docs
- Adapt examples to specific needs
- Test examples before using

## Integration with OpenClaw

### Tool Documentation
```bash
# Get tool help
exec("tool --help")

# Read tool docs
read("openclaw/docs/tools/tool-name.md")

# Check tool examples
read("openclaw/examples/tool-usage.md")
```

### Skill Documentation
```bash
# Read skill docs
read("skills/skill-name/SKILL.md")

# Check skill examples
read("skills/skill-name/examples/")
```

### Configuration Documentation
```bash
# Read config docs
read("openclaw/docs/configuration.md")

# Check config examples
read("openclaw/examples/config/")
```

---

**Remember**: This skill exists because LLMs hallucinate. ALWAYS use it for code generation. The only way to prevent bugs is to reference actual documentation.