Agent skill

Doc Tester

by mitchdenny in mitchdenny/hex1b

Agent for validating Hex1b documentation against actual library behavior.

MITAuto-check passedTesting & QA

Install Doc Tester

skills CLI
$ npx skills add mitchdenny/hex1b --skill doc-tester -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install mitchdenny/hex1b doc-tester --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/mitchdenny/hex1b.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/doc-tester .claude/skills/doc-tester && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
doc-tester
GitHub stars
178
Token cost
~9.5k tokens
SKILL.md length
2,842 words
Files
2
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

Agent for validating Hex1b documentation against actual library behavior.

  • Works in 7 steps: Teaching Effectiveness → Accuracy & Correctness → Environment Preparation → …
  • Auditing documentation accuracy
  • SKILL.md covers ⚠️ CRITICAL: User-Centric…, Testing Goals, Environment Setup and Purpose, plus 5 more sections
  • Runs Shell scripts from its folder; calls dotnet; reaches api.nuget.org

What it does

Doc Tester is an agent skill from mitchdenny/hex1b. Agent for validating Hex1b documentation against actual library behavior. Use when auditing documentation accuracy, testing interactive examples, or identifying discrepancies between documentation and implementation.

Its SKILL.md is about 9.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `build-local-package.sh`).

It sits in Testing & QA. It works with Playwright. The repository describes itself as: The .NET Terminal Application Stack. The licence is MIT.

When your agent uses it

  • Auditing documentation accuracy
  • Testing interactive examples
  • Identifying discrepancies between documentation and implementation

Example prompts

  • “/doc-tester”

Requirements

  • A Bash shell

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Teaching Effectiveness
  2. Accuracy & Correctness
  3. Environment Preparation
  4. Navigate and Read Documentation (Playwright)
  5. Test Code Examples
  6. Test Interactive Demos (Playwright)
  7. Evaluate Teaching Effectiveness

What it can do on your machine

Read from SKILL.md and the folder at commit e2335bd. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships script files (Shell), which the agent can run.

    Shell commands in SKILL.md call:

    • dotnet

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • api.nuget.org

    Also links to:

    • hex1b.dev

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Doc Tester loads about 9.5k tokens when it runs. Until then it costs about 57 tokens; SKILL.md has 2,842 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~57
When it runs · the whole SKILL.md, loaded when a task matches
~9.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from mitchdenny/hex1b at commit e2335bd, republished under its MIT licence (© mitchdenny). 2,842 words, ~9,518 tokens.

Download SKILL.mdSave it as .claude/skills/doc-tester/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
doc-tester
description
Agent for validating Hex1b documentation against actual library behavior. Use when auditing documentation accuracy, testing interactive examples, or identifying discrepancies between documentation and implementation.

Documentation Tester Skill

This skill provides guidelines for AI agents to systematically validate the Hex1b documentation site against the actual behavior of the Hex1b library. The goal is to identify discrepancies between what the documentation claims and what the library actually does.

⚠️ CRITICAL: User-Centric Testing Approach

You are testing the documentation as if you were a new user learning Hex1b.

Core Principles
  1. Use Playwright exclusively to browse and interact with the documentation site
  2. Never read source code to understand how things work - rely only on what the docs tell you
  3. Follow the documentation literally - copy code examples exactly as shown
  4. Test interactive demos by actually using them in the browser
  5. Evaluate teaching effectiveness - can you learn from this documentation?
What This Means

❌ DO NOT:

  • Read src/Hex1b/*.cs files to understand widget behavior
  • Check implementation details in node or widget source
  • Look at test files to understand expected behavior
  • Use internal knowledge of the codebase

✅ DO:

  • Use Playwright MCP tools to navigate the documentation site
  • Read documentation content as displayed in the browser
  • Copy code examples and run them in test projects
  • Interact with live demos using Playwright
  • Evaluate if explanations make sense without prior knowledge
When You Get Stuck

If documentation is insufficient to proceed:

  1. Document the blocker - What were you trying to do? What information was missing?
  2. Describe the gap - What would a user need to know to succeed?
  3. Hand off to doc-writer - Create a task for the doc-writer skill to fix it
  4. Move on - Continue testing other areas

This is valuable feedback! Gaps in documentation are exactly what we're trying to find.

Testing Goals

1. Teaching Effectiveness

Can someone learn Hex1b from these docs alone?

  • Are concepts introduced in a logical order?
  • Are prerequisites clearly stated?
  • Do examples build on each other progressively?
  • Is terminology explained before being used?
  • Are common mistakes or gotchas addressed?
2. Accuracy & Correctness

Does the documentation match reality?

  • Do code examples compile and run?
  • Do interactive demos behave as described?
  • Are API signatures and parameters correct?
  • Do claimed features actually exist?
  • Are limitations and caveats documented?

Environment Setup

Local Development Stack

The doc-tester uses a local development environment for fast iteration:

  1. Aspire launches the documentation site locally
  2. Playwright browses and interacts with the site
  3. Local NuGet packages are built for testing code examples

This allows testing documentation changes before they go live.

Aspire App Model

The Hex1b workspace uses .NET Aspire to orchestrate local services. The app model in apphost.cs defines:

ResourceTypePurpose
websiteCSharpAppWebSocket backend for interactive demos (src/Hex1b.Website)
contentViteAppVitePress documentation site (src/content)

The content resource serves the documentation. Use mcp_aspire_list_resources to get the current URL.

Starting the Local Environment

⚠️ CRITICAL: Terminal Isolation

Aspire must run in an isolated background process to avoid interference with other terminal commands. When running commands in the same terminal session as Aspire, the terminal may send signals that stop Aspire unexpectedly.

Recommended approach - run Aspire with nohup:

bash
# Start Aspire in background (won't be interrupted by other commands)
cd /path/to/hex1b
nohup aspire run > /tmp/aspire.log 2>&1 &

# Wait a few seconds for startup, then check logs
sleep 10 && head -15 /tmp/aspire.log

Alternative - use isBackground: true:

When using the run_in_terminal tool, set isBackground: true for the Aspire command, then run all subsequent commands in separate terminal invocations.

Use the Aspire MCP tools to get the content URL:

# Call the MCP tool
mcp_aspire_list_resources

# Look for the content resource endpoint_urls
# Example output: http://content-hex1b.dev.localhost:1189

The URL format is typically http://content-hex1b.dev.localhost:1189 but always verify with mcp_aspire_list_resources as ports can vary.

IMPORTANT: Use the local content URL for all testing, not https://hex1b.dev

Building Local Packages

To test code examples accurately, build and use local Hex1b packages:

bash
# Run the build-local-package script in this skill directory
./.github/skills/doc-tester/build-local-package.sh

This script:

  1. Packs src/Hex1b into a local NuGet package
  2. Creates a temporary NuGet feed at .doc-tester-packages/
  3. Generates a NuGet.config for test projects

See Local Package Testing for detailed workflow.

Purpose

The doc-tester agent produces actionable feedback that can:

  1. Trigger the doc-writer skill to correct documentation inaccuracies
  2. Identify product design issues that need to be addressed in code
  3. Surface missing documentation for existing features
  4. Find dead or broken interactive examples

Scope

What to Test
AreaDescription
Conceptual accuracyDo explanations match actual implementation?
Code examplesDo code samples compile and run as described?
Interactive demosDo live terminal demos behave as documented?
API referencesAre parameter names, types, and behaviors accurate?
Navigation & linksDo internal links work? Are pages accessible?
Feature coverageAre all significant features documented?
Documentation Structure

The documentation site (served by Aspire's content resource) includes:

/                           # Landing page with feature overview
/guide/getting-started      # Getting started tutorial
/guide/first-app           # Quick start guide
/guide/widgets-and-nodes   # Core architecture concepts
/guide/layout              # Layout system
/guide/input               # Input handling
/guide/testing             # Testing guide
/guide/theming             # Theming system
/guide/widgets/            # Per-widget documentation
    text
    button
    textbox
    list
    stacks
    containers
    navigator
    ...
/deep-dives/               # Advanced topics
    reconciliation
    ...
/api/                      # API reference
/gallery                   # Examples showcase

Testing Workflow

All testing uses Playwright MCP tools to interact with the documentation site.

Phase 0: Environment Preparation
  1. Start Aspire: Run aspire run from the repository root
  2. Get content URL: Use mcp_aspire_list_resources to find the content endpoint
  3. Build local packages: Run .github/skills/doc-tester/build-local-package.sh
  4. Note the package version: The script outputs the version (e.g., 1.0.0-local.20260105120000)
Phase 1: Navigate and Read Documentation (Playwright)

Use Playwright MCP tools to browse the documentation:

# Take an accessibility snapshot to read page content
mcp_playwright_browser_snapshot

# Navigate to a page
mcp_playwright_browser_click with element="Getting Started link"

# Read interactive demos
mcp_playwright_browser_snapshot

For each documentation page:

  1. Navigate to the page using Playwright click actions
  2. Take a snapshot to read the page content
  3. Evaluate the content - Is it clear? Complete? Accurate?
  4. Note any confusion - What would a new user struggle with?
Phase 2: Test Code Examples

For each code example shown in the documentation:

  1. Copy the code exactly as shown in the browser (from snapshot)
  2. Create a test project in the workspace directory
  3. Build the code - does it compile without errors?
  4. Run and observe using TerminalMcp - does it match what the docs describe?
Step 1: Create Test Project in Workspace

Use the .doc-tester-workspace/ directory in the repository root (this is gitignored):

bash
# Create test project in the workspace (not /tmp!)
cd /path/to/hex1b
mkdir -p .doc-tester-workspace
cd .doc-tester-workspace
dotnet new console -n DocTest --force
cp ../.doc-tester-packages/NuGet.config DocTest/
cd DocTest
dotnet add package Hex1b --version 1.0.0-local.XXXXXX

# Paste the code example into Program.cs and build
dotnet build
Step 2: Run with TerminalMcp Interactive Shell

⚠️ CRITICAL: Use an interactive shell, not direct command execution

After building successfully, use TerminalMcp with an interactive shell to run and validate:

# 1. Activate terminal tools
activate_terminal_session_control_tools
activate_terminal_interaction_tools

# 2. Start an interactive bash shell (use start_pwsh_terminal on Windows)
mcp_terminal-mcp_start_bash_terminal workingDirectory="/path/to/hex1b"

# 3. Wait for shell prompt
mcp_terminal-mcp_wait_for_terminal_text text="$" timeoutSeconds=5

# 4. Navigate to the test project
mcp_terminal-mcp_send_terminal_input text="cd .doc-tester-workspace/DocTest"
mcp_terminal-mcp_send_terminal_key key="Enter"
mcp_terminal-mcp_wait_for_terminal_text text="$" timeoutSeconds=5

# 5. Run the TUI application
mcp_terminal-mcp_send_terminal_input text="dotnet run"
mcp_terminal-mcp_send_terminal_key key="Enter"

# 6. Wait for the TUI to render
mcp_terminal-mcp_wait_for_terminal_text text="Expected UI text" timeoutSeconds=15

# 7. Capture and verify the visual output (ALWAYS use both)
mcp_terminal-mcp_capture_terminal_text      # For text-based verification
mcp_terminal-mcp_capture_terminal_screenshot savePath="/path/to/hex1b/.doc-tester-workspace/screenshots/test-name-step1.svg"

# 8. Interact with the TUI (type, navigate, etc.)
mcp_terminal-mcp_send_terminal_input text="Hello"
mcp_terminal-mcp_send_terminal_key key="Tab"
mcp_terminal-mcp_send_terminal_key key="Enter"

# 9. Verify the result after interaction (ALWAYS use both)
mcp_terminal-mcp_capture_terminal_text      # Text verification
mcp_terminal-mcp_capture_terminal_screenshot savePath="/path/to/hex1b/.doc-tester-workspace/screenshots/test-name-step2.svg"

# 10. Exit the TUI (Ctrl+C) and clean up
mcp_terminal-mcp_send_terminal_key key="c" modifiers=["Ctrl"]
mcp_terminal-mcp_stop_terminal sessionId="..."
mcp_terminal-mcp_remove_session sessionId="..."

Why TerminalMcp? Standard dotnet run cannot capture TUI visual output. TerminalMcp provides a virtual terminal that captures the screen buffer, allowing you to verify:

  • The UI renders correctly (use capture_terminal_screenshot for visual analysis)
  • Text appears where expected (use capture_terminal_text for verification)
  • Interactions (typing, Tab navigation) work as documented
  • Focus states and styling change appropriately (visible in screenshots)

⚠️ CRITICAL: Always use BOTH capture_terminal_text AND capture_terminal_screenshot when testing TUI apps. Text capture verifies content, but screenshots reveal visual elements (colors, borders, focus indicators) that text alone cannot assess.

Why interactive shell? Starting dotnet run directly can fail because the PTY isn't properly initialized. Starting a shell first ensures proper environment and terminal setup.

Phase 3: Test Interactive Demos (Playwright)

Interactive demos have a "Run in browser" button. Test them:

# Click the demo button
mcp_playwright_browser_click with element="Run in browser"

# Wait for terminal to appear
mcp_playwright_browser_wait_for with text="..." 

# Take snapshot to see the demo
mcp_playwright_browser_snapshot

# Interact with the demo
mcp_playwright_browser_type with text="test input"
mcp_playwright_browser_press with key="Tab"
mcp_playwright_browser_press with key="Enter"

# Snapshot again to see results
mcp_playwright_browser_snapshot

Verify:

  • Does the demo load?
  • Does it match the code example shown?
  • Do interactions work as described?
Phase 4: Evaluate Teaching Effectiveness

As you navigate, evaluate:

  1. Concept flow - Are ideas introduced in a logical order?
  2. Prerequisites - Is prior knowledge clearly stated?
  3. Completeness - Can you accomplish tasks with just the docs?
  4. Clarity - Would a new user understand this?

When you get stuck:

  • Document what you were trying to do
  • Note what information was missing
  • This becomes a doc-writer task

Focus Area Templates

When given a focus area, use these templates to guide testing:

Widget Documentation Focus
markdown
## Widget: [WidgetName]

### Page: /guide/widgets/[widget-name]

#### Navigation (Playwright)
- [ ] Page loads successfully
- [ ] All sections visible in snapshot
- [ ] Code examples readable

#### Content Clarity
- [ ] Widget purpose is clear
- [ ] When to use this widget is explained
- [ ] Basic usage example is complete and runnable

#### Code Example Testing
- [ ] Example 1: Compiles and runs as described
- [ ] Example 2: Compiles and runs as described
- [ ] (etc.)

#### Live Demo Testing (Playwright)
- [ ] **"Run in browser" button exists** for at least one code example
- [ ] Demo loads when clicked (no 500 errors)
- [ ] Initial state matches description
- [ ] Interactions work as documented
- [ ] Demo matches the code example shown

⚠️ **CRITICAL: If "Run in browser" button is MISSING for interactive widgets, report this as a Critical bug.** Every interactive widget (buttons, inputs, lists, etc.) MUST have at least one working interactive demo. Missing demos indicate incomplete documentation.

#### Cross-Reference
- [ ] Matches `src/Hex1b/Widgets/[WidgetName]Widget.cs`
- [ ] Matches `src/Hex1b/Nodes/[WidgetName]Node.cs`
- [ ] Extension methods accurate
- [ ] Theme elements documented
Guide Page Focus
markdown
## Guide: [Page Title]

### Page: /guide/[page-name]

#### Content Verification
- [ ] Conceptual explanations accurate
- [ ] Terminology consistent with codebase
- [ ] Architecture diagrams current
- [ ] Example code compiles

#### Code Examples
For each example:
- [ ] Example [N]: Compiles successfully
- [ ] Example [N]: Runs as described
- [ ] Example [N]: Output matches documentation

#### Links
- [ ] All internal links work
- [ ] External links accessible
- [ ] "Next Steps" links valid
API Reference Focus
markdown
## API: [Type/Namespace]

### Page: /api/[path]

#### Completeness
- [ ] All public types documented
- [ ] All public members documented
- [ ] Parameter descriptions accurate
- [ ] Return value descriptions accurate

#### Accuracy
- [ ] Type signatures match source
- [ ] Default values documented correctly
- [ ] Exceptions documented
- [ ] Examples work as shown

Output Format

After testing a focus area, produce a structured report:

markdown
# Documentation Test Report

**Focus Area:** [Description]
**Date:** [ISO Date]
**Tester:** doc-tester agent

## Summary

| Category | Passed | Failed | Warnings |
|----------|--------|--------|----------|
| Content Accuracy | X | Y | Z |
| Code Examples | X | Y | Z |
| Interactive Demos | X | Y | Z |
| Links | X | Y | Z |

## Critical Issues

Issues that make documentation misleading or incorrect.

### Issue 1: [Brief Title]

**Location:** [Page URL and section]
**Type:** [Content/Example/Demo/Link]
**Severity:** Critical

**What the documentation says:**
> [Quote from documentation]

**What actually happens:**
> [Description of actual behavior]

**Evidence:**
[Code snippet, error message, or screenshot description]

**Recommended Action:**
- [ ] Update documentation to match behavior
- [ ] Fix implementation to match documentation
- [ ] Add clarifying note

---

## Warnings

Issues that may confuse readers but aren't strictly incorrect.

### Warning 1: [Brief Title]

**Location:** [Page URL and section]
**Issue:** [Description]
**Suggestion:** [How to improve]

---

## Passed Checks

[List of items that passed validation - brief summary]

## Recommendations

1. **Priority fixes:** [List critical issues to address first]
2. **Documentation gaps:** [Missing documentation to add]
3. **Product issues:** [Implementation bugs discovered]

Local Package Testing

Testing code examples requires running them against the current Hex1b source, not the published NuGet package. This ensures documentation matches the actual behavior of the code in the repository.

Build Script

The build-local-package.sh script in this skill directory handles package creation:

bash
./.github/skills/doc-tester/build-local-package.sh

What it does:

  1. Cleans any previous local packages
  2. Runs dotnet pack on src/Hex1b/Hex1b.csproj
  3. Uses a timestamped version suffix (e.g., 0.35.0-local.20260105120000)
  4. Outputs the package to .doc-tester-packages/ in the repo root
  5. Creates a NuGet.config that prioritizes the local feed

Output:

✓ Built Hex1b 0.35.0-local.20260105120000
✓ Package: /path/to/hex1b/.doc-tester-packages/Hex1b.0.35.0-local.20260105120000.nupkg
✓ NuGet config: /path/to/hex1b/.doc-tester-packages/NuGet.config
Testing Code Examples Workflow

When validating code examples from documentation:

Step 1: Create a Test Project in the Workspace

Test projects are created in .doc-tester-workspace/ within the hex1b repository. This directory is gitignored.

bash
# Navigate to the hex1b repo root
cd /path/to/hex1b

# Create test project directory (name it descriptively for the test)
mkdir -p .doc-tester-workspace/DocTest
cd .doc-tester-workspace/DocTest

# Create new console project
dotnet new console --force

# Copy the local NuGet.config (contains absolute path to packages)
cp ../../.doc-tester-packages/NuGet.config .
Step 2: Add Local Package Reference
bash
# Add the local Hex1b package (use version from build script output)
# The NuGet.config uses an absolute path, so no need to copy the .nupkg file
dotnet add package Hex1b --version 1.0.0-local.20260105120000
Step 3: Test the Code Example
bash
# Replace Program.cs with the documentation code sample
cat > Program.cs << 'EOF'
// Paste code example from documentation here
EOF

# Build to verify it compiles
dotnet build
Step 4: Run as TUI App with TerminalMcp

Hex1b applications are TUI (Terminal User Interface) apps that take over the terminal. Use the TerminalMcp server with an interactive shell:

# Start an interactive shell (use start_pwsh_terminal on Windows)
start_bash_terminal workingDirectory="/path/to/hex1b"

# Wait for shell prompt
wait_for_terminal_text text="$" timeoutSeconds=5

# Navigate to test project and run
send_terminal_input text="cd .doc-tester-workspace/DocTest && dotnet run\n"

# Wait for the TUI to render
wait_for_terminal_text text="Expected text" timeoutSeconds=10

# Capture and verify output (ALWAYS use both for TUI apps)
capture_terminal_text      # Text-based verification
capture_terminal_screenshot savePath="/path/to/hex1b/.doc-tester-workspace/screenshots/example-name.svg"

# Interact with the TUI if needed
send_terminal_key key="Tab"
send_terminal_input text="test"

# Exit the TUI (Ctrl+C or Escape depending on the app)
send_terminal_key key="Escape"

# Clean up the session
remove_session sessionId="..."

See the TerminalMcp Server section for full details.

Step 5: Compare Behavior
  • Does it compile without errors?
  • Does it run without exceptions?
  • Does the output/behavior match what documentation describes?
  • Do keyboard interactions work as documented?
Automated Example Testing

For testing multiple examples efficiently, use this pattern:

bash
#!/bin/bash
# test-examples.sh

REPO_ROOT="$(cd "$(dirname "$0")" && pwd)"
EXAMPLES_DIR="$1"
PACKAGE_VERSION="$2"
NUGET_CONFIG="$REPO_ROOT/.doc-tester-packages/NuGet.config"
WORKSPACE="$REPO_ROOT/.doc-tester-workspace"

# Ensure workspace exists
mkdir -p "$WORKSPACE"

for example in "$EXAMPLES_DIR"/*.cs; do
    name=$(basename "$example" .cs)
    test_dir="$WORKSPACE/test-$name"
    
    echo "Testing: $name"
    
    # Clean up any previous test
    rm -rf "$test_dir"
    mkdir -p "$test_dir"
    cd "$test_dir"
    
    dotnet new console --force > /dev/null
    cp "$NUGET_CONFIG" .
    dotnet add package Hex1b --version "$PACKAGE_VERSION" > /dev/null 2>&1
    cp "$example" Program.cs
    
    if dotnet build > /dev/null 2>&1; then
        echo "  ✓ $name: Compiles"
    else
        echo "  ✗ $name: Build failed"
    fi
done

echo "Test projects preserved in $WORKSPACE for inspection"
NuGet.config Template

The build script creates a NuGet.config with an absolute path to the package directory:

xml
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="doc-tester-local" value="/absolute/path/to/hex1b/.doc-tester-packages" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <packageSource key="doc-tester-local">
      <package pattern="Hex1b" />
    </packageSource>
    <packageSource key="nuget.org">
      <package pattern="*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

This ensures:

  • Hex1b comes from the local package (works when copied to any directory)
  • All other dependencies come from nuget.org
  • No need to copy the .nupkg file to the test project directory
Cleanup

After testing, clean up:

bash
# Remove local packages
rm -rf .doc-tester-packages/

# Or run the build script with --clean
./.github/skills/doc-tester/build-local-package.sh --clean

Aspire Integration

The doc-tester uses Aspire to run the documentation site locally. This enables testing against the latest changes before deploying.

Starting Aspire
bash
aspire run

If prompted about an existing instance, allow it to stop the previous one.

Finding Resource URLs

Use the Aspire MCP tools to discover service endpoints:

# List all resources and their status
list_resources

# Expected output includes:
# - content (ViteApp) → http://localhost:1189
# - website (CSharpApp) → http://localhost:XXXXX

The content resource URL is the documentation site. Use this URL for all testing instead of https://hex1b.dev.

Monitoring During Testing

Use Aspire diagnostic tools to debug issues:

ToolPurpose
list_console_logsView stdout/stderr from resources
list_structured_logsQuery structured log entries
list_tracesView distributed traces
execute_resource_commandRestart resources if needed
Typical Testing Session
bash
# 1. Start environment
aspire run

# 2. Build local packages (in another terminal)
./.github/skills/doc-tester/build-local-package.sh

# 3. Use MCP tools to get content URL
# list_resources → find content endpoint

# 4. Fetch pages and test
# fetch_webpage with local URLs

# 5. Test code examples
# Create temp projects with local packages

# 6. Check for errors
# list_console_logs for website resource
WebSocket Demo Testing

Interactive demos connect to the website resource via WebSocket. When testing demos:

  1. Get the website resource URL from list_resources
  2. The demos connect to /ws/example/{example-id}
  3. Check list_console_logs for the website resource if demos fail
Resource Health

Before testing, verify resources are healthy:

list_resources

Look for:

  • ✅ Running state for both content and website
  • ✅ HTTP endpoints available
  • ⚠️ If Waiting or Failed, check logs with list_console_logs

TerminalMcp Server

The TerminalMcp server provides tools for running and observing terminal applications. This is essential for testing Hex1b code examples that produce TUI (Terminal User Interface) output, since standard command-line execution cannot capture the visual output of TUI apps.

When to Use TerminalMcp

Use TerminalMcp when you need to:

  • Run a Hex1b TUI application and verify its visual output
  • Capture terminal screenshots (SVG) for documentation verification
  • Interact with running TUI apps using keyboard input
  • Wait for specific text to appear on the terminal screen

TerminalMcp solves the limitation that TUI apps take over the terminal and can't be easily observed through standard tooling.

Show full SKILL.md (1,137 more words)Show less
Supported Shells

TerminalMcp works by starting an interactive shell and then sending commands to it like a user would. The supported shells are:

ShellOSPreferred For
bashLinux, macOSLinux and macOS systems
pwsh (PowerShell)Windows, Linux, macOSWindows systems

Detecting Available Shells:

Before starting a terminal session, check which shells are available:

bash
# On Linux/macOS - check for bash
which bash

# Check for PowerShell (cross-platform)
which pwsh

Use bash on Linux/macOS and pwsh on Windows.

Available Tools
ToolPurpose
start_bash_terminalStart a new bash shell session (Linux/macOS)
start_pwsh_terminalStart a new PowerShell session (Windows or cross-platform)
stop_terminalKill the process (session remains for inspection)
remove_sessionFully dispose and clean up a session
list_terminalsList all active terminal sessions
send_terminal_inputSend text input (commands) to the shell
send_terminal_keySend special keys (Enter, Tab, arrows, F1-F12)
resize_terminalResize the terminal dimensions
capture_terminal_textGet the screen buffer as plain text
capture_terminal_screenshotSave the screen as SVG and PNG (requires savePath)
wait_for_terminal_textWait for specific text to appear
Interactive Shell Workflow

⚠️ IMPORTANT: Start a shell, then send commands interactively

Do NOT try to run dotnet run directly as the command. Instead, start an interactive shell and send commands to it like a user would:

# 1. Start an interactive bash shell (use start_pwsh_terminal on Windows)
mcp_terminal-mcp_start_bash_terminal workingDirectory="/path/to/hex1b"

# 2. Wait for the shell prompt to appear
mcp_terminal-mcp_wait_for_terminal_text text="$" timeoutSeconds=5

# 3. Send a command by typing it + pressing Enter
mcp_terminal-mcp_send_terminal_input text="cd .doc-tester-workspace/DocTest"
mcp_terminal-mcp_send_terminal_key key="Enter"

# 4. Wait for the command to complete (shell prompt returns)
mcp_terminal-mcp_wait_for_terminal_text text="$" timeoutSeconds=5

# 5. Run the TUI application
mcp_terminal-mcp_send_terminal_input text="dotnet run"
mcp_terminal-mcp_send_terminal_key key="Enter"

# 6. Wait for the TUI to render
mcp_terminal-mcp_wait_for_terminal_text text="TextBox Widget Demo" timeoutSeconds=15

# 7. Capture and verify output
mcp_terminal-mcp_capture_terminal_text

# 8. Interact with the TUI (type, Tab, etc.)
mcp_terminal-mcp_send_terminal_input text="Hello World"
mcp_terminal-mcp_send_terminal_key key="Tab"

# 9. Exit the TUI (Ctrl+C)
mcp_terminal-mcp_send_terminal_key key="c" modifiers=["Ctrl"]

# 10. Clean up
mcp_terminal-mcp_stop_terminal sessionId="..."
mcp_terminal-mcp_remove_session sessionId="..."
Why Interactive Shell?

The dedicated shell tools (start_bash_terminal, start_pwsh_terminal) ensure:

  • Proper environment setup (PATH, etc.)
  • Correct working directory handling
  • Better PTY initialization for TUI apps
  • The ability to run multiple commands in sequence
Testing Code Examples with TerminalMcp

For Hex1b TUI applications:

  1. Build the test project first using run_in_terminal (standard terminal)
  2. Start an interactive shell in TerminalMcp
  3. Navigate to the project directory using cd command
  4. Run dotnet run by sending the command + Enter
  5. Wait for the TUI to render using wait_for_terminal_text
  6. Capture output using BOTH capture_terminal_text AND capture_terminal_screenshot
  7. Interact with the TUI using input tools
  8. Exit and clean up the session
Screenshot Directory

All terminal screenshots should be saved to .doc-tester-workspace/screenshots/ with descriptive filenames:

.doc-tester-workspace/
├── screenshots/
│   ├── button-basic-initial.svg
│   ├── button-basic-initial.png
│   ├── button-basic-after-click.svg
│   ├── button-basic-after-click.png
│   ├── textbox-typing.svg
│   ├── textbox-typing.png
│   └── ...
└── DocTest/
    └── ...

Use filenames that identify the test and step, e.g., widget-example-step.svg. Both SVG and PNG files are generated automatically.

Comparing Output to Documentation

When documentation shows expected output:

  1. ALWAYS capture both text AND screenshot for TUI apps
  2. Use capture_terminal_text for text-based verification
  3. Use capture_terminal_screenshot with savePath to save for inspection (e.g., savePath=".doc-tester-workspace/screenshots/test-name.svg")
  4. Compare against documentation claims
  5. Report discrepancies as documentation issues

⚠️ IMPORTANT: TUI apps have visual elements (colors, borders, styling) that cannot be assessed from plain text alone. Always save the screenshot for inspection. Screenshots are preserved (not deleted) so you can review them after testing.

Limitations
  • TerminalMcp runs on the local machine (Linux/macOS with PTY support)
  • Sessions persist until explicitly removed - always clean up
  • For long-running apps, use stop_terminal then remove_session

Playwright MCP Tools Reference

These are the primary tools for testing. Use these instead of reading source files.

Navigation & Reading
ToolPurpose
mcp_playwright_browser_snapshotGet accessibility tree of current page (read content)
mcp_playwright_browser_clickClick links, buttons, demos
mcp_playwright_browser_navigateGo to a specific URL
mcp_playwright_browser_typeType into text fields
mcp_playwright_browser_pressPress keyboard keys (Tab, Enter, etc.)
Reading Page Content
# Navigate to the docs
mcp_playwright_browser_navigate url="http://content-hex1b.dev.localhost:1189/guide/widgets/text"

# Read the page content
mcp_playwright_browser_snapshot

The snapshot returns an accessibility tree showing all text content, links, buttons, and interactive elements.

⚠️ Visual Verification Limitations

Accessibility snapshots cannot verify visual correctness. Snapshots show DOM structure and text content, but NOT:

  • Colors and styling
  • Visual layout and spacing
  • How text overflow actually renders (truncation, wrapping)
  • Unicode character display width
  • Terminal cursor appearance

For visual verification, use screenshots:

# Take a screenshot to verify visual output
mcp_playwright_browser_take_screenshot

# Or screenshot a specific element
mcp_playwright_browser_take_screenshot element="Terminal demo output" ref="e123"

When to use screenshots:

  • Verifying "Show output" previews match their descriptions
  • Checking interactive terminal demos display correctly
  • Confirming Unicode characters (emoji, CJK) render with correct width
  • Validating color/styling claims in documentation
Interacting with Demos
# Find and click the demo button
mcp_playwright_browser_click element="Run in browser"

# Wait for demo to load
mcp_playwright_browser_wait_for text="some expected text"

# Interact
mcp_playwright_browser_press key="Tab"
mcp_playwright_browser_type text="Hello"
mcp_playwright_browser_press key="Enter"

# See results
mcp_playwright_browser_snapshot
Handling Terminal Demos

The interactive terminal demos use WebSocket connections. When you click "Run in browser":

  1. A terminal overlay appears
  2. The example code runs in the terminal
  3. You can interact with it using keyboard inputs

Use mcp_playwright_browser_press to send keyboard input to the terminal.

Interaction with Other Skills

Handoff to doc-writer

When documentation issues are found, create actionable items for the doc-writer skill:

markdown
## Doc-Writer Task: [Issue Title]

**Source:** doc-tester report [date]
**Priority:** [Critical/High/Medium/Low]

**Page URL:** [URL from Playwright navigation]

**Issue:**
[What's wrong or missing - based on what you saw in the browser]

**User Impact:**
[How this affects someone trying to learn from the docs]

**Suggested fix:**
[What information should be added or corrected]
When You Can't Proceed

If documentation is insufficient to complete a task:

markdown
## Documentation Gap: [Title]

**What I was trying to do:**
[Task or goal]

**Where I got stuck:**
[Page URL and section]

**What information was missing:**
[What the docs should have told me]

**Questions a user would have:**
1. [Question 1]
2. [Question 2]

**Recommendation:**
Add [specific content] to [specific location]

This is valuable feedback! Gaps that block a user are high-priority fixes.

Handoff to Product/Engineering

When the docs are correct but the library doesn't work as documented:

markdown
## Bug Report: [Issue Title]

**Discovered via:** Documentation testing
**Affected documentation:** [URL]

**Expected behavior (per docs):**
[What documentation says should happen]

**Actual behavior:**
[What actually happens when running the code]

**Code example from docs:**
[The exact code you copied from the documentation]

**Recommendation:**
- [ ] Fix implementation to match documented behavior
- [ ] Update documentation if current behavior is intentional

Best Practices

Do
  • ✅ Use Playwright to read ALL documentation content
  • ✅ Copy code examples EXACTLY as shown in the browser
  • ✅ Test as if you know nothing about the codebase
  • ✅ Document when you get stuck - this is valuable feedback
  • ✅ Evaluate if explanations would make sense to a newcomer
  • ✅ Test interactive demos by actually interacting with them
  • ✅ Note terminology that isn't explained
  • ✅ Hand off to doc-writer when you find gaps
Don't
  • ❌ Read source code to understand how things work
  • ❌ Use internal knowledge of the codebase
  • ❌ Assume you know what something means - check if docs explain it
  • ❌ Skip testing code examples (they must actually run)
  • ❌ Ignore confusing explanations - report them
  • ❌ Continue past blockers without documenting them

Common Issues to Watch For

Teaching Gaps
  • Concepts used before they're explained
  • Missing prerequisites or assumptions
  • Jumps in complexity without explanation
  • Jargon without definitions
Documentation Drift
  • API changes that weren't reflected in docs
  • Renamed properties/methods still using old names
  • Removed features still documented
  • New features not yet documented
Example Rot
  • Code examples using deprecated APIs
  • Missing using statements
  • Incomplete examples that don't compile
  • Examples that compile but don't work as described
Demo Inconsistencies
  • Live demos that don't match static code snippets
  • WebSocket examples with different behavior than documented
  • Missing interactive examples for interactive widgets (Critical - "Run in browser" button missing)
  • Demo state that persists incorrectly
  • Demo fails with 500 error (example not registered in Program.cs)
Conceptual Inaccuracies
  • Explanations that don't match implementation
  • Incorrect architecture descriptions
  • Misleading performance claims
  • Wrong default values documented

Documentation Style Guide

When testing documentation, verify that code examples follow these style conventions. Violations of these rules should be reported as bugs.

Hex1bApp Callback Pattern

Prefer synchronous callbacks for Hex1bApp unless the example specifically requires async behavior:

✅ Correct - Use the synchronous overload:

csharp
var app = new Hex1bApp(ctx => ctx.VStack(v => [
    v.Text("Hello"),
    v.Button("Click me")
]));

❌ Incorrect - Don't use Task.FromResult unless async is required:

csharp
var app = new Hex1bApp(ctx => Task.FromResult<Hex1bWidget>(
    ctx.VStack(v => [
        v.Text("Hello"),
        v.Button("Click me")
    ])
));

When async IS required:

  • The builder function needs to await something
  • The example is demonstrating async patterns specifically
Other Style Rules
RuleCorrectIncorrect
Use collection expressionsv => [v.Text("A"), v.Text("B")]v => new[] { v.Text("A"), v.Text("B") }
Prefer varvar app = new Hex1bApp(...)Hex1bApp app = new Hex1bApp(...)
Include required using statementsAlways show importsOmit imports
Use file-scoped classes for stateclass MyState { ... } at endInline anonymous types
Reporting Style Violations

When a code example violates style rules:

  1. Mark as a bug in the test report
  2. Specify the rule violated
  3. Show the correct version

Example report entry:

markdown
### Bug: Style Violation - Unnecessary async callback

**Location:** /guide/widgets/button - Basic Usage example
**Rule:** Prefer synchronous Hex1bApp callbacks
**Current:**
\`\`\`csharp
var app = new Hex1bApp(ctx => Task.FromResult<Hex1bWidget>(ctx.Button("Click")));
\`\`\`
**Should be:**
\`\`\`csharp
var app = new Hex1bApp(ctx => ctx.Button("Click"));
\`\`\`

Evolving This Skill

This skill will evolve based on testing experience. When you discover:

  1. New testing patterns - Add them to the workflow
  2. Common failure modes - Document them in "Common Issues"
  3. Better output formats - Update the report template
  4. Integration improvements - Enhance handoff processes

Track skill evolution in git history for this file.

© mitchdenny, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in .github/skills/doc-tester of mitchdenny/hex1b.

  • SKILL.md
  • build-local-package.sh

Open the folder on GitHubat commit e2335bd

Compare with similar skills

Doc Tester next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Doc Tester compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Doc Tester this skillmitchdenny/hex1b178—~9.5kAutomated safety check: PassMIT
Web Application Testinganthropics/skills180k51 repos~966Automated safety check: PassApache-2.0
Playwright CLIsanity-io/sanity6.4k18 repos~1.9kAutomated safety check: PassMIT
Write and Verify Playwright Testsappsmithorg/appsmith41k—~2.9kAutomated safety check: NotesApache-2.0
playwright-cli Browser Automationgithub/gh-aw5.4k23 repos~2.8kAutomated safety check: PassMIT
Cucumber and Playwright E2E Testslanggenius/dify158k—~682Automated safety check: PassCustom licence

Similar skills

  • Web Application Testing

    anthropics/skills

    Official

    Tests local web applications with Python Playwright scripts, checking frontend behavior, capturing screenshots and reading browser console logs.

    180k GitHub starsUsed in 51 repos~966 tokens
    Testing & QAAuto-check passed
  • Playwright CLI

    sanity-io/sanity

    Official

    Automates browser interactions for web testing, form filling, screenshots, and data extraction.

    6.4k GitHub starsUsed in 18 repos~1.9k tokens
    Testing & QAAuto-check passed
  • Writes a Playwright end-to-end test from a prompt, runs it against a live Appsmith deployment and retries with fixes up to three times until it passes.

    41k GitHub stars~2.9k tokensUpdated today
    Testing & QAAuto-check: notes
  • Official

    Drives a real browser from the command line with playwright-cli to open pages, interact, mock requests, save state and work with Playwright tests.

    5.4k GitHub starsUsed in 23 repos~2.8k tokens
    Testing & QAAuto-check passed
  • Guides changes and reviews of the Cucumber and Playwright end-to-end suite under `e2e/`: feature files, step definitions, support code, tags, locators and assertions.

    158k GitHub stars~682 tokensUpdated today
    Testing & QAAuto-check passed
  • Verify Openhands

    OpenHands/OpenHands

    This skill should be used to "verify OpenHands features", "test the Canvas UI like a user", "drive Agent Canvas", "check a UI change in the real app", "create or update the feature map", "run the…

    90k GitHub stars~3.4k tokensUpdated today
    Testing & QAAuto-check passed

More from mitchdenny/hex1b

  • API Reviewer

    mitchdenny/hex1b

    Guidelines for reviewing API design in the Hex1b codebase. An agent skill from mitchdenny/hex1b.

    178 GitHub stars~4k tokensUpdated today
    Auto-check passed
  • Surface Benchmarker

    mitchdenny/hex1b

    Guidelines for running and interpreting Surface API performance benchmarks.

    178 GitHub stars~3.1k tokensUpdated today
    Auto-check passed
  • Doc Writer

    mitchdenny/hex1b

    Guidelines for producing accurate and maintainable documentation for the Hex1b TUI library.

    178 GitHub stars~8.7k tokensUpdated today
    Auto-check passed
  • Test Fixer

    mitchdenny/hex1b

    Agent for diagnosing and fixing flaky terminal UI tests in the Hex1b test suite.

    178 GitHub stars~6.5k tokensUpdated today
    Auto-check passed
  • Widget Creator

    mitchdenny/hex1b

    Step-by-step guide for creating new widgets in the Hex1b TUI library.

    178 GitHub stars~7.6k tokensUpdated today
    Auto-check passed
  • Writing Unit Tests

    mitchdenny/hex1b

    Guidelines for writing unit tests in the Hex1b TUI library. An agent skill from mitchdenny/hex1b.

    178 GitHub stars~7k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Doc Tester

What does Doc Tester do?

Agent for validating Hex1b documentation against actual library behavior. Doc Tester is an agent skill from mitchdenny/hex1b. Agent for validating Hex1b documentation against actual library behavior.

When should I use Doc Tester?

Doc Tester fits situations like: auditing documentation accuracy; testing interactive examples; identifying discrepancies between documentation and implementation.

How do I install Doc Tester in Claude Code?

Run `npx skills add mitchdenny/hex1b --skill doc-tester -a claude-code`. Or copy the skill folder (.github/skills/doc-tester in mitchdenny/hex1b) into .claude/skills/doc-tester in your project. Claude Code loads it when a task matches its description.

How do I install Doc Tester in Codex?

Run `npx skills add mitchdenny/hex1b --skill doc-tester -a codex`. Or copy the skill folder (.github/skills/doc-tester in mitchdenny/hex1b) into .agents/skills/doc-tester in your project. Codex loads it when a task matches its description.

Can I use Doc Tester in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mitchdenny/hex1b --skill doc-tester -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/doc-tester, .gemini/skills/doc-tester, .github/skills/doc-tester and .opencode/skills/doc-tester in your project.

What does Doc Tester need to run?

Going by SKILL.md and its folder, Doc Tester needs a shell for the scripts in its folder and the command-line tools its instructions call (dotnet). Our summary lists: A Bash shell.

Does Doc Tester access the network?

SKILL.md names 2 domains. In commands or code: api.nuget.org; the agent is likely to contact it when it follows the instructions. As links in the text: hex1b.dev. This is read from the text; nothing was executed.

Is Doc Tester safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Doc Tester use?

Doc Tester is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Doc Tester use?

About 9.5k tokens (SKILL.md is roughly 38k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Doc Tester?

Skills that share tags, products or a category with Doc Tester: Web Application Testing (anthropics/skills, 180k stars), Playwright CLI (sanity-io/sanity, 6.4k stars), Write and Verify Playwright Tests (appsmithorg/appsmith, 41k stars) and playwright-cli Browser Automation (github/gh-aw, 5.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Doc Tester?

mitchdenny (a GitHub user) maintains it in mitchdenny/hex1b, which has 178 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 9, 2026.

Source: mitchdenny/hex1b on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.