Frontend Project Bootstrap
Bootstrap a team-standard frontend project from a UI/UX prototype, complete with filled-in documentation and ready-to-assign task tickets, ensuring that code written by different people or different coding agents feels like it was written by the same person.
Version: See the latest entry in CHANGELOG.md.
Core Principles
- The prototype is a requirements asset, not code to be copied into the project. Extract screens, data, color swatches, and interactions from it; do not copy its implementation. Store the original file and screenshots in the repo as acceptance criteria.
- Team conventions are copied as-is; project content is filled in based on the prototype. These two file types are handled differently (see the "File Index" below).
- When uncertain, ask; do not guess. Ask questions in rounds at pause points, attaching suggested answers to each; "yes" means accept the suggestion.
- Do not implement business logic. This skill only creates the skeleton, blank pages, and documentation; business features are developed later by
/implementbased on the task tickets. - Verification means completion. Lint, typecheck, test, and build must all pass green; no leftover placeholders; every screen must have a screenshot.
Required Input
- Prototype (single HTML, multi-page HTML, design file link, or screenshots) with its version / delivery date
- Project name and one-line description
- Folder location for the new project (must be empty or a fresh repo; stop and confirm if it already has content)
Other information (deployment environment, backend status, language, dark mode) is gathered in Step 1; details are in references/workflow-detail.md.
Prerequisites (one-time per machine)
cd <skill> && npm ci && npx playwright install chromium # Playwright and Prettier for scripts/; not added to project skeleton
# If Chromium is already on the machine, skip the download and use CHROMIUM_EXECUTABLE=<path> in the screenshot script
Workflow
Create a task list to track the following five steps; check off each step as completed.
Step 1: Intake
First, confirm the project folder does not exist or is empty (if it has content, stop and ask). Then, confirm the prototype file, version, and team-shared storage location. Ask about any items from the table in references/workflow-detail.md Step 1 that are not yet provided in the message.
Step 2: Analyze Prototype and Take Screenshots
Read references/prototype-analysis.md, analyze the prototype according to its method, and produce docs/_bootstrap/prototype-analysis.md (format: templates/prototype-analysis.md). If the prototype is HTML, also place the original file in docs/prototype/, fill in docs/prototype/screens.json (format: templates/prototype-screens.json), and run the screenshot script to produce a PNG for each screen.
⏸ Pause Point: Following the "Pause Point" section of references/prototype-analysis.md, ask questions in rounds: pending concerns, default behavior for missing states, routing mode (history / hash), and backend status. Record the answers in sections 11 and 12 of the analysis file before continuing.
Step 3: Create Skeleton
Copy assets/skeleton/ (excluding node_modules), run npm ci, then modify the name, color swatches, routing mode, routes and menu, blank pages, and permission codes according to references/workflow-detail.md Step 3. Keep the Item example feature until the first real feature is completed.
Step 4: Generate Documentation
Copy and fill in documents according to the mapping table in references/workflow-detail.md Step 4. Fill all <!-- FILL: --> placeholders as instructed and remove the comments; replace all {{PLACEHOLDER}} tokens. Write "TBD" for anything unknown; do not fabricate information.
Step 5: Verification, Commit, and Report
npm run lint && npm run typecheck && npm test && npm run build
node <skill>/scripts/check-placeholders.mjs <project>
The step is only complete when all four checks pass green (lint with no warnings) and the check script reports 0 ERRORs; then make the first commit.
See references/workflow-detail.md Step 5 for the report format.
When the user is not available: If a question has a suggested answer, adopt it and mark it "Adopted suggestion (tentative)"; if there is no suggested answer, write "TBD". Continue normally and list both types in the final report. The only situation that requires stopping is when the project folder already has content.
File Index
Copied As-Is (only name replacement allowed; content must not be rewritten)
| Path | Copied To | Content |
|---|---|---|
assets/skeleton/ | Project root | Runnable skeleton: config files, API layer, data hooks, DataBoundary, permissions, i18n, theme, MSW, tests, CI (Azure DevOps), PR template, Item example feature |
references/standards/ | docs/conventions/ | 18 team development standards + index |
references/adr-baseline/ | docs/adr/ | ADR 0001–0016 + index |
templates/agents/ | docs/agents/ | mattpocock skills tracker and domain docs settings (local markdown, single-context) |
Filled In Based on Prototype
| Template | Output |
|---|---|
templates/prototype-analysis.md | docs/_bootstrap/prototype-analysis.md |
templates/prototype-screens.json | docs/prototype/screens.json (input for screenshot script) |
templates/README.md, AGENTS.md, ARCHITECTURE.md, GLOSSARY.md | Project root |
templates/CLAUDE.md | Project root (adapter for Claude Code: one-line comment plus @AGENTS.md, copied as-is) |
templates/prototype-README.md | docs/prototype/README.md |
templates/adr-router-mode.md | docs/adr/0017-router-mode.md |
templates/api-interface-auth.md, api-interface.md, api-checklist.md | docs/api/ |
templates/feature-spec.md | docs/specs/<feature>.md |
templates/task.md, tasks-README.md, task-remove-example.md | docs/tasks/ |
templates/adr.md, bug-report.md etc. | Also save a copy to docs/templates/ for later use |
Instructions and Tools
| Path | When to Read |
|---|---|
references/workflow-detail.md | Specific actions, commands, and file mappings for each step |
references/prototype-analysis.md | Step 2 |
scripts/screenshot-prototype.mjs | Step 2 (also re-run if the prototype is updated) |
scripts/check-placeholders.mjs | Step 5 |
Integration with mattpocock skills
This skill's output is the input for mattpocock/skills; the project does not need to run /setup-matt-pocock-skills (doing so would only update the ## Agent skills section in AGENTS.md and the docs/agents/ folder; do not let it write to CLAUDE.md).
| Their skill | Corresponds to here |
|---|---|
/grill-with-docs, grilling | The pause point in Step 2 is the same kind of interview; for design changes later, use it directly; nouns go in GLOSSARY.md, decisions go in docs/adr/0018+ |
domain-modeling | Reads and writes GLOSSARY.md (same format) and docs/adr/ (team format, see docs/agents/domain.md) |
/to-spec, /to-tickets | Not needed. Specs are already docs/specs/ (Gherkin numbered), tasks are already docs/tasks/ (with layered file paths and reusable components) |
/implement | First version implementation approach: one docs/tasks/<ID>-*.md at a time, branching from main written in the task ticket; it will call tdd and code-review |
tdd | Seams are already documented in AGENTS.md "Test seams"; no further discussion needed |
/implement-spec | Usable but not tested: each worktree needs npm ci (husky prepare); Azure DevOps has no draft PR integration |
Agent Tool Compatibility
AGENTS.md is the single source of rules. opencode and Kimi Code CLI read AGENTS.md directly from the project root; Claude Code reads CLAUDE.md, so the skeleton includes an adapter file that contains only @AGENTS.md. Do not write additional rules in the adapter file.
Updating This Skill
To update team conventions, modify this skill (standards, adr-baseline, and skeleton together), record changes in CHANGELOG.md, and bump the version; do not make changes only in individual projects. Individual project deviations should be documented in that project's ADR (starting from 0017). After modifying the skeleton, always run lint, typecheck, test, and build in assets/skeleton/; after modifying Markdown, run npm run format.