ln-112-project-core-creator

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

Project Core Documentation Creator

Type: L3 Worker

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/)
• targetDir: Project root directory

MANDATORY READ: Load references/docs_quality_contract.md, and references/markdown_read_protocol.md. Optional rule catalog: load references/docs_quality_rules.json only when exact rule IDs, path matrices, or allowlisted placeholder exceptions are needed.

Documents Created (4)

| File | Target Sections | Questions | Auto-Discovery | |------|-----------------|-----------|----------------| | 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 | | docs/architecture/patterns_catalog.md | Pattern summary, 4-score model, trend tracking | — | High |

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 (docs/project/requirements.md, docs/project/architecture.md, docs/project/tech_stack.md, docs/architecture/patterns_catalog.md):

1. Check if file exists (idempotent)
2. If exists: skip with log
3. If not exists:
4. Copy template from references/templates/
5. docs/project/requirements.md: derive requirements from current product/project sources and normalize to FR-XXX structure
6. docs/project/architecture.md: derive structure from current source tree, ADRs, and runtime boundaries; generate diagrams from live code facts
7. docs/project/tech_stack.md: derive versions and rationale from current dependencies and config files
8. docs/architecture/patterns_catalog.md:
9. Copy template from references/templates/patterns_template.md
10. Auto-detect patterns in the current codebase:
11. Grep("Queue|Worker|Job|Bull") → Job Processing
12. Grep("EventEmitter|publish|subscribe") → Event-Driven
13. Grep("Cache|Redis|Memcached") → Caching
14. Grep("CircuitBreaker|Retry") → Resilience
15. Add detected patterns as "Status: Detected" (not yet audited)
16. Link to existing ADRs if pattern names match
17. Mark: <!-- Auto-detected by ln-112, audit with ln-640 -->
18. Replace {{PLACEHOLDER}} with Context Store values
19. Preserve the shared opening contract: SCOPE, DOC_KIND, DOC_ROLE, READ_WHEN, SKIP_WHEN, PRIMARY_SOURCES
20. Preserve the standard top sections: Quick Navigation, Agent Entry, Maintenance
21. Generate C4 diagrams from SRC_STRUCTURE (for architecture.md, if no legacy diagrams)
22. Insert ADR links (for architecture.md Section 8)
23. Never leave template markers in published project docs
24. If data is missing: omit the claim or use a concise neutral fallback, but do NOT emit [TBD: ...]

Phase 3: Self-Validate

For each created document:

1. Check SCOPE tag and metadata markers in the opening block
2. Check required top sections (Quick Navigation, Agent Entry, Maintenance)
3. Check required sections (from questions_core.md)
4. Validate specific format requirements:
5. requirements.md: FR-XXX identifiers, MoSCoW labels
6. architecture.md: 11 sections, C4 diagrams, ADR references
7. tech_stack.md: versions, rationale for each technology
8. Check docs-quality contract compliance (no forbidden placeholders, no leaked template metadata, valid doc kind/role)
9. Auto-fix issues where possible

Phase 4: Return Status

Return to coordinator:

{
  "created_files": ["docs/project/requirements.md", "docs/project/architecture.md", "docs/project/tech_stack.md", "docs/architecture/patterns_catalog.md"],
  "skipped_files": [],
  "quality_inputs": {
    "doc_paths": ["docs/project/requirements.md", "docs/project/architecture.md", "docs/project/tech_stack.md", "docs/architecture/patterns_catalog.md"],
    "owners": {
      "docs/project/requirements.md": "ln-112-project-core-creator",
      "docs/project/architecture.md": "ln-112-project-core-creator",
      "docs/project/tech_stack.md": "ln-112-project-core-creator",
      "docs/architecture/patterns_catalog.md": "ln-112-project-core-creator"
    }
  },
  "validation_status": "passed",
  "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
• Publishable output: Core project docs must not contain [TBD: ...], TODO, or leaked template metadata

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

Runtime Summary Artifact

MANDATORY READ: Load references/docs_generation_summary_contract.md

Accept optional summaryArtifactPath.

Summary kind:

• docs-generation

Required payload semantics:

• worker = "ln-112"
• status
• created_files
• skipped_files
• quality_inputs
• validation_status
• warnings

Write the summary to the provided artifact path or return the same envelope in structured output.

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 (metadata markers, top sections, format)
• [ ] Actuality verified: all document facts match current code (paths, functions, APIs, configs exist and are accurate)
• [ ] Status returned

Reference Files

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

Version: 2.2.0 Last Updated: 2025-01-12