design-it
Skill283 starsChanged 4 months agoMITView on GitHub
Use when turning a requirement, spec, or feature brief into a single self-contained HTML design document in a fixed house style — one styled HTML page with a table-of-contents, architecture/sequence SVG diagrams, code/SQL/YAML blocks, callout boxes, an aligned-decisions (已对齐结论) panel, test cases, and a code index. Reuse for any new 需求/设计文档 that should look identical every time.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Marvellbrazil/my-agentic-skillstheir own version, first seen Oct 17, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Marvellbrazil/my-agentic-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository19 other files it gives its agents.
- article-iconsSkill
- code-to-specSkill
- graphSkill
- humanize-itSkill
- insight-diagramSkill
- listenhub-ttsSkill
- loop-itSkill
- modern-goSkill
- note-itSkill
- prdSkill
- prd-to-specSkill
- refactorSkill
- review-itSkill
- ship-itSkill
- smellSkill
- to-designSkill
- to-issuesSkill
- understandSkill
- walkthroughSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 24
Copy the template: Start from template.html in this skill's directory.
- Very specific: line 27
Keep TOC and sections in sync: Every <a href="#x"> needs a matching <section id="x">, and vice versa.
- Distinctive: line 49
Making it a proposal: Keep it a *design doc* (what/how, locked decisions), not a persuasive pitch.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
design-it
Overview
Generate a technical design document as one self-contained HTML file in a fixed house style, so every new 需求 produces a visually identical page. The look is not improvised each time — it comes from a fixed <style> block and a fixed section skeleton. Your job is to fill content into that skeleton, never to redesign it.
Core principle: Copy template.html verbatim, then replace only the content. Keep the <style> block byte-for-byte. Consistency comes from not touching the design system.
When to Use
- The user gives a new requirement / spec / feature and wants a design doc.
- Converting a
.mdtechnical spec into the shareable HTML form. - Any request like "生成同样的 html / 用这套模板 / 出一份设计文档".
When NOT to use: quick throwaway notes, a real Markdown deliverable the user wants to stay Markdown, or slide decks.
Workflow
- Copy the template. Start from
template.htmlin this skill's directory. Do not hand-roll the<head>/<style>— copy it whole. - Gather real content first. Section titles, field names, SQL,
file:linecode positions, protoIds — all must come from the actual requirement doc and codebase. Read the code; do not invent identifiers. If a fact is unknown, mark it<span class="pill todo">待确认</span>, never guess. - Fill the skeleton. Rename/reorder
<section>s to fit the feature. Keep the section kinds: 已对齐结论 → 业务规则 → 架构图 → 时序 → 数据模型 → 契约 → 清单 → 幂等降级 → 测试用例 → 代码索引 → 变更记录. Drop what doesn't apply; add feature-specific ones in the same style. - Keep TOC and sections in sync. Every
<a href="#x">needs a matching<section id="x">, and vice versa. This is the #1 breakage — verify at the end (see Quick Reference). - Save as
docs/<需求名>.html. Don't commit unless asked.
House-Style Rules (non-negotiable)
| Element | Rule |
<style> block | Copy verbatim. Never restyle. Colors come from :root CSS variables only. |
| Code / SQL / YAML | Always the template's <pre style="background:#f8fafc;...">. Inside <pre>, escape <→<, >→>, &→&. Unescaped < silently eats content. |
| Callout boxes | .note (橙, 提醒/易错), .tip (蓝, 正向补充), .warn (红, 风险). Use the right color for the meaning. |
| Diagrams | Hand-authored inline <svg> inside <figure>; text uses .svg-t/.svg-s/.svg-title; node fills use :root vars (var(--new-bg) etc.), matching the .legend. |
| Intro | Each section opens with one <p class="lead"> stating what it answers. |
| Pills | .pill.new/.old/.infra/.mq/.prod/.tech/.done/.todo for status tags — reuse, don't invent classes. |
| Tables | Plain <table> — the CSS handles zebra striping and header shading. |
| Lang | <html lang="zh">; body copy in the doc's language (usually 中文). |
Common Mistakes
- Redesigning the CSS. The whole point is identical output — don't "improve" colors, spacing, or fonts. Copy
<style>untouched. - Unescaped angle brackets in
<pre>.List<String>renders as a broken tag. Escape toList<String>. - Dead TOC links. Adding a section without its TOC entry (or renaming an
idand forgetting thehref). Always cross-check. - Inventing code positions.
file:line, table names, protoIds must be read from the repo. Unknown →待确认pill, not a plausible-looking guess. - Making it a proposal. Keep it a design doc (what/how, locked decisions), not a persuasive pitch.
Quick Reference — final self-check
f="docs/<需求名>.html"
# TOC hrefs vs section ids must match exactly (no output = perfect):
diff <(grep -oE 'href="#[a-z0-9-]+"' "$f" | sed 's/.*#//;s/"//' | sort -u) \
<(grep -oE '<section id="[a-z0-9-]+"' "$f" | sed 's/.*"//' | sort -u)
# open in browser to eyeball diagrams + code blocks render cleanlyDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

