Paths: File paths (references/, ../ln-*) are relative to this skill directory.

Type: L1 Top Orchestrator Category: 1XX Documentation Pipeline

Documentation Pipeline (Orchestrator)

This skill orchestrates the creation of a complete documentation system by invoking one L2 coordinator plus 3 L2 workers. The coordinator (ln-110) delegates to 5 L3 workers for project docs; other L2 workers handle reference, tasks, and test domains. Each component validates its own output, and the orchestrator owns the final docs-quality acceptance gate.

Purpose

Top-level orchestrator that creates a complete project documentation system in one invocation. Chains ln-110 coordinator + ln-120/130/140 workers sequentially, then runs global cleanup (deduplication, orphan reporting, cross-link validation).

Runtime Contract

MANDATORY READ: Load references/coordinator_runtime_contract.md, references/docs_pipeline_runtime_contract.md, references/docs_generation_summary_contract.md

Runtime family: docs-pipeline-runtime

Identifier:

• docs-pipeline

Phases:

1. PHASE_0_CONFIG
2. PHASE_1_LEGACY_SCAN
3. PHASE_2_CONFIRMATION
4. PHASE_3_DELEGATE
5. PHASE_4_QUALITY_GATE
6. PHASE_5_CLEANUP
7. PHASE_6_SELF_CHECK

Component summary contract:

• ln-110, ln-120, ln-130, ln-140 write or return docs-generation envelopes
• ln-100 consumes those summaries plus docs-quality checkpoints as orchestration SSOT

Architecture

ln-100-documents-pipeline (L1 Top Orchestrator - this skill)
|- ln-110-project-docs-coordinator (L2 Coordinator)
|  |- ln-111-root-docs-creator (L3 Worker) -> 5 docs
|  |- ln-112-project-core-creator (L3 Worker) -> 3 docs
|  |- ln-113-backend-docs-creator (L3 Worker) -> 2 conditional
|  |- ln-114-frontend-docs-creator (L3 Worker) -> 1 conditional
|  `- ln-115-devops-docs-creator (L3 Worker) -> 1 always + 1 conditional
|- ln-120-reference-docs-creator (L2 Worker)
|- ln-130-tasks-docs-creator (L2 Worker)
`- ln-140-test-docs-creator (L2 Worker - optional)

When to Use This Skill

This skill should be used when:

• Start a new IT project and need complete documentation system at once
• Use automated workflow instead of manually invoking multiple workers
• Create entire documentation structure (AGENTS.md canonical + CLAUDE.md import stub -> docs/) in one go
• Prefer orchestrated CREATE path over manual skill chaining
• Need automatic global cleanup (deduplication, orphaned files, consolidation)

Alternative: If you prefer granular control, invoke workers manually:

1. ln-110-project-docs-coordinator - Root + Project docs (coordinates 5 L3 workers)
2. ln-120-reference-docs-creator - reference/ structure
3. ln-130-tasks-docs-creator - tasks/README.md + kanban
4. ln-140-test-docs-creator - tests/README.md (optional)

MANDATORY READ: Load references/docs_quality_contract.md.

Note: Each worker validates its own local output in Phase 2/3. The orchestrator still owns the final docs-quality manifest, verification, and repair loop before cleanup can continue.

Workflow

The skill follows a 5-phase orchestration workflow: Legacy Migration (optional) -> User confirmation -> Invoke coordinator + workers sequentially -> Global cleanup -> Summary.

Phase 0: Source Documentation Cleanup (OPTIONAL)

Objective: Detect non-canonical documentation, normalize any useful facts, and remove duplicate documentation paths before generation.

Trigger: Runs at pipeline start when the repo already contains documentation outside the canonical layout.

Process:

0a. Non-Canonical Source Detection:

• Scan project for non-standard documentation using patterns from references/legacy_detection_patterns.md:
  • Root .md files: ARCHITECTURE.md, REQUIREMENTS.md, STACK.md, API.md, DATABASE.md, DEPLOYMENT.md
  • Non-canonical folders: documentation/, doc/, wiki/, or docs/ with wrong structure
  • README.md sections: ## Architecture, ## Tech Stack, ## Requirements, etc.
  • CONTRIBUTING.md sections: ## Development, ## Code Style, ## Coding Standards
• Build source_manifest: list of { path, detected_type, target_doc, confidence }
• If no non-canonical docs are found -> skip to Phase 1

0b. Fact Extraction:

• For each detected source file:
  • Parse markdown structure (headers, lists, code blocks)
  • Apply type-specific extractor (MANDATORY READ: Load references/legacy_detection_patterns.md):
    • architecture_extractor -> { layers[], components[], diagrams[] }
    • requirements_extractor -> { functional[], non_functional[] }
    • tech_stack_extractor -> { frontend, backend, database, versions }
    • principles_extractor -> { principles[], anti_patterns[] }
    • api_spec_extractor -> { endpoints[], authentication }
    • database_schema_extractor -> { tables[], relationships[] }
    • runbook_extractor -> { prerequisites[], install_steps[], env_vars[] }
    • infrastructure_extractor -> { servers[], domains[], ports[], services[], artifacts{}, cicd{} }
  • Score content quality (0.0-1.0)
• Store results in source_notes

0c. User Confirmation:

• Display detected non-canonical files:

  Non-Canonical Documentation Detected:
  
  | File | Type | Confidence | Target |
  |------|------|------------|--------|
  | README.md (## Architecture) | architecture | HIGH | docs/project/architecture.md |
  | docs/ARCHITECTURE.md | architecture | HIGH | docs/project/architecture.md |
  | CONTRIBUTING.md (## Development) | principles | MEDIUM | docs/principles.md |
  
  Cleanup Options:
  1. NORMALIZE (recommended): Extract facts -> Archive -> Remove duplicate sources
  2. ARCHIVE ONLY: Backup without extraction
  3. SKIP: Leave non-canonical docs as-is (may cause duplication)
  
  Choose option (1/2/3): _
  

• If user selects "1" (NORMALIZE):
  • Optional: "Review extracted facts before folding them into the canonical context? (yes/no)"
  • Confirm: "Proceed with cleanup and archive non-canonical files?"
• If user selects "2" (ARCHIVE ONLY):
  • Confirm: "Archive non-canonical files to .archive/? Content will NOT be normalized."
• If user selects "3" (SKIP):
  • Warn: "Non-canonical files will remain. This may cause duplication issues."
  • Proceed to Phase 1

0d. Backup and Archive:

• Create .archive/source-docs-{timestamp}/ directory
• Structure:

  .archive/
  `- source-docs-YYYY-MM-DD-HHMMSS/
      |- README_cleanup.md          # Rollback instructions
      |- original/                  # Exact copies of non-canonical files
      |  |- README.md
      |  |- ARCHITECTURE.md
      |  `- documentation/
      `- extracted/                 # Extracted facts (for reference)
          |- architecture_content.md
          `- principles_content.md
  

• Copy all detected source files to original/
• Save extracted facts to extracted/
• Generate README_cleanup.md with rollback instructions

0e. Context Normalization:

• Build SOURCE_DOC_NOTES from extracted facts:

  {
    "SOURCE_DOC_NOTES": {
      "architecture_notes": { "sections": [...], "diagrams": [...] },
      "requirements_notes": { "functional": [...] },
      "principles_notes": { "principles": [...] },
      "tech_stack_notes": { "frontend": "...", "backend": "..." },
      "api_notes": { "endpoints": [...] },
      "database_notes": { "tables": [...] },
      "runbook_notes": { "install_steps": [...] },
      "infrastructure_notes": { "servers": [...], "domains": [...], "ports": {} }
    }
  }
  

• Merge extracted facts into the coordinator input as supporting evidence only
• Workers consume normalized context fields and current source facts directly; there is no legacy-only branch
• Priority order: **Current source facts + normalized project documentatio