Get the FREE Ultimate OpenClaw Setup Guide →

ln-112-project-core-creator

Scanned
npx machina-cli add skill levnikolaevich/claude-code-skills/ln-112-project-core-creator --openclaw
Files (1)
SKILL.md
7.3 KB

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.

Project Core Documentation Creator

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

Purpose & Scope

  • Creates 4 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 (4)

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
docs/architecture/patterns_catalog.mdPattern summary, 4-score model, trend trackingHigh

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, patterns_catalog.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
      • For patterns_catalog.md:
        • Copy template from shared/templates/patterns_template.md
        • Auto-detect patterns in codebase:
          • Grep("Queue|Worker|Job|Bull") → Job Processing
          • Grep("EventEmitter|publish|subscribe") → Event-Driven
          • Grep("Cache|Redis|Memcached") → Caching
          • Grep("CircuitBreaker|Retry") → Resilience
        • Add detected patterns as "Status: Detected" (not yet audited)
        • Link to existing ADRs if pattern names match
        • Mark: <!-- Auto-detected by ln-112, audit with ln-640 -->
    • 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
  • 4 core documents created (or skipped if exist)
  • C4 diagrams generated (Context, Container, Component)
  • ADR links populated
  • Patterns auto-detected and added to catalog
  • Self-validation passed (SCOPE, sections, format)
  • Actuality verified: all document facts match current code (paths, functions, APIs, configs exist and are accurate)
  • Status returned to coordinator

Reference Files

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

Version: 2.2.0 Last Updated: 2025-01-12

Source

git clone https://github.com/levnikolaevich/claude-code-skills/blob/master/ln-112-project-core-creator/SKILL.mdView on GitHub

Overview

The Project Core Documentation Creator is an L3 Worker that always generates four essential docs for every project: requirements.md, architecture.md, tech_stack.md, and patterns_catalog.md. It receives a Context Store from the ln-110-project-docs-coordinator and performs auto-discovery, legacy content merging, and placeholder replacement to produce ready-to-use docs.

How This Skill Works

Triggered by the project docs coordinator, it first validates essential keys like PROJECT_NAME and TECH_STACK. For each document, it checks for existing files to maintain idempotency, then creates missing docs by pulling from templates, applying legacy content if present, and merging with auto-discovered data. It marks migrated sections when using legacy data.

When to Use It

  • Bootstrapping a new project and generating all four core docs automatically
  • Migrating an older project using LEGACY_CONTENT to seed requirements, architecture, or tech details
  • Coordinating documentation in a multi-step pipeline where existing files must not be overwritten
  • Ensuring documentation exists even if a project type uses nonstandard tech stacks
  • Conducting a full documentation refresh by combining legacy content with live discovery

Quick Start

  1. Step 1: Ensure ln-110-project-docs-coordinator can provide a full contextStore
  2. Step 2: Run the ln-112-project-core-creator worker and let it create missing docs
  3. Step 3: Review docs under docs/project and docs/architecture/patterns_catalog.md for migrated content and placeholders

Best Practices

  • Ensure the coordinator provides a complete contextStore before invocation
  • Keep templates in references/templates up to date and aligned with project standards
  • Prefer legacy content when present, but give priority to auto-discovered data where needed
  • Verify idempotence by checking for existing files before creation
  • Review architecture and requirements sections for accuracy and placeholder replacements

Example Use Cases

  • Bootstrapping a new microservice with all four docs created automatically
  • Migrating a legacy project by seeding docs with legacy_architecture and legacy_requirements
  • Generating architecture.md with complete arc42 sections and C4 diagrams
  • Populating tech_stack.md with frontend, backend, and database versions
  • Creating a patterns_catalog.md to capture observed design patterns and trends

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers