majiayu000 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).