impeccable-documenter

Writes DESIGN.md and its sidecar by deriving the design system from the shipped build artifact.

1|Updated Apr 30, 2026
One-click install
npx skills add https://github.com/hafidzlvm/opencode --skill impeccable-documenter-hafidzlvm
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: impeccable-documenter
Source: https://github.com/hafidzlvm/opencode/tree/main/skills/impeccable-documenter
Command: npx skills add https://github.com/hafidzlvm/opencode --skill impeccable-documenter-hafidzlvm

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Design documentation written before a build drifts from what actually ships, and undocumented builds leave future work guessing at tokens and rules. This Skill records the design system after the build is finished, grounding every token and rule in the shipped artifact rather than in intentions. ## Core Features & Use Cases - Evidence-Based Design Tokens: Scans stylesheets, custom properties, computed values, spacing rhythm, and the type ramp as actually used, recording only durable system rules. - DESIGN.md and Sidecar Generation: Follows the operating spec in reference/document.md for format, token schema, sidecar, and section order, and updates an existing DESIGN.md by preserving confirmed incumbent decisions. - Defect Guardrails: Refuses to canonize craft-floor violations (invented kickers, hard offset shadows, glyph icons) into system rules, recording them as defects instead. - Use Case: After shipping a new marketing site built with the Impeccable workflow, run this Skill to produce a DESIGN.md that future surfaces can inherit, with a not-canonized line naming the defects the build carries. ## Quick Start Document the design system of the finished build at the project root, writing DESIGN.md at the app boundary using the direction contract and PRODUCT.md as inputs.

Frequently Asked Questions about impeccable-documenter

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a DESIGN.md from a finished frontend build?▼

Provide the project root, artifact paths, direction contract text, and PRODUCT.md path. The Skill scans stylesheets, custom properties, and component patterns, then writes DESIGN.md and its sidecar following the format spec in reference/document.md.

What is a design system sidecar file?▼

The sidecar is a companion file to DESIGN.md whose structure is defined by the skill's reference/document.md operating spec. It is written alongside DESIGN.md and follows the same evidence-based rules derived from the shipped artifact.

Does it update an existing DESIGN.md or replace it?▼

An existing DESIGN.md path means update, not replace. The Skill preserves confirmed incumbent decisions and reconciles them with what the current build actually evidences.

Why document the design system after the build instead of before?▼

A rulebook written before the build gets defended against reality instead of describing it. Writing after the fact ensures every token and rule is evidenced by shipped code, so the build wins wherever it diverges from the plan.

What are the limitations of build-derived design documentation?▼

One-off values are skipped since a token used once is not a system, and craft-floor violations like invented kickers or glyph icons are recorded as defects, never as rules. The run also operates under a hard turn ceiling, so evidence sampling is prioritized over exhaustive scans.