Docs Manager

Documentation Manager (Internal Engine)

Internal skill that manages documentation file operations in .maister/docs/. Not directly user-invocable — called by maister-init, standards-update, and standards-discover skills.

Core Principles

• Project documentation is source of truth — plugin-bundled docs are baseline/reference only
• INDEX.md is the master map — always kept up-to-date after changes
• .github/copilot-instructions.md integration is mandatory — ensures AI reads documentation

Documentation Structure

.maister/docs/
├── INDEX.md                      # Master index - READ THIS FIRST
├── project/                      # Project-level documentation (generated by maister-init, not copied from templates)
│   ├── vision.md                # Project vision and goals
│   ├── roadmap.md               # Development roadmap
│   ├── tech-stack.md            # Technology choices and rationale
│   └── architecture.md          # System architecture (optional)
└── standards/                    # Technical standards and conventions
    ├── global/                  # Language-agnostic standards
    │   ├── error-handling.md
    │   ├── validation.md
    │   ├── conventions.md
    │   ├── coding-style.md
    │   └── commenting.md
    ├── frontend/                # Frontend-specific standards
    │   ├── css.md
    │   ├── components.md
    │   ├── accessibility.md
    │   └── responsive.md
    ├── backend/                 # Backend-specific standards
    │   ├── api.md
    │   ├── models.md
    │   ├── queries.md
    │   └── migrations.md
    └── testing/                 # Testing standards
        └── test-writing.md

Standard File Conventions

Standard files follow the structure standards/[category]/[topic].md:

• Category = domain folder (global, frontend, backend, testing, or custom)
• Topic file = contains multiple related standards

Format: Each file uses ## Topic as the file heading, with ### Standard Name for each individual standard. Each standard has a 1-10 line description (excluding code snippets) and an optional brief code example (under 10 lines).

Conciseness: Standards are quick-reference conventions, not tutorials. If a file grows unwieldy, split into focused sub-topic files.

Why ### per standard: Each standard as a discrete section makes it easier for agents to find, update, and reference individually — no need to parse bullet lists.

Bundled Resources

This skill bundles the following resources within the plugin:

• Standards Directory: Contains baseline technical standards organized by category:
  • global/ - Global standards (error handling, validation, conventions, etc.)
  • frontend/ - Frontend-specific standards (CSS, components, accessibility, etc.)
  • backend/ - Backend-specific standards (API design, database, queries, etc.)
  • testing/ - Testing standards (test writing, coverage, etc.)
• INDEX.md Template: Master template for documentation index

Location Reference

• Plugin bundles (read-only baseline): This skill's docs/ subdirectory within the plugin
• Project documentation (source of truth): .maister/docs/ in the project root
• Project configuration: .github/copilot-instructions.md in the project root

Capabilities

1. Initialize Documentation in Project

Use this when a project doesn't have .maister/docs/ or needs documentation for the first time. This is a one-time baseline setup that gives the project a starting point.

IMPORTANT: This operation accepts an optional standards_selection parameter (array of standard categories) to control which standards to initialize. If not provided, all standards are copied (backward compatible). It also accepts an optional standards_source_path parameter to copy standards from an external project instead of the bundled defaults.

What to do:

1. Check if .maister/docs/ exists in the project root
2. If it exists, warn the user that initialization will overwrite existing documentation and ask for confirmation
3. Create the directory structure based on standards_selection:

   .maister/docs/
   ├── project/
   └── standards/
       ├── global/      (if 'global' in standards_selection or no selection provided)
       ├── frontend/    (if 'frontend' in standards_selection or no selection provided)
       ├── backend/     (if 'backend' in standards_selection or no selection provided)
       └── testing/     (if 'testing' in standards_selection or no selection provided)
   

4. Copy standards to the project's .maister/docs/standards/ directory. Source selection: If standards_source_path is provided, copy from that external path. Otherwise, copy from this skill's bundled docs/standards/ directory:
   • Project documentation: Do NOT copy project templates — only create the project/ directory. Project documentation files (vision, roadmap, tech-stack, architecture) are generated by the calling skill (e.g., maister-init) using analyzer data, not copied as placeholder templates.
   • Standards: Only copy selected standard categories based on standards_selection parameter:
     • If standards_selection is empty or not provided: Copy ALL standards (backward compatible)
     • If standards_selection is provided: Only copy specified categories
     • Examples:
       • ['global', 'frontend', 'testing'] → Copy only these three categories
       • ['global', 'backend', 'testing'] → Skip frontend standards
       • ['global', 'testing'] → Only global and testing standards
5. Generate INDEX.md with entries for all copied documentation (see "Manage INDEX.md" operation):
   • For skipped standard categories, add placeholder sections with "Not initialized - run standards discovery if needed"
   • Example: If frontend standards are skipped, INDEX.md shows:

     ### Frontend Standards
     
     *Not initialized for this project. If you need frontend standards, you can:*
     - *Add them manually using the docs-manager skill*
     - *Run `/maister-standards-discover --scope=frontend` to auto-discover*
     

6. MANDATORY - Update .github/copilot-instructions.md:
   • Check if .github/copilot-instructions.md exists in the project root; if not, ask the user if they want to create it
   • Add the documentation reference section (see "Manage .github/copilot-instructions.md Integration" operation)
   • Ensure it emphasizes reading INDEX.md at the beginning of any task
7. Inform the caller about the documentation structure created

Parameters:

• standards_selection (optional, array of strings): Standard categories to initialize
  • Array of category names (e.g., ['global', 'frontend', 'backend', 'testing']). Baseline categories: global, frontend, backend, testing. Custom categories are also supported.
  • If omitted or empty: Initialize all baseline standards (backward compatible)
  • If provided: Only initialize specified categories (creates directories for custom ones)
• standards_source_path (optional, string): Absolute path to an external standards directory (e.g., /path/to/other-project/.maister/docs/standards/)
  • If provided: Copy standards from this path instead of the bundled defaults
  • If omitted: Copy from this skill's bundled docs/standards/ directory (default behavior)

Result: The project now has baseline documentation in .maister/docs/, a comprehensive INDEX.md, and .github/copilot-instructions.md integration that ensures AI assistance is documentation-aware. Only selected standard categories are initialized.

Important: After this initial setup, the project's documentation becomes the source of truth. Teams should customize it for their specific needs.

Note on Skipped Standards: If standard categories are skipped during initialization, teams can add them later using:

• "Add Documentation File" operation to add specific standards
• /maister-standards-discover command to auto-discover standards from codebase

2. Manage INDEX.md

Use this to create or update the INDEX.md file that serves as the master documentation map.

What to do:

1. Scan the .maister/docs/ directory structure
2. For each documentation file found:
   • Read the file content to extract description
   • Determine the file's purpose and category
   • For technical standards: The description MUST enumerate the specific practices/conventions documented in the file, not just a generic category description.
3. Read references/index-md-template.md for the INDEX.md structure template
4. Generate INDEX.md by populating the template with discovered files and descriptions
5. Write the generated INDEX.md to .maister/docs/INDEX.md
6. Verify that .github/copilot-instructions.md references this index (see "Manage .github/copilot-instructions.md Integration" operation)

Result: A comprehensive, up-to-date INDEX.md that provides a clear map of all project documentation.

3. Add Documentation File

Use this to add new documentation to the project, either from plugin baseline or custom.

What to do:

1. Determine the type of documentation to add:
   • Project documentation (vision, roadmap, tech-stack, architecture, custom)
   • Technical standard (any category under standards/)
2. If adding from plugin baseline:
   • Check if the requested documentation exists in this skill's bundled docs/ directory
   • Copy it to the appropriate location in .maister/docs/
3. If creating custom documentation:
   • Ask for the category (project/ or standards/category/)
   • Ask for the filename and purpose
   • Create a template file with appropriate frontmatter and structure
4. Update INDEX.md to include the new documentation (see "Manage INDEX.md" operation)
5. If this is a technical standard and corresponds to a Claude Code Skill, ensure consistency

Result: New documentation is added to the project and indexed in INDEX.md.

4. Update Documentation

Use this to help the user update or modify existing project documentation.

What to do:

1. Accept the documentation identifier from the user (e.g., "project/vision", "standards/global/error-handling")
2. Check if the documentation exists in .maister/docs/
3. If the documentation exists:
   • Read the current documentation
   • Ask the user what they want to change or update
   • Help them edit the documentation file directly
   • Optionally, show them the plugin's baseline version for reference if they ask
4. If the documentation doesn't exist:
   • Offer to add it from the plugin baseline (see "Add Documentation File" operation)
   • Or offer to help them create custom documentation from scratch
5. After updating:
   • Check if INDEX.md needs updating (if the purpose/description changed significantly)
   • If updating tech-stack.md or architecture.md, suggest reviewing .github/copilot-instructions.md for consistency
6. For technical standards:
   • If a corresponding Claude Code Skill exists, suggest reviewing it for consistency
   • Standards should align with actual code patterns in the project

Result: Documentation is updated to reflect current project state and team decisions.

5. Use Plugin Documentation as Reference

Use this when a team wants to see the plugin's baseline documentation for reference, or reset specific docs to plugin defaults.

What to do:

1. Compare the documentation in this skill's bundled docs/ directory with the project's .maister/docs/ directory to identify differences
2. Show the user which documents differ and how they differ
3. Explain that plugin documentation is baseline/reference only, and project documentation is superior
4. WARNING: Copying plugin documentation to the project will overwrite any project-specific customizations
5. Ask the user if they want to:
   • View the differences for reference only (no changes)
   • Reset specific documentation to plugin baseline (selective overwrite)
   • Reset all documentation to plugin baseline (full overwrite - rarely recommended)
6. If the user chooses to copy any documentation:
   • Copy the selected files from this skill's bundled docs/ directory to the project's .maister/docs/ directory
   • Update INDEX.md to reflect any changes
   • Review .github/copilot-instructions.md for any necessary updates

Important: This operation should be used rarely, mainly when a team wants to reset to baseline. Project documentation is the source of truth and should be maintained by the team.

Result: User can reference plugin baseline documentation and optionally reset specific docs to plugin versions.

6. List Available Documentation

Use this to show what documentation is bundled with this plugin and their installation status in the project.

What to do:

1. List all documentation in this skill's bundled docs/ directory, organized by category
2. For each bundled document:
   • Show the category and name
   • Check if it exists in the project at .maister/docs/[category]/[name].md
   • Show installation status (bundled only, installed, or customized)
   • If installed, show whether it differs from the baseline (customized)
3. Show whether INDEX.md exists and is up-to-date
4. Show whether .github/copilot-instructions.md has documentation integration
5. Remind the user that plugin documentation is baseline/reference only, and project documentation (if installed) is the source of truth

Result: The user sees a complete inventory of available baseline documentation and their installation status in the current project.

7. Manage .github/copilot-instructions.md Integration

Use this to ensure the project's .github/copilot-instructions.md properly integrates with the documentation system, encouraging AI to read and use the documentation.

What to do:

1. Check if .github/copilot-instructions.md exists in the project root
2. If it doesn't exist, ask the user if they want to create it
3. Look for a documentation reference section in .github/copilot-instructions.md
4. If the section doesn't exist or is incomplete:
   • Read references/claude-md-template.md for the template
   • Add the template section to .github/copilot-instructions.md
5. Ensure the documentation section is placed prominently in .github/copilot-instructions.md (near the top)
6. Verify that the INDEX.md path is correct and the file exists
7. If .maister/docs/ doesn't exist, suggest running the initialization operation first

Result: .github/copilot-instructions.md properly integrates with the documentation system, ensuring AI assistance is documentation-aware and follows team conventions.

8. Validate Documentation Consistency

Use this to check that documentation is consistent, up-to-date, and properly integrated.

What to do:

1. Check structure:
   • Verify .maister/docs/ directory exists
   • Verify all expected subdirectories exist (project/, standards/global/, etc.)
2. Check INDEX.md:
   • Verify it exists and is readable
   • Check that all files in .maister/docs/ are listed in INDEX.md
   • Check that all files listed in INDEX.md actually exist
   • Report any orphaned files or broken references
3. Check .github/copilot-instructions.md integration:
   • Verify .github/copilot-instructions.md exists
   • Verify it contains documentation reference section
   • Verify it uses valid file reference format: @.maister/docs/INDEX.md (with @ prefix, without backticks)
   • Warn if using incorrect formats like .maister/docs/INDEX.md or @.maister/docs/INDEX.md (backticks)
4. Check project documentation:
   • Verify critical files exist (vision.md, tech-stack.md)
   • Check if they contain placeholder text vs. actual project information
   • Warn if critical documentation is missing or empty
5. Check standards consistency:
   • If Claude Code Skills exist, check if corresponding standards documentation exists
   • If standards exist without skills, suggest creating skills (if appropriate)
   • Report any inconsistencies
6. Generate validation report:
   • Summary of documentation status
   • List of issues found
   • Recommendations for fixes
7. Offer to fix issues:
   • Ask if the user wants to automatically fix found issues
   • Fix missing INDEX.md entries
   • Fix missing .github/copilot-instructions.md integration
   • Create missing directory structure

Result: A comprehensive validation report with optional automatic fixes for common issues.

Usage Examples

Initialize documentation in a new project:

User: "Set up documentation for this project"
Claude: [Executes Initialize Documentation - creates structure, copies baseline docs, generates INDEX.md, updates .github/copilot-instructions.md, gathers project info]

Update project vision:

User: "I want to update our project vision to include AI-first approach"
Claude: [Executes Update Documentation - reads current vision.md, helps user edit it, updates INDEX.md if needed]

Add custom documentation:

User: "Add documentation for our deployment process"
Claude: [Executes Add Documentation File - creates custom project/deployment.md, updates INDEX.md]

Reference plugin baseline:

User: "Show me the plugin's baseline error handling standard"
Claude: [Executes Use Plugin Documentation as Reference - shows plugin baseline, compares with project version, no changes unless user requests]

Validate documentation:

User: "Check if our documentation is complete and consistent"
Claude: [Executes Validate Documentation Consistency - checks structure, INDEX.md, .github/copilot-instructions.md integration, generates report]

Manage INDEX.md:

User: "Rebuild the documentation index"
Claude: [Executes Manage INDEX.md - scans .maister/docs/, regenerates comprehensive INDEX.md]

Important Notes

• Project documentation is source of truth — plugin-bundled docs are baseline/reference only
• INDEX.md must stay current — regenerate after any documentation change
• .github/copilot-instructions.md integration is mandatory — ensures AI reads documentation at task start
• This skill is an internal engine — called by maister-init, standards-update, and standards-discover. Not directly user-invocable.
• CRITICAL: Return control after completion — This is an internal sub-skill. After completing the requested operation, return control to the calling workflow. Do NOT treat completion of this skill as the end of the conversation turn — the parent skill has more steps to execute.

Source: SkillPanel/maister — distributed by TomeVault.