# Dot AI Write Docs

> Write documentation with real, validated examples. Executes commands through the user to capture actual output. Use for any new documentation or major doc updates.

- Skill: `vfarcic-dot-ai/dot-ai-write-docs` (Agent Skill)
- Install (CLI): `npx skillmds add vfarcic-dot-ai/dot-ai-write-docs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vfarcic-dot-ai/dot-ai-write-docs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: vfarcic (https://skillmd.com/u/vfarcic-dot-ai)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/vfarcic-dot-ai/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**
   ```bash
   kind delete cluster --name dot-test 2>/dev/null || true
   rm -f ./kubeconfig.yaml
   ```

2. **Create fresh Kind cluster with local kubeconfig**
   ```bash
   kind create cluster --name dot-test --kubeconfig ./kubeconfig.yaml
   export KUBECONFIG=./kubeconfig.yaml
   ```

3. **Install prerequisites (ingress controller)**
   ```bash
   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:
   ```bash
   # 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:
   ```bash
   --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:
```text
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:**
```text
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:**
```text
Please ask: "Show dot-ai status"

Share what you see for the Vector DB collections.
```

**For bash commands (run directly, not delegated to user):**
```bash
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/`