App Documentation Generator

Browser Tool Detection

1. Chrome MCP (

   mcp__claude-in-chrome__*

   ) — preferred for authenticated apps
2. Playwright MCP (

   mcp__plugin_playwright_playwright__*

   ) — for public apps
3. playwright-cli — for scripted flows

Depth Levels

Workflow

1. Get App Details

• App URL (required)
• App name (for the guide title)
• Auth — do they need to log in? Chrome MCP uses their session; Playwright needs credentials
• Depth — quick, standard, or thorough
• Audience — who will read this guide? (end users, admins, new team members)

2. Discover All Routes

• Read the sidebar/navigation menu
• Click through all top-level items
• Note sub-pages and nested navigation
• Check for settings, profile, admin areas
• Record the URL and purpose of each page

3. Document Each Page

a. Navigate and Orient

• Navigate to the page
• Wait for data to load (no skeleton/spinner in screenshot)
• Resize browser to 1280x720 for consistent screenshots

b. Screenshot Default State

• Take a clean screenshot showing the page with realistic data
• Save to

  docs/screenshots/

  with descriptive names:

  01-dashboard.png

  ,

  02-contacts-list.png

c. Describe the Page

• What this page is for — one sentence
• What the user can see — key data, status indicators, navigation elements
• What the user can do — actions available (buttons, forms, filters)

d. Document Key Workflows

1. Screenshot the starting state
2. Perform the action (click button, fill form)
3. Screenshot each significant step
4. Screenshot the result/confirmation
5. Write numbered steps matching the screenshots

e. Depth-Specific Extras

4. Organise the Guide

# [App Name] User Guide

## Getting Started
- Accessing the app (URL, login)
- Dashboard overview
- Navigation guide

## [Core Feature 1: e.g. Contact Management]
### Viewing contacts
### Adding a new contact
### Editing contact details
### Deleting a contact
### Searching and filtering

## [Core Feature 2: e.g. Reports]
### Viewing reports
### Creating a report
### Exporting data

## [Core Feature 3: e.g. Settings]
### Profile settings
### Team management
### Preferences

## Tips and Shortcuts
- Keyboard shortcuts (if any)
- Bulk actions
- Filters and search tips

## Troubleshooting
- Common issues noticed during documentation
- Error messages and what they mean

5. Write the Output

docs/screenshots/NN-description.png

docs/USER_GUIDE.md

• Relative image paths:

  ![Dashboard](screenshots/01-dashboard.png)

• Step-by-step numbered lists for workflows
• Tables for reference data (keyboard shortcuts, settings options)
• Admonitions for important notes:

  > **Note:** ...

Screenshot Conventions

• Resolution: 1280x720 (desktop), 375x812 (mobile if thorough)
• Naming:

  NN-section-description.png

  (e.g.

  01-dashboard-overview.png

  ,

  05-contacts-add-form.png

  )
• Content: Wait for data to load. No spinners, no skeleton screens in final shots.
• Annotations: If a screenshot needs callouts, describe them in the markdown text below the image rather than editing the image
• Save location:

  docs/screenshots/

  in the project root

Autonomy Rules

• Just do it: Navigate pages, take screenshots, read page content
• Brief confirmation: Before writing docs to files
• Ask first: Before submitting forms, before clicking delete, before entering credentials
• Thorough mode: Same as above but skip confirmation for writing files and filling forms with test data

Quality Rules

1. Document what the app actually does, not what you think it should do
2. Every screenshot must have context — don't just dump images without explanation
3. Write for the audience — admin docs are different from end-user docs
4. Number screenshots chronologically — so they make sense when viewed in a file browser
5. Note gaps — if a feature seems incomplete or confusing, note it (this is feedback for the developer)
6. Keep steps atomic — one action per numbered step