Claude-skill-registry ln-112-project-core-creator

Creates 3 core project docs (requirements.md, architecture.md, tech_stack.md). L3 Worker invoked by ln-110-project-docs-coordinator. ALWAYS created.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/levn-ln-112-project-core-creator" ~/.claude/skills/majiayu000-claude-skill-registry-ln-112-project-core-creator && rm -rf "$T"
manifest: skills/data/levn-ln-112-project-core-creator/SKILL.md
source content

Project Core Documentation Creator

L3 Worker that creates 3 core project documentation files. These are ALWAYS created regardless of project type.

Purpose & Scope

  • Creates 3 core project documentation files (required for all projects)
  • Receives Context Store from ln-110-project-docs-coordinator
  • Heavy use of auto-discovery (architecture needs full project scan)
  • Replaces placeholders with project-specific data
  • Self-validates structure and content (16 questions)
  • Never gathers context itself; uses coordinator input

Invocation (who/when)

  • ln-110-project-docs-coordinator: ALWAYS invoked as second worker (after ln-111)
  • Never called directly by users

Inputs

From coordinator:

  • contextStore
    : Full Context Store with all discovered data
    • PROJECT_NAME, PROJECT_DESCRIPTION
    • TECH_STACK (full object: frontend, backend, database, etc.)
    • DEPENDENCIES (from package.json)
    • SRC_STRUCTURE (folder analysis)
    • EXTERNAL_SYSTEMS (from .env.example)
    • CODE_CONVENTIONS (from eslint, prettier)
    • ADR_LIST (from docs/reference/adrs/)
    • LEGACY_CONTENT (optional, from ln-100 Phase 0 migration):
      • legacy_architecture
        : { layers[], components[], diagrams[], data_flow }
      • legacy_requirements
        : { functional[], non_functional[], user_stories[] }
      • legacy_tech_stack
        : { frontend, backend, database, versions }
  • targetDir
    : Project root directory

LEGACY_CONTENT is used as base content when creating documents. Priority: Legacy > Auto-discovery > Template defaults.

Documents Created (3)

FileTarget SectionsQuestionsAuto-Discovery
docs/project/requirements.mdFunctional Requirements (FR-XXX-NNN format)Q23Low
docs/project/architecture.md11 arc42 sections with C4 diagramsQ24-Q34High
docs/project/tech_stack.mdFrontend, Backend, Database, AdditionalQ35-Q38High

Workflow

Phase 1: Receive Context

  1. Parse full Context Store from coordinator
  2. Validate required keys (PROJECT_NAME, TECH_STACK)
  3. Extract architecture-specific data (SRC_STRUCTURE, DEPENDENCIES)

Phase 2: Create Documents

For each document (requirements.md, architecture.md, tech_stack.md):

  1. Check if file exists (idempotent)
  2. If exists: skip with log
  3. If not exists:
    • Copy template from
      references/templates/
    • Check LEGACY_CONTENT for this document type:
      • For
        architecture.md
        : If
        LEGACY_CONTENT.legacy_architecture
        exists:
        • Use
          legacy_architecture.layers[]
          for "## Building Block View" (Section 5)
        • Use
          legacy_architecture.components[]
          for component descriptions
        • Use
          legacy_architecture.diagrams[]
          for existing diagrams (preserve mermaid/images)
        • Use
          legacy_architecture.data_flow
          for "## Runtime View" (Section 6)
        • Merge with auto-discovered SRC_STRUCTURE (legacy takes priority)
        • Mark:
          <!-- Migrated from legacy documentation -->
          at top of merged sections
      • For
        requirements.md
        : If
        LEGACY_CONTENT.legacy_requirements
        exists:
        • Use
          legacy_requirements.functional[]
          as base for FR-XXX requirements
        • Use
          legacy_requirements.user_stories[]
          if FR format not found
        • Augment with template structure (add MoSCoW labels if missing)
      • For
        tech_stack.md
        : If
        LEGACY_CONTENT.legacy_tech_stack
        exists:
        • Use
          legacy_tech_stack.versions
          as base for technology versions
        • Merge with auto-discovered TECH_STACK (legacy versions take priority)
        • Use
          legacy_tech_stack.rationale
          for decision explanations
    • Replace
      {{PLACEHOLDER}}
      with Context Store values
    • Generate C4 diagrams from SRC_STRUCTURE (for architecture.md, if no legacy diagrams)
    • Insert ADR links (for architecture.md Section 8)
    • Mark
      [TBD: X]
      for missing data

Phase 3: Self-Validate

For each created document:

  1. Check SCOPE tag in first 10 lines
  2. Check required sections (from questions_core.md)
  3. Validate specific format requirements:
    • requirements.md: FR-XXX identifiers, MoSCoW labels
    • architecture.md: 11 sections, C4 diagrams, ADR references
    • tech_stack.md: versions, rationale for each technology
  4. Check Maintenance section
  5. Auto-fix issues where possible

Phase 4: Return Status

Return to coordinator:

{
  "created": ["docs/project/requirements.md", ...],
  "skipped": [],
  "tbd_count": 5,
  "validation": "OK",
  "diagrams_generated": 3
}

Critical Notes

  • Idempotent: Never overwrite existing files
  • Heavy auto-discovery: architecture.md requires deep project analysis
  • C4 diagrams: Generated from SRC_STRUCTURE in Mermaid format
  • ADR integration: Section 8 links to docs/reference/adrs/
  • arc42 compliance: ISO/IEC/IEEE 42010:2022 structure
  • TBD markers: Use
    [TBD: X]
    for missing data

NO_CODE_EXAMPLES Rule (MANDATORY)

Documents describe contracts and decisions, NOT implementations:

  • FORBIDDEN: Code blocks > 5 lines, function implementations, imports, DI configuration
  • ALLOWED: Mermaid diagrams, component tables, method signatures (1 line), ADR links
  • INSTEAD OF CODE: Reference source: "See src/Services/UserService.cs:45"
  • TEMPLATE RULE: All templates include
    <!-- NO_CODE_EXAMPLES: ... -->
    tag - FOLLOW IT

Stack Adaptation Rule (MANDATORY)

  • Links must reference stack-appropriate docs (Microsoft for .NET, MDN for JS)
  • Never mix stack references (no Python examples in .NET project)

Format Priority (MANDATORY)

Tables > Mermaid/ASCII diagrams > Lists > Text

Definition of Done

  • Context Store received and validated
  • 3 core documents created (or skipped if exist)
  • C4 diagrams generated (Context, Container, Component)
  • ADR links populated
  • Self-validation passed (SCOPE, sections, format)
  • Status returned to coordinator

Reference Files

  • Templates:
    references/templates/requirements_template.md
    ,
    architecture_template.md
    ,
    tech_stack_template.md
  • Questions:
    references/questions_core.md
    (Q23-Q38)

Version: 2.2.0 (Added Stack Adaptation and Format Priority rules) Last Updated: 2025-01-12