docs-manager

Documentation Manager Workflow

Execute a structured 6-phase workflow for managing documentation. Supports two documentation formats (MkDocs sites and standalone markdown files) and three action types (generate, update, change summary).

Phase Overview

Execute these phases in order, completing all applicable phases:

1. Interactive Discovery — Determine documentation type, format, and scope through user interaction
2. Project Detection & Setup — Detect project context, conditionally scaffold MkDocs
3. Codebase Analysis — Deep codebase exploration using the deep-analysis skill
4. Documentation Planning — Translate analysis findings into a concrete plan for user approval
5. Documentation Generation — Delegate to docs-writer to generate content
6. Integration & Finalization — Write files, validate, present results

Phase 1: Interactive Discovery

Goal: Determine through user interaction what documentation to create and in what format.

Step 1 — Infer intent from inputs

Parse the user's input to pre-fill selections:

• Keywords like "README", "CONTRIBUTING", "ARCHITECTURE" -> infer basic-markdown
• Keywords like "mkdocs", "docs site", "documentation site" -> infer mkdocs
• Keywords like "changelog", "release notes", "what changed" -> infer change-summary

If the intent is clear, present a summary for quick confirmation before proceeding (skip to Step 4). If ambiguous, proceed to Step 2.

Step 2 — Q1: Documentation type

If the documentation type is ambiguous or needs confirmation, prompt the user:

What type of documentation would you like to create?

Options:

• "MkDocs documentation site" — Full docs site with mkdocs.yml, Material theme
• "Basic markdown files" — Standalone files like README.md, CONTRIBUTING.md, ARCHITECTURE.md
• "Change summary" — Changelog, release notes, commit message

Store as DOC_TYPE = mkdocs | basic-markdown | change-summary.

Step 3 — Conditional follow-up questions

If DOC_TYPE = mkdocs:

Prompt the user — Existing project or new setup?

• "Existing MkDocs project" -> MKDOCS_MODE = existing
• "New MkDocs setup" -> MKDOCS_MODE = new

If existing: Prompt the user — What to do?

• "Generate new pages"
• "Update existing pages"
• "Both — generate and update"

Store as ACTION.

If new: Prompt the user — Scope?

• "Full documentation"
• "Getting started only (minimal init)"
• "Custom pages"

Store as MKDOCS_SCOPE. If custom, ask for desired pages (free text).

If DOC_TYPE = basic-markdown:

Prompt the user — Which files?

• "README.md"
• "CONTRIBUTING.md"
• "ARCHITECTURE.md"
• "API documentation"

Store as MARKDOWN_FILES. If "Other" is selected, ask for custom file paths/descriptions.

If DOC_TYPE = change-summary:

Prompt the user — What range?

• "Since last tag"
• "Between two refs"
• "Recent changes"

Follow up for specific range details (tag name, ref pair, etc.).

Step 4 — Confirm selections

Present a summary of all selections and prompt the user:

• "Proceed"
• "Change selections"

If the user wants to change, loop back to the relevant question. Then proceed to Phase 2.

Phase 2: Project Detection & Setup

Goal: Detect project context automatically, conditionally scaffold MkDocs.

Step 1 — Detect project metadata (all paths)

• Check manifests: package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml
• Execute: git remote get-url origin 2>/dev/null
• Note primary language and framework

Step 2 — Check existing documentation (all paths)

• Search for files matching docs/**/*.md, README.md, CONTRIBUTING.md, ARCHITECTURE.md
• For MkDocs: check for mkdocs.yml/mkdocs.yaml, read if found

Step 3 — MkDocs Initialization (only if DOC_TYPE = mkdocs AND MKDOCS_MODE = new)

1. Use this MkDocs configuration template:

```yaml site_name: PROJECT_NAME site_description: PROJECT_DESCRIPTION site_url: "" repo_url: REPO_URL repo_name: REPO_NAME

theme: name: material features:

• navigation.tabs
• navigation.sections
• navigation.expand
• navigation.top
• search.suggest
• search.highlight
• content.code.copy
• content.tabs.link

palette:

• scheme: default

primary: indigo accent: indigo toggle: icon: material/brightness-7 name: Switch to dark mode

• scheme: slate

primary: indigo accent: indigo toggle: icon: material/brightness-4 name: Switch to light mode

markdown_extensions:

• admonition
• pymdownx.details
• pymdownx.superfences:

custom_fences:

• name: mermaid

class: mermaid format: !!python/name:pymdownx.superfences.fence_code_format

• pymdownx.highlight:

anchor_linenums: true line_spans: __span pygments_lang_guess: false

• pymdownx.inlinehilite
• pymdownx.tabbed:

alternate_style: true

• pymdownx.snippets
• attr_list
• md_in_html
• toc:

permalink: true

nav:

• Home: index.md
• Getting Started: getting-started.md

```

Field population:

• site_name: From manifest (name in package.json, pyproject.toml, etc.) or directory name
• site_description: From manifest description field, or summarize from README
• repo_url: From git remote get-url origin (convert SSH to HTTPS if needed)
• repo_name: Extract owner/repo from the remote URL
• If not a git repository, omit repo_url and repo_name

1. Fill template with detected metadata (prompt the user if incomplete)
2. Generate mkdocs.yml, create docs/index.md and docs/getting-started.md
3. Present scaffold for confirmation before writing

If MKDOCS_SCOPE = minimal (getting started only): write the scaffold files and skip to Phase 6.

Step 4 — Set action-specific context (for update/change-summary)

For update modes, determine the approach:

• git-diff — Update docs affected by recent code changes
• full-scan — Compare all source code against all docs for gap analysis
• targeted — Update specific pages or sections

For change-summary, execute: git log and git diff --stat for the determined range.

Proceed to Phase 3.

Phase 3: Codebase Analysis

Goal: Deep codebase exploration using the deep-analysis skill.

Skip conditions:

• Skip for change-summary (uses git-based analysis instead — see below)
• Skip for MkDocs minimal init-only (MKDOCS_SCOPE = minimal)

Step 1 — Build documentation-focused analysis context

Construct a specific context string based on Phase 1 selections:

| Selection | Analysis Context | |-----------|-----------------| | MkDocs generate | "Documentation generation — find all public APIs, architecture, integration points, and existing documentation..." | | MkDocs update | "Documentation update — identify changes to public APIs, outdated references, documentation gaps..." | | Basic markdown README | "Project overview — understand purpose, architecture, setup, key features, configuration, and dependencies..." | | Basic markdown ARCHITECTURE | "Architecture documentation — map system structure, components, data flow, design decisions, key dependencies..." | | Basic markdown API docs | "API documentation — find all public functions, classes, methods, types, their signatures and usage patterns..." | | Basic markdown CONTRIBUTING | "Contribution guidelines — find dev workflow, testing setup, code style rules, commit conventions, CI process..." | | Multiple files | Combine relevant contexts from above |

Step 2 — Run deep-analysis

Refer to the deep-analysis skill (from the core-tools package) and follow its workflow. Pass the documentation-focused analysis context from Step 1.

Step 3 — Supplemental