Communitygithub.com

shenyuhao1/agent-doc-generator

Turn agent sessions into illustrated, reproducible Word documentation with automatic screenshots and encoding-safe images.

Qu'est-ce que agent-doc-generator ?

agent-doc-generator is a Claude Code agent skill that turn agent sessions into illustrated, reproducible Word documentation with automatic screenshots and encoding-safe images.

Compatible avecClaude CodeCodex CLI~Cursor
npx skills add shenyuhao1/agent-doc-generator

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Generate Illustrated Agent Documentation

Create a reproducible gen_doc.js, run it, and deliver both the generator and the final DOCX. Keep the generator portable: all project-bound image assets must live in the output workspace, not only under a global Codex directory.

Required Outputs

  • gen_doc.js: document generator.
  • Final .docx: generated by running the script.
  • doc-assets/images.json: image manifest when the document contains visuals.
  • image-plan.json: reproducible source plan when screenshots or copied images are used.
  • doc-image-helpers.cjs: copy from scripts/doc-image-helpers.cjs when image support is needed.

Prerequisites

  • Install docx: npm install -g docx or add it to the project.
  • Set NODE_PATH when using a global install.
  • Install playwright only when browser screenshots are required. Existing images and generated images do not require Playwright.

Runtime Compatibility

The core SKILL.md, scripts, and references follow the Agent Skills directory pattern and can be used by Codex or Claude Code.

  • In Codex, keep the skill under $CODEX_HOME/skills/agent-doc-generator and use the built-in imagegen path when available.
  • In Claude Code, place it under ~/.claude/skills/agent-doc-generator or .claude/skills/agent-doc-generator; invoke it with /agent-doc-generator and use ${CLAUDE_SKILL_DIR} to resolve bundled scripts.
  • agents/openai.yaml is Codex UI metadata and is not required by Claude Code.
  • The Node scripts are runtime-neutral. Only the image-generation tool invocation needs an agent-specific adapter.

Workflow

  1. Inspect the transcript, notes, repository, and requested output location.
  2. Build a concise chapter outline around the actual development phases.
  3. Decide which claims benefit from visuals before writing the document.
  4. Prepare images and generate doc-assets/images.json.
  5. Copy scripts/doc-image-helpers.cjs beside gen_doc.js.
  6. Generate gen_doc.js with actual image calls, not hard-coded placeholders.
  7. Run the generator and validate the DOCX.
  8. Render the DOCX to images or PDF for a visual check when LibreOffice is available.

Use chapter-by-chapter approval only when the user asks for staged review. Otherwise generate the complete first draft and iterate from the rendered result.

Visual Source Selection

Choose the most faithful source for each visual:

  1. Existing image: reuse project screenshots, charts, logos, or diagrams.
  2. Browser screenshot: capture real UI state with scripts/prepare-images.mjs and Playwright.
  3. Precise explanatory diagram: build it in HTML/CSS/SVG/Mermaid, then capture it. Prefer this for exact labels, architecture, sequences, and code paths.
  4. Codex-generated explanatory image: use the built-in imagegen capability for conceptual illustrations, educational cutaways, or visual metaphors where exact UI and exact text are not required.

For Codex-generated images:

  • Use the built-in image generation tool by default.
  • Save or copy the selected output from $CODEX_HOME/generated_images/... into the document workspace.
  • Add the copied file to image-plan.json with source: "generated".
  • Do not leave a DOCX-referenced image only in the global generated-images directory.
  • Avoid generated text-heavy diagrams. Render exact labels with code instead.

Read references/image-workflow.md whenever visuals are requested.

Image Contract

Treat images.json as the boundary between asset preparation and DOCX generation.

  • Give every image a stable id.
  • Store paths relative to the manifest.
  • Include pixel width, pixel height, caption, alt text, origin, and required state.
  • Use imageBlock(id, { required: true }) for visuals essential to the explanation.
  • Allow optional images to fall back to a labeled placeholder.
  • Never silently omit a required image.

Encoding Contract

  • Read image bytes with fs.readFileSync(filePath) and pass the resulting Buffer directly to ImageRun.
  • Never decode image bytes as UTF-8, inline them into JSON, or run text replacement on Base64 image data.
  • Read and write JSON, JavaScript, Markdown, captions, and transcript text as UTF-8.
  • Save generated source files as UTF-8 without converting through the active console code page.
  • Keep image paths as normal strings; do not serialize binary data into the manifest.
  • Include a regression test with a Chinese caption and a PNG image whenever image handling changes.

Document Structure

Adapt the structure to the project. A useful default is:

  • Title page.
  • Product or outcome overview.
  • Requirements and constraints.
  • Architecture and design decisions.
  • Implementation phases.
  • Verification and observed results.
  • Problems encountered and lessons learned.
  • Runbook or handoff notes.

Self-documentation is allowed when explicitly requested. In that case, explain the skill's purpose, workflow, files, extension points, and a real end-to-end example.

Content Rules

  • Extract only meaningful dialog excerpts; omit tool noise and repetitive approvals.
  • Explain why decisions were made, not only what commands ran.
  • Keep code excerpts short and relevant.
  • Use tables for compact comparisons and measured results.
  • Use real screenshots for claims about UI state.
  • Use captions that explain why the visual matters.
  • Keep paths and commands exact.
  • Preserve the user's requested language and writing style.

DOCX Rules

  • Set page size and margins explicitly.
  • Use built-in heading levels with matching style IDs and outline levels.
  • Use DXA widths for tables and set both table column widths and cell widths.
  • Put PageBreak inside a paragraph.
  • Set the required type and complete altText fields on every ImageRun.
  • Scale images proportionally within the page content area.
  • Use real numbering definitions instead of Unicode bullet characters.

Commands

Prepare assets:

$env:PLAYWRIGHT_PATH = "C:\path\to\playwright-or-playwright-core"
node "<skill-dir>\scripts\prepare-images.mjs" image-plan.json

Copy the DOCX image helper:

Copy-Item "<skill-dir>\scripts\doc-image-helpers.cjs" .

Generate the document:

$env:NODE_PATH = npm root -g
node gen_doc.js

Validate the output with the DOCX skill's validator:

python "$env:USERPROFILE\.codex\skills\docx\scripts\office\validate.py" output.docx

Transcript Input

Prefer a clean transcript with alternating user and assistant text. Remove tool payloads, hidden metadata, duplicate progress updates, and unrelated chat before outlining. If the original source is JSONL, use a structured JSON parser rather than line-based string slicing.

Failure Handling

  • If Playwright is unavailable, continue with existing/generated images and leave screenshot entries unprepared; report the missing dependency.
  • If the app cannot start, do not fabricate screenshots. Preserve the screenshot plan so it can be rerun later.
  • If image generation is unavailable, use a precise code-rendered diagram or a labeled optional placeholder.
  • If a required visual cannot be produced, stop document generation with a clear error instead of shipping a misleading document.

Resources

  • scripts/prepare-images.mjs: copy local/generated images, capture browser screenshots, and write images.json.
  • scripts/doc-image-helpers.cjs: load the manifest, scale images, insert captions, and handle missing assets.
  • references/image-workflow.md: plan schema, image-generation guidance, and integration examples.

Skills associés