OpenSkillIndex← back to search
claude-codedevelopment

Claude-skill-registry lcp-wysiwid-spec

Write WYSIWID-style design docs (Concepts + Synchronizations) for go-lcpd, keeping terminology consistent with code.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/lcp-wysiwid-spec" ~/.claude/skills/majiayu000-claude-skill-registry-lcp-wysiwid-spec && rm -rf "$T"
manifest: skills/data/lcp-wysiwid-spec/SKILL.md
tags
#design-docs#wysiwid#go-lcpd#architecture#specification
source content

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
)

  1. Security & Architectural Constraints
  2. Concepts
  3. 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
    ).