EliteForge Frontend Onboarding
This skill drives the first frontend development pass from a Google Stitch export. It must keep implementation incremental, auditable, and gated by user confirmation.
Mandatory orchestration rule
Before reading or modifying project files, activate and use
$eliteforge-task-progress-tracker
.
Create a top-level task named exactly:
The task must contain these four steps:
- Read ; initialize/create the frontend project in the current directory according to the required stack.
- Read /; randomly select two prototype pages containing HTML and image files; implement shared layout components and enforce page consistency such as sidebar and navigation bar.
- Traverse the Google Stitch folder; implement every prototype page in sequence with mock data first while reserving backend API calls.
- Check whether all prototype pages have been implemented.
For each step
, create a child task named exactly:
Do not proceed from one step to the next until the user explicitly confirms the step result. After finishing a step, update the tracker with deliverables, touched files, validation commands, known gaps, and pending decisions, then ask for confirmation. If the tracker supports a waiting state, mark the step as waiting for user confirmation. After confirmation, mark the child task completed and start the next child task.
Trigger conditions
Use this skill when a task mentions any of these contexts:
- Google Stitch prototype, Stitch export, prototype ZIP, page HTML plus screen image.
- First frontend pass, frontend onboarding, frontend project initialization, UI landing from prototype.
- Requirements to read , , , and implement multiple pages progressively.
- Explicit use of
$eliteforge-task-progress-tracker
with confirmation-gated subtasks.
Required inputs and discovery
Work from the current directory unless the user provided a different path.
Expected project/prototype inputs:
- in the current directory.
- A Google Stitch export directory or ZIP containing page directories.
- Product document candidates: , , or similar.
- Design document candidates: , , or a nested design markdown file.
- Page prototype directories containing at least and usually an image such as .
When file names differ from the canonical names, locate reasonable equivalents and record the mapping in the tracker. Do not silently ignore missing
; treat it as a blocker for step 1.
Optional helper scripts:
scripts/stitch_manifest.sh
scans a Stitch ZIP or folder and prints docs plus page prototype inventory.
scripts/coverage_check.sh
compares discovered prototype page names with an implementation tracking file.
Read references/frontend-onboarding-workflow.md for detailed step instructions. Read references/google-stitch-implementation-guide.md before translating Stitch HTML/images into frontend components.
Operating principles
- Respect over all generic assumptions. Do not impose React/Vue/Next/Tailwind unless the stack document requires or permits it.
- Initialize in the current directory. Avoid creating an extra nested app directory unless the stack document explicitly requires it.
- Never delete existing user files to make initialization easier. If the directory is non-empty, merge carefully and record conflicts.
- Use the prototype HTML as structural evidence and the image as visual evidence. When they conflict, prefer the image for visible layout and the PRD/design docs for product intent.
- Build shared layout primitives before duplicating page code: app shell, sidebar, top navigation, page header, cards, tables, form controls, status badges, empty states, pagination, drawers/modals, and floating agent/help entry points when present.
- Mock data is acceptable only for the first pass. API boundary functions, typed DTOs, service modules, or adapter interfaces must be present so the mock can be replaced without changing page components.
- Maintain a local implementation ledger at
.eliteforge/frontend-onboarding/implemented-pages.txt
. Append one source prototype page name per line only after its route/page/component has been implemented.
- Maintain
.eliteforge/frontend-onboarding/state.md
with source paths, selected seed pages, route mapping, validation commands, and decisions.
Step gate contract
At the end of every step, respond with:
- Tracker task/subtask updated.
- Files created or modified.
- Validation run and result.
- What is ready for review.
- Explicit request for user confirmation to continue.
Do not start the next step in the same response unless the user has already confirmed it in a prior message.
Completion criteria
The first pass is complete only when:
- The frontend project exists in the current directory and follows .
- Shared layout and design tokens/components are extracted from docs plus two randomly selected seed pages.
- Every Stitch page directory containing has a corresponding route/page/component or documented equivalent.
- Each page uses mock data through an API-ready boundary.
- Coverage check shows no missing prototype pages.
- The tracker contains completed child tasks through .