| name | page-claw |
| description | Use when the user wants to turn a page-story markdown file (page-story-*.md) into a polished static HTML page. Trigger for: personal pages, academic homepages, portfolio pages, profile pages, any request to build a page from a structured markdown brief. Runs the full pipeline automatically: design context gathering, design system, implementation plan, build, and quality pass. |
| argument-hint | [page-story-file] |
| license | MIT |
| metadata | {"author":"pageclaw","version":"1.0.0","homepage":"https://github.com/XY-Showing/pageclaw"} |
Page Claw
Convert a page-story-*.md file into a polished, single-file static HTML page.
<name> in filenames below is derived from the page-story filename (e.g., page-story-ying-xiao.md → ying-xiao). If the filename has no slug, use the subject's name from the content in kebab-case.
Pipeline
page-story.md
│
▼
[1. teach-impeccable] → <name>-design.md
│
▼
[2. ui-ux-pro-max] → (appended to design.md)
│
▼
[3. writing-plans] → <name>-impl.md
│
▼
[4. Build] → index.html (project root)
│
▼
[5. Quality pass] → polish → audit → (quieter / critique if needed)
Skill Invocation
Each numbered step in this pipeline invokes a sub-skill. How to invoke it depends on your platform:
| Platform | How to invoke a sub-skill |
|---|
| Claude Code | Use the Skill tool with the skill name |
| Codex / OpenCode / Cursor / other | Read the sub-skill's SKILL.md file in full, then execute it as a complete mandatory step — produce all required outputs on disk before proceeding. Do NOT summarize, abbreviate, or simulate the output. |
Critical: Reading a skill's instructions and approximating the output is not equivalent to executing it. Each step must produce its defined artifact on disk before the next step begins. If a step's artifact is missing, re-execute that step — do not skip ahead.
Pre-flight — Page-Story Check
Before asking any questions, verify that a page-story-*.md file has been provided (as an argument, in the current directory, or referenced in the user's message).
If a page-story is found: proceed directly to Step 1.
If no page-story is found:
- Copy the full contents of
page-story-starter.md (at ~/.claude/skills/page-claw/page-story-starter.md) into a new file called page-story.md in the user's current working directory.
- Pause and respond with:
"No page-story found — I've created page-story.md in your current directory with sample content.
You can:
- Run
/page-claw page-story.md now to preview the output with the sample data
- Or edit
page-story.md first with your own information, then run /page-claw page-story.md"
Do not proceed further until the user explicitly continues.
Step 1 — Design Context
Before invoking any skill, ask the user two or three questions — no more. The number depends on whether they have a reference design (see below).
-
Reference design — Ask this first, before generating any style options:
"Do you have a website or design you'd like to reference? (URL or screenshot — skip if not. Feel free to add a directional note, e.g. 'like this but darker' or 'same vibe, more minimal'.)"
If the user provides a reference URL: fetch and analyze it immediately (before asking anything else):
-
Fetch (max 2 pages) — Use WebFetch on the provided URL. Then inspect <nav> links to identify site type: if it's a personal/academic page, the home page is sufficient; if it's a portfolio or company site, also fetch the single most relevant subpage (/work, /about, /research). Never fetch more than 2 pages.
-
Extract design signals from HTML/CSS — read the full visual language of the reference:
- Color temperature (warm/neutral/cool) — from CSS color values
- Typography character (serif/sans/mono, weight contrast) — from
font-family, font-weight
- Spatial density (compact/airy) — from
padding, line-height
- Animation presence — from
transition, @keyframes (signals static/minimal vs. motion-enhanced)
- Hover character — from
:hover styles
- Surface treatment (shadow depth, border-radius, border presence) — from
box-shadow, border-radius, border
- Layout character (sidebar tendency / single-column / grid) — from
display: grid/flex, sidebar patterns, max-width constraints
-
Document — write extracted signals in the design doc under a ### Reference sub-section (e.g., "From reference: sans-serif, extreme whitespace, no shadows, flat surfaces, static, single-column reading layout").
After analysis, skip Q2 and go directly to Q3. All extracted signals serve as soft inputs that tilt the Q3 option generation space — they shape which aesthetics and layouts feel resonant, but do not mandate outcomes. Page-story governs content. The Q3 aesthetic selection governs the final layout. The reference tilts, not dictates.
If the user skips: proceed to Q2.
-
Visual direction — Ask only if Q1 was skipped. Present 3–4 named style options labeled A/B/C/D, each with a one-line description. Include at least one distinctive or bold direction alongside safer choices. Tell the user: "If none feel right, just say so and I'll generate another set."
Example:
A. Warm & editorial — ...
B. Cool & minimal — ...
C. High-contrast & typographic — ...
D. Bold & expressive — ...
-
Aesthetic style — Generate 4 aesthetic style options dynamically based on the page-story content, Q2 direction (if asked), and reference signals + directional note (if provided). Each option must be a genuinely different CSS world — not a variation of the same mood. Present options labeled A/B/C/D. Format:
A. Style Name — one-sentence description
Layout: [layout pattern]
The CSS signature (3 key decorative properties) is your internal knowledge for this option — do not show it to the user. After the user selects an option, record the full CSS signature in the design doc under Aesthetic Implementation.
Rules:
- Options must be radically distinct from each other (e.g., Brutalism vs. Glassmorphism — not "cool minimal" vs. "refined minimal")
- Include at least one unexpected direction for this subject matter
- Each option's layout pattern must differ from at least one other option — variety in layout is part of variety in aesthetic
- If Q2 direction was given, options should respect its temperature bias — don't offer dark-mode choices when user said "warm." "Unexpected direction" still applies within the chosen temperature space.
- If user says "none feel right," generate a new set
Example format (content must vary per page-story + direction inputs — these are illustrative, not a fixed menu):
A. Brutalist Academic — Raw grid, stark contrast, no decoration; reading-machine feel
Layout: asymmetric two-column grid, content bleeds full width
B. Glassmorphism Light — Frosted glass panels, layered translucency, modern tech feel
Layout: stacked frosted cards, single centered column
C. Museum Whitespace — Extreme negative space, caption-driven, artifact-display feel
Layout: narrow single column, wide margins, content as artifact
D. Terminal Scholar — Monospace throughout, dark mode, command-line aesthetic
Layout: sticky sidebar left, scrollable main right
Infer everything else (audience, tone, content hierarchy) directly from the page-story. Do not ask additional questions beyond these.
Once you have the user's answers (and have analyzed any reference URL), write a brief summary in your response — the user's aesthetic choice, reference signals extracted (or that they skipped), and the target save path. This appears in the conversation history so teach-impeccable can read it without re-asking. Then invoke the teach-impeccable skill (Claude Code: use the Skill tool; other platforms: read teach-impeccable/SKILL.md in full and execute it completely), passing the target file path (docs/plans/<name>-design.md) as the config_file argument. teach-impeccable scans the page-story and produces a ## Design Context block (users, brand personality, aesthetic direction, design principles).
Save output to: docs/plans/<name>-design.md
Verify before proceeding to Step 2: docs/plans/<name>-design.md must exist and contain a ## Design Context section. If missing, re-execute this step.
Constraints
The page-story is the authoritative source. Render it faithfully — do not add, remove, reorder, or reinterpret its content. The design system serves the story, not the other way around. Content must remain in its original section — do not promote elements (e.g. a bold paragraph) into a hero area, header badge, or any other section.
Design decisions must derive solely from the page-story and design context gathered in Step 1. Do not reference existing project files, other HTML pages, or prior designs for inspiration unless the user explicitly requests it.
Step 2 — Design System
Invoke the ui-ux-pro-max skill with --design-system (Claude Code: use the Skill tool; other platforms: read ui-ux-pro-max/SKILL.md in full and execute it completely). This step must be performed by the skill — do not write a design system manually, even if the skill's output seems mismatched to the context. Use the page-story content and design context from Step 1 as the sole inputs.
Take the skill's output (palette, typography, style, effects, anti-patterns) as the foundation. Where specific recommendations conflict with the design context (e.g. a "motion-driven" style for an academic page), note the override and the reason in the design doc, then adapt those elements. The rest of the skill's output applies as-is. Append the result as a new ## Design System section to the design doc from Step 1.
The design system must include a ### Aesthetic Implementation section that translates the chosen aesthetic style into concrete CSS patterns. This is the bridge that makes the style choice executable — writing-plans reads it to generate specific CSS, not generic defaults.
Required fields:
- Layout structure — the page layout this aesthetic naturally produces: describe the HTML skeleton (e.g., sticky sidebar + scrollable main, single centered column, asymmetric grid). This comes directly from the layout descriptor in the aesthetic CSS signature and drives the HTML structure in writing-plans.
- Surface treatment — exact CSS for cards, panels, containers (border, shadow, border-radius, background)
- Typography expression — heading vs. body distinction: weight ratio, size scale, letter-spacing
- Decorative rules — what decoration is present / explicitly forbidden in this aesthetic
- Spatial rhythm — density disposition this aesthetic produces (compact / airy / extreme whitespace / dense)
- Signature CSS — 3–5 declarations that are the unmistakable fingerprint of this aesthetic (copied from the aesthetic CSS signature, expanded). This is the CSS signature you generated internally for the chosen aesthetic option — record it here in full even though it was not shown to the user during the aesthetic question.
Verify before proceeding to Step 3: docs/plans/<name>-design.md must contain both ## Design Context and ## Design System sections, including ### Aesthetic Implementation. If either section is missing, re-execute this step.
Step 3 — Implementation Plan
Invoke the writing-plans skill (Claude Code: use the Skill tool; other platforms: read writing-plans/SKILL.md in full and execute it completely). Do not write the plan manually. Use the design doc as spec. Output: a task-by-task implementation plan saved to docs/plans/<name>-impl.md.
Verify before proceeding to Step 4: docs/plans/<name>-impl.md must exist and contain a task-by-task plan. If missing, re-execute this step.
Rendering Conventions
These conventions control how certain page-story sections are visually rendered during Build (Step 4). Content (what links exist, what text says) is never changed — only the presentation.
Prose is the absence of a design decision. Every content element has a semantic type — a record, a sequence, a label, a relationship. Plain text collapses all types into the same form. Before building, ask of each element: what is this, structurally? Then surface that structure visually. A sequence in time is a timeline. A categorical attribute is a badge. A name among others marks a relationship. These details are what separate a polished page from a generic one — default to prose only for genuinely unstructured narrative.
Links section — A ## Links section containing profile/social URLs must be rendered as icon-based links using inline SVG, not bare text. Each icon links to its URL with an accessible aria-label.
Use Simple Icons as the icon source via CDN:
https://cdn.jsdelivr.net/npm/simple-icons@latest/icons/<slug>.svg
Common platform slugs:
| Platform | Slug |
|---|
| GitHub | github |
| LinkedIn | linkedin |
| Google Scholar | googlescholar |
| rednote (小红书) | xiaohongshu |
| Twitter / X | x |
| ORCID | orcid |
| ResearchGate | researchgate |
For email (mailto: links), use a generic envelope SVG (not from Simple Icons). For any unrecognized platform, use a generic chain-link SVG — do not guess with semantically unrelated icons (location pin, bookmark, globe, etc.).
Step 4 — Build
Execute the implementation plan. The plan drives all structural and visual decisions — do not deviate from it without updating the plan doc first.
Before marking the build complete, verify:
Step 5 — Quality Pass
After index.html is functionally complete, invoke these skills in order (Claude Code: use the Skill tool; other platforms: read each skill's SKILL.md in full and execute it completely):
polish — always run. Final pass for alignment, states, edge cases.audit — always run. Accessibility, performance, anti-pattern report.quieter — only if the design feels visually aggressive after polish.critique — only if quality concerns remain after polish and audit.
Intermediate Artifacts
| Artifact | Created by | Purpose |
|---|
docs/plans/*-design.md | teach-impeccable + ui-ux-pro-max | Design context + system, source of truth for all decisions |
docs/plans/*-impl.md | writing-plans | Task-by-task build instructions |
index.html | Build step | Final deliverable |
