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)

   kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml
   # Wait for ingress to be ready
   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

For each section:

1. Propose the section content – Brief description of what this section covers
2. Execute or request execution:
   • 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)
3. Wait for output – For MCP interactions, user shares the actual output
4. Write the chunk – Create the documentation section using real output
5. Apply the edit – Use Edit tool to add to the doc file
6. Proceed to next – Move to the next section

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

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:

Please run:
kubectl get pods -n dot-ai

Share the output.

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

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/