ln-112-project-core-creator

安装量: 113
排名: #7587

安装

npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-112-project-core-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)

| docs/project/requirements.md | Functional Requirements (FR-XXX-NNN format) | Q23 | Low

| docs/project/architecture.md | 11 arc42 sections with C4 diagrams | Q24-Q34 | High

| docs/project/tech_stack.md | Frontend, Backend, Database, Additional | Q35-Q38 | High

Workflow

Phase 1: Receive Context

  • Parse full Context Store from coordinator

  • Validate required keys (PROJECT_NAME, TECH_STACK)

  • Extract architecture-specific data (SRC_STRUCTURE, DEPENDENCIES)

Phase 2: Create Documents

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

  • Check if file exists (idempotent)

  • If exists: skip with log

  • 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:

  • Check SCOPE tag in first 10 lines

  • Check required sections (from questions_core.md)

  • 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

  • Check Maintenance section

  • 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

返回排行榜