--- name: wireframe-sketch description: Hand-drawn paper-wireframe template — white paper background, monochromatic ink palette, SVG turbulence "wobble" filters for pen-quiver authenticity, handwritten fonts (Caveat / Kalam / Ma Shan Zheng / Long Cang), wavy dividers, sketch-rect overlays, marginalia annotations. For PRD illustrations, IA flow docs, low-fidelity layout exploration, "draft / not final" stakeholder communication. Three skeletons (single-page editorial / app multi-screen flow / IA sitemap) — pick one up front based on the artifact, do NOT inherit only the brush strokes. visibility: public mode: template carrier: web-page scenario: lo-fi-mockup pattern_source: foolscap-wireframe.html source_priority: skill-first triggers: - "做个手绘 wireframe" - "纸感线框图" - "IA 流程图" - "低保真草图" - "PRD 配图" - "draft / not final 风格" --- # Wireframe Sketch Template Hand-drawn lo-fi wireframes that look explicitly draft — to invite layout feedback, signal "not shippable", or document IA without committing to visual design. ## ⚠️ Pick the Skeleton FIRST The biggest failure mode of this skill: model inherits the brush strokes (wobble, dashed, handwriting) but writes the **wrong document structure** — e.g. producing 3 isolated app screens when a multi-screen flow doc was needed, or stuffing a sitemap with editorial figures. **Before you write a single line, declare in your reply which skeleton you're using and why.** Match user's words to one of: | User says | Skeleton | Why | |---|---|---| | 报纸 / 杂志 / landing / 官网 / brochure / 单页 / 一篇 / 简报 / 海报式文档 / one-pager / editorial | **A. Single-Page Editorial** | One long page, sections stack, content-dense | | App / 小程序 / 移动端 / 手机 / 桌面应用 / SaaS 流程 / 用户路径 / 注册流 / 下单流 / 多屏 / 多页 / 注册 / 登录 / 引导 / 设置 / Tab / 表单流 | **B. App Multi-Screen Flow** | Multiple screens, navigation, states, triggers | | 信息架构 / IA / sitemap / 站点地图 / 流程图 / 关系图 / 节点图 / 数据流 / 状态机 / 权限矩阵 | **C. IA / Sitemap Diagram** | Nodes + edges, no actual screens | | 不明 / 用户没说 / 都行 | **ask the user** before picking — don't default | — | If the user gave a topic but no skeleton hint, **ask which one**. Picking wrong = doing the work twice. --- ## Skeleton A — Single-Page Editorial `foolscap-wireframe.html` is the reference for this skeleton. Use when the artifact is a single scrollable page (newspaper, magazine spread, landing page wireframe, brochure, single-page PRD illustration). Required sections (in order, can drop 1–2 but keep the rhythm): 1. **Masthead / banner** — title, issue/version, date 2. **Hero feature** — one big lead block with headline + intro + hand-drawn illustration placeholder 3. **3–5 content sections** — each with its own h2, mix of text figures and sketch illustrations 4. **Sidebar / brief / list block** — short items, dense type, breaks the rhythm 5. **CTA / signup / footer** Density: aim for the foolscap reference's content-per-square-inch — sparse single-page wireframes feel like a stub, not a draft. --- ## Skeleton B — App Multi-Screen Flow ⛔ HARD MINIMUMS `foolscap-wireframe.html` is **not the reference for this skeleton** — only borrow its SVG filters, font stack, and dashed-cell aesthetic. The document **structure** must be assembled from the checklist below. ### Required sections (MUST all be present — page is incomplete otherwise) 1. **Cover** — app name + version + role/persona + 1-line scope ("MVP / 内测 / v0.3 / 仅记账,不含理财") 2. **Sitemap / nav diagram** — visual tree or grid showing all screens and their relationship. Not a list — an actual diagram with boxes + lines. 3. **6–8+ core screens** as `figure` blocks. For a 记账 app that's at minimum: 启动/欢迎 → 首页(概览) → 记一笔(金额→分类→备注→保存) → 账单详情 → 月度统计 → 分类管理 → 预算设置 → 我的/设置. **3 screens is not a wireframe doc, it's a sketch sample.** 4. **At least 1 flow arrow diagram** showing user path across screens (e.g. "首页 → 点'+' → 记一笔 → 保存 → toast → 回首页"). Don't just put a single `↓` between screens — write the trigger on the arrow. 5. **At least 1 state variant** for each screen that has state: empty / loading / error / success. Pick the screens where it matters (list page → empty state; form → error state). 6. **End matter** — open questions / TBD list / version log / next-step decisions to make ### Per-screen requirements Every screen block must have: - **Figure number** — `图 02` / `Fig. 03`, sequential, referenced from flow diagrams - **One-line responsibility** — "记一笔 · 从主页点'+'进入,保存后弹 toast 并返回主页" - **Trigger annotations** — what entry points lead here, what exits go where - **Marginalia** — at least 1 hand-written side note per non-trivial screen (constraint, edge case, "TBD",未决问题) ### Layout - **Vertical stack** of screens with explicit arrow + trigger label between each (not a passive `↓`) - Or **horizontal flow strip** with screens in left-to-right order — works well for linear flows like onboarding/checkout - **Don't** put screens in a grid with no flow indication — that's a screen gallery, not a flow doc ### Content density red lines - < 5 screens → reject yourself, ask user for more flows or downgrade scope honestly - No sitemap → reject yourself, the doc is unreadable without it - No state variants → at least mark the empty/error spots even if you don't draw them ("空状态:见图 04a / TBD") - No marginalia anywhere → you copied the brush but not the language; go back and annotate --- ## Skeleton C — IA / Sitemap Diagram Pure structural document — no real screens, just node-edge diagrams of information architecture, navigation, data flow, or state machines. Required sections: 1. **Title + legend** — what the boxes mean, what the line types mean (solid = direct nav, dashed = conditional, double = data binding) 2. **Main diagram** — the tree/graph itself, central, large 3. **Per-node mini-spec** — for non-obvious nodes, 1–3 lines of what lives there 4. **Permission / role matrix** if applicable 5. **Open questions** at the bottom Wobble + handwriting still apply. Box-and-line layout, lots of whitespace, single accent color for the "current path" / "default" highlight. --- ## Marginalia Language (skeletons B & C must use; A optional) Marginalia is what separates a real lo-fi wireframe from a "high-fi draft pretending to be lo-fi". Use these moves: | Mark | When | How | |---|---|---| | Side note | Constraint or rationale | `