Dot AI Write Docs

Write Documentation

Write accurate, user-focused documentation with real examples by executing operations through the user.

Principles

1. Execute-then-document: Never write examples without real output
2. Chunk-by-chunk: Write one section at a time, get confirmation before proceeding
3. User-focused: Write for users, not developers
4. Validate prerequisites: Run setup steps from existing docs to verify they work
5. Claude runs infrastructure, user runs MCP: Claude executes all bash/infrastructure commands. Only ask user for MCP client interactions (the actual user-facing examples).
6. Fix docs when broken: If existing docs don't work during setup, STOP and discuss updating those docs before proceeding.

Workflow

Step 1: Identify the Documentation Target

Ask the user what documentation to write. Options:

• New feature guide (e.g., "knowledge base guide")
• Update existing guide
• API reference
• Setup/configuration guide

Step 2: Fresh Environment Setup

ALWAYS start with a clean test cluster to ensure reproducible documentation.

Follow the actual docs (docs/setup/mcp-setup.md) - this validates they work.

Claude executes all infrastructure steps directly using Bash tool:

1. Tear down existing test cluster if present

   kind delete cluster --name dot-test 2>/dev/null || true
   rm -f ./kubeconfig.yaml
   

2. Create fresh Kind cluster with local kubeconfig

   kind create cluster --name dot-test --kubeconfig ./kubeconfig.yaml
   export KUBECONFIG=./kubeconfig.yaml
   

3. Install prerequisites (ingress controller)

   KUBECONFIG=./kubeconfig.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml
   # Wait for ingress to be ready
   KUBECONFIG=./kubeconfig.yaml kubectl wait --namespace ingress-nginx --for=condition=ready pod --selector=app.kubernetes.io/component=controller --timeout=300s
   

4. Follow docs/setup/mcp-setup.md (skip controller if not needed for the feature)

   • Step 1: Set environment variables (use existing API keys from env)
   • Step 2: Install controller via Helm (skip if feature doesn't need it)
   • Step 3: Install MCP server via Helm
   • Step 4: Tell user to configure MCP client
   • Step 5: Tell user to verify with "Show dot-ai status"

5. For unreleased features: Build and use local images

   If documenting a feature not yet in published charts:

   # Build MCP server image
   npm run build
   docker build -t dot-ai:test .
   kind load docker-image dot-ai:test --name dot-test
   
   # Build agentic-tools plugin image
   docker build -t dot-ai-agentic-tools:test ./packages/agentic-tools
   kind load docker-image dot-ai-agentic-tools:test --name dot-test
   

   Add these flags to helm install:

   --set image.repository=dot-ai \
   --set image.tag=test \
   --set image.pullPolicy=Never \
   --set plugins.agentic-tools.image.repository=dot-ai-agentic-tools \
   --set plugins.agentic-tools.image.tag=test \
   --set plugins.agentic-tools.image.pullPolicy=Never
   

IMPORTANT: Always use KUBECONFIG=./kubeconfig.yaml for all kubectl/helm commands.

If any step fails or doesn't match existing docs: STOP and discuss whether to update those docs before proceeding.

Why fresh cluster? Ensures documentation examples work from a known clean state and validates setup docs.

Step 3: Outline the Documentation

Present an outline of sections to write. Example:

1. Overview (what it does, when to use it)
2. Prerequisites
3. Basic Usage (with real examples)
4. Advanced Features
5. API Reference
6. Troubleshooting
7. Next Steps

Get user confirmation on the outline before proceeding.

Step 4: Write Chunk-by-Chunk

🚨 CRITICAL: One section at a time. NEVER write multiple sections or the whole doc at once.

For each section:

1. Execute first — Run every command or ask user to run every MCP interaction that will appear in this section. Do this BEFORE writing any documentation prose.
   • Bash commands: Claude runs these directly using Bash tool
   • MCP interactions: Ask user to send intent and share output (these are the user-facing examples we're documenting)
2. Wait for output — For MCP interactions, user shares the actual output. For bash commands, capture the real output.
3. Write and apply the chunk immediately — Write the documentation section using real output and apply the edit directly (Write or Edit tool). Do NOT ask for permission — the user will cancel the edit if they want changes. Do NOT show the markdown in a code block and ask "should I write this?" — just write it.
4. Proceed to next section — Move to the next section and repeat.

Key distinction: Infrastructure/setup = Claude runs it. User-facing MCP examples = User runs it and shares output.

NEVER do these:

• ❌ Write the entire document in one go
• ❌ Write multiple sections before getting confirmation
• ❌ Show proposed markdown and ask "want me to write this?"
• ❌ Write examples without executing the commands first
• ❌ Skip execution for "simple" or "standard" commands — validate everything

Step 5: Cross-Reference Check

After all sections are written:

• Verify internal links work
• Check links to other docs exist
• Update mcp-tools-overview.md if adding a new tool guide
• Update any index pages

Step 6: Final Review

Tell the user: "Documentation complete. Please review the full file and let me know if any adjustments are needed."

Example Execution Request Formats

For MCP tool operations:

Please send this intent to your MCP client:
"Ingest this document into the knowledge base: [content] with URI: [url]"

Share the response you receive.

For status checks:

Please ask: "Show dot-ai status"

Share what you see for the Vector DB collections.

For bash commands (run directly, not delegated to user):

KUBECONFIG=./kubeconfig.yaml kubectl get pods --namespace dot-ai

Important Rules

• Never invent output - Always use real responses from the user
• Never skip validation - Every example must be executed first
• Keep sections small - One concept per chunk for easy review
• Use user language - Avoid internal/developer terminology
• Include error cases - Document what happens when things go wrong
• Full flags in commands - Always use long-form flags (e.g., --filename not -f, --namespace not -n, --output not -o). Full flags are more self-documenting for users unfamiliar with the tools.

File Locations

• Feature guides: docs/guides/mcp-*-guide.md
• Setup guides: docs/setup/*.md
• Tool overview: docs/guides/mcp-tools-overview.md
• Images: docs/img/