layout-writing

Name: layout-writing
Author: pavel-molyanov

241stars75forks

How to install layout-writing?

pavel-molyanov/molyanov-ai-dev/layout-writing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill layout-writing

Installs into the current project.

Summary

Reproduces and adjusts web layouts from Figma, Claude Design exports, screenshots, or an existing project style with high visual fidelity and proportional verification. Use when: "сверстай по Figma", "поправь вёрстку", "подвинь блок", "перенеси из Claude Design", "сделай адаптив"

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Layout Writing
4
5	Deliver a layout that matches its exact source where one exists, fills only genuinely unspecified decisions from project evidence, works at relevant widths, and fits the existing codebase. Keep verification proportional to the requested scope.
6
7	## Ownership
8
9	- `layout-writing` owns markup structure, styles, responsive behavior, typography application, asset placement, presentation, and visual verification.
10	- `code-writing` owns data flow, state, APIs, validation, and business behavior. Use both skills for mixed work and keep their ownership separate.
11	- Reproduce or extend an existing visual language. Blank-slate visual design needs a design source or separately approved design work.
12
13	## Phase 1: Read the Project and Set the Scope
14
15	1. Read the repository instructions and the project documentation they identify as required before changing the layout. Then inspect the affected component or template, its styles, tokens, fonts, images, nearby components, and the relevant run/build command. If project documentation is absent, use the existing code and interface without inventing project-wide rules.
16	2. Classify the requested scope:
17	- `selected area` — one element, component, or section; verify it and its nearest context;
18	- `whole page` — a landing page or other long page; list its major visual blocks from top to bottom using the exact source when present or the current DOM and requested content otherwise, then verify every item. Preserve a compact inventory that proves the list is complete: parent-frame section metadata or node IDs, an ordered DOM outline with selectors, or segment ranges covering the full height of one long source image.
19	3. Choose source guidance before implementation:
20	- With an exact source such as Figma, a Claude Design export, PDF, screenshot, or existing page to reproduce, read and apply [reproduce.md](references/reproduce.md) — source acquisition, exact block evidence, and comparison.
21	- Without an exact source, read and apply [design-decisions.md](references/design-decisions.md) — project-first choices for missing visual decisions.
22	- When the source defines only part of the task, read both. Apply `reproduce.md` to everything the source defines and `design-decisions.md` only to missing states, widths, or parts and to changes the user explicitly requested to differ from the source. General design advice does not override an intentional source value.
23	4. Resolve only blockers that cannot be established from the project or source. Ask for the relevant frame or block when a Figma link identifies only a whole file, and ask before substituting a missing required font or asset or expanding beyond the requested scope.
24
25	Checkpoint: Required project guidance and source references were read; the selected area or complete page block list and its inventory, exact-source boundary, relevant files, and runnable verification path are known.
26
27	## Phase 2: Implement and Verify
28
29	1. Reuse the project's components, tokens, layout primitives, fonts, images, and asset pipeline when they produce the required result. Adapt source-generated code to the real project rather than inserting it unchanged.
30	2. Implement the smallest change that satisfies the request. Exact source measurements control defined colors, spacing, density, geometry, crop, and layering even when they look unusual. For unspecified decisions, follow project documentation and existing UI before the general rules in `design-decisions.md`.
31	3. Build a deduplicated viewport list in the `WIDTHxHEIGHT` syntax required by `capture.mjs`, and pass the full list explicitly with `--viewports`:
32	- `360px`, `430px`, `768px`, and `1440px` for ordinary responsive coverage;
33	- the owning viewport width of every exact source and the user-screenshot width when its viewport and device scale are established;
34	- widths immediately before and after each breakpoint in the affected styles that changes the requested area or any affected block in a whole-page checklist.
35	Use the owning source viewport height when it is known; keep it separate from the compared block bounds. Otherwise declare one stable representative browser height and reuse it across captures and reruns; for example, use `360x900,430x900,768x900,1440x900` when `900px` is that declared height. This is a small targeted set, not a sweep acr

People who liked this also viewed

6 picks

Type

layout-writing

241stars75forks

View on GitHub

How to install layout-writing?

pavel-molyanov/molyanov-ai-dev/layout-writing

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill layout-writing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Layout Writing
4
5	Deliver a layout that matches its exact source where one exists, fills only genuinely unspecified decisions from project evidence, works at relevant widths, and fits the existing codebase. Keep verification proportional to the requested scope.
6
7	## Ownership
8
9	- `layout-writing` owns markup structure, styles, responsive behavior, typography application, asset placement, presentation, and visual verification.
10	- `code-writing` owns data flow, state, APIs, validation, and business behavior. Use both skills for mixed work and keep their ownership separate.
11	- Reproduce or extend an existing visual language. Blank-slate visual design needs a design source or separately approved design work.
12
13	## Phase 1: Read the Project and Set the Scope
14
15	1. Read the repository instructions and the project documentation they identify as required before changing the layout. Then inspect the affected component or template, its styles, tokens, fonts, images, nearby components, and the relevant run/build command. If project documentation is absent, use the existing code and interface without inventing project-wide rules.
16	2. Classify the requested scope:
17	- `selected area` — one element, component, or section; verify it and its nearest context;
18	- `whole page` — a landing page or other long page; list its major visual blocks from top to bottom using the exact source when present or the current DOM and requested content otherwise, then verify every item. Preserve a compact inventory that proves the list is complete: parent-frame section metadata or node IDs, an ordered DOM outline with selectors, or segment ranges covering the full height of one long source image.
19	3. Choose source guidance before implementation:
20	- With an exact source such as Figma, a Claude Design export, PDF, screenshot, or existing page to reproduce, read and apply [reproduce.md](references/reproduce.md) — source acquisition, exact block evidence, and comparison.
21	- Without an exact source, read and apply [design-decisions.md](references/design-decisions.md) — project-first choices for missing visual decisions.
22	- When the source defines only part of the task, read both. Apply `reproduce.md` to everything the source defines and `design-decisions.md` only to missing states, widths, or parts and to changes the user explicitly requested to differ from the source. General design advice does not override an intentional source value.
23	4. Resolve only blockers that cannot be established from the project or source. Ask for the relevant frame or block when a Figma link identifies only a whole file, and ask before substituting a missing required font or asset or expanding beyond the requested scope.
24
25	Checkpoint: Required project guidance and source references were read; the selected area or complete page block list and its inventory, exact-source boundary, relevant files, and runnable verification path are known.
26
27	## Phase 2: Implement and Verify
28
29	1. Reuse the project's components, tokens, layout primitives, fonts, images, and asset pipeline when they produce the required result. Adapt source-generated code to the real project rather than inserting it unchanged.
30	2. Implement the smallest change that satisfies the request. Exact source measurements control defined colors, spacing, density, geometry, crop, and layering even when they look unusual. For unspecified decisions, follow project documentation and existing UI before the general rules in `design-decisions.md`.
31	3. Build a deduplicated viewport list in the `WIDTHxHEIGHT` syntax required by `capture.mjs`, and pass the full list explicitly with `--viewports`:
32	- `360px`, `430px`, `768px`, and `1440px` for ordinary responsive coverage;
33	- the owning viewport width of every exact source and the user-screenshot width when its viewport and device scale are established;
34	- widths immediately before and after each breakpoint in the affected styles that changes the requested area or any affected block in a whole-page checklist.
35	Use the owning source viewport height when it is known; keep it separate from the compared block bounds. Otherwise declare one stable representative browser height and reuse it across captures and reruns; for example, use `360x900,430x900,768x900,1440x900` when `900px` is that declared height. This is a small targeted set, not a sweep acr

People who liked this also viewed

6 picks

Type