From lite-sdd
Lite-SDD implementation planning and sync. Use when the user wants to plan the implementation of a specification, build it, or keep the technical documentation reflecting the actual code state. Drives the loop: plan (in plan mode) → user approval → build → update implementation.md so it stays the living, exhaustive image of the code — minimising the gap between spec and code in a lite-sdd project.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lite-sdd:lite-sdd-implementThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Plan the implementation of a `spec.md`, build it, and keep `implementation.md` as the
Plan the implementation of a spec.md, build it, and keep implementation.md as the
living technical image of the code. Each feature folder holds one spec.md
(functional source of truth) and one implementation.md (technical image); for where
they live see lite-sdd-overview → ## Repository layout.
The loop is always the same and runs in this order:
spec.md (ready)
└─▶ Phase 0 — plan (in plan mode, not stored)
└─▶ user approves the plan
└─▶ Phase 1 — technical implementation
└─▶ Phase 2 — update implementation.md to match the real code
spec.md is the what and stays functional. implementation.md is the how it is
actually built and stays technical. Never start Phase 1 before the plan is approved;
never finish a feature without Phase 2.
Before touching any file:
implementation.md persists. Git holds the history; the plan does not.Do not modify any file until the plan is approved. If you are in plan mode, leave it through the native approval gate; if you are not, self-enforce this gate anyway — the rule binds whether or not plan mode is on.
Build exactly the approved plan. If reality forces a departure from the plan (a lib behaves differently, a better approach surfaces), that is fine — the plan was only a means. What matters is that Phase 2 documents what you actually built, not what the plan predicted.
After the code is written, always review and update implementation.md so it
matches the code that now exists. This is not optional and not deferred to "later".
implementation.md must be able to honour every rule in
spec.md. A rule with no corresponding implementation is a gap — surface it.## implementation.md reflects the real state below.The exhaustive technical image of how the feature is really built — the technical
counterpart to the functional spec.md. Its job is to let the next person (human or
agent) implement the next feature without re-discovering how this one works, and
without repeating mistakes already made here.
It is exhaustive on what matters and silent on the trivial. Trace everything that shapes real behaviour; skip boilerplate, obvious wiring, and noise.
| Trace (exhaustive) | Skip (futile) |
|---|---|
| Every API call: trigger, endpoint/operation, params, response handling | Trivial getters, obvious imports, framework boilerplate |
| Every filter, query, sort, and pagination rule actually applied | Self-evident one-liners with no behavioural weight |
| Every behaviour change on a UI event (click a button, an event fires) | Restating the spec's functional rules verbatim |
| Non-obvious UI behaviours worth knowing for future features — patterns to reuse, pitfalls and mistakes not to reproduce | Step-by-step narration of how the code was written |
Suggested skeleton — adapt the sections to the feature, keep it token-light:
# NNN — <Feature title> · Implementation
## Overview
One paragraph: how the feature is built — the main modules/components and how they
fit together.
## API calls
| Trigger | Endpoint / operation | Params / payload | Response handling |
|---|---|---|---|
| … | … | … | … |
## Filters & queries
The filters, queries, sort and pagination rules actually applied (and where).
## Event → behaviour
| Event (click, load, change, …) | What the app does |
|---|---|
| … | … |
## Notable UI behaviour
Non-obvious behaviours worth knowing for future features: patterns to reuse,
gotchas hit here, mistakes not to reproduce.
## Key files
Where the above lives in the codebase (paths), so the next reader finds it fast.
Like spec.md, implementation.md always describes the state that exists now,
never how it got there. When a behaviour changes, rewrite the affected part: no
changelogs, no "previously…" notes, no struck-through lines, no plan leftovers. This
is exactly why the plan is never stored — a stored plan would rot into a stale,
temporal record. History lives in git; implementation.md stays a clean image of the
current code.
| Anti-pattern | Correct approach |
|---|---|
| Editing files before the plan is approved | Phase 0 gate — recommend plan mode, present the plan, wait for approval |
| Writing the plan to disk (plan.md, a stored design doc) | Keep the plan in the conversation; only implementation.md persists |
| Writing implementation.md before coding | It is a descriptive image of real code — write/update it in Phase 2, after the build |
| Skipping the implementation.md update when "the change was small" | Phase 2 is mandatory every time; an un-synced doc is a stale doc |
| Documenting what the plan predicted instead of what was built | Read the real code; where code and plan diverge, the code wins |
| Padding implementation.md with trivia (boilerplate, obvious wiring) | Trace API calls, filters, event→behaviour and notable UI behaviour; skip the futile |
| Keeping changelogs / "previously…" notes when behaviour changes | Rewrite to the current state; history lives in git |
lite-sdd-overviewlite-sdd-initlite-sdd-specifyProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub tchinnin/lite-sdd --plugin lite-sdd