Use this skill when you are authoring or updating go-lcpd design documentation (the “What You See Is What It Does” / WYSIWID pattern).
References (in-repo)
- •
go-lcpd/WhatYouSeeIsWhatItDoes.md(background and rationale)
WYSIWID model (summary)
- •A Concept is an independent capability. Concepts must not depend on each other.
- •A Synchronization connects Concepts into an end-to-end flow/story.
Writing rules (must follow)
- •Start with invariants (“Security & Architectural Constraints”). Use RFC 2119 language (MUST / MUST NOT) and include brief rationales.
- •Keep Concepts dependency-free:
- •A Concept MUST NOT call actions from other Concepts.
- •A Concept MUST NOT reference other Concepts’ types.
- •Cross-Concept coordination belongs only in Synchronizations.
- •Keep structure flat and scannable; prefer short lists, signatures, and data-shape bullets over long prose.
- •Use a ubiquitous language: keep terminology consistent across docs and Go identifiers where possible.
Suggested section order (for spec.md)
- •Security & Architectural Constraints
- •Concepts
- •Synchronizations
Example template (shape)
- •
### <ConceptName>- •Purpose: …
- •Domain Model:
Thing: field, field - •Actions:
action(arg) -> out(include side effects + error cases)
- •
### sync <SyncName>- •Summary: …
- •Flow: when / where / then (include error branches)
If the flow is complex, add a Mermaid sequence diagram or state chart.
Validation
- •Ensure the doc can be read as the “ubiquitous language” for the relevant code.
- •If the doc implies behavior changes, implement them and validate with the module’s normal test/lint flow (see
$lcp-go-lcpd).