eliteforge-google-stitch-onboarding

What this skill does

# EliteForge Google Stitch Onboarding

This skill expects the companion `$eliteforge-task-progress-tracker` skill to be available.

This skill drives the first frontend implementation pass from a Google Stitch export. Keep it incremental, auditable, and confirmation-gated.

## Mandatory orchestration rule

Before reading or modifying project files, activate `$eliteforge-task-progress-tracker`.

Use `docs/tasks/google-stitch-onboarding/` as the task-root override. Do not write google-stitch-onboarding bookkeeping under `.eliteforge/google-stitch-onboarding/` or repository-root `tasks/google-stitch-onboarding/`.

- Top-level tracker task file: `docs/tasks/google-stitch-onboarding/google-stitch-onboarding.md`.
- Child tracker task files, if the tracker stores child tasks as separate files: `docs/tasks/google-stitch-onboarding/google-stitch-onboarding-N.md`.
- State file: `docs/tasks/google-stitch-onboarding/state.md`.
- Implementation ledger: `docs/tasks/google-stitch-onboarding/implemented-pages.txt`.
- Acceptance manifest: `docs/tasks/google-stitch-onboarding/acceptance-manifest.md`.
- Integration test plan: `docs/tasks/google-stitch-onboarding/integration-test-plan.md`.

During tracker setup, check whether the current directory is already inside a Git repository. If not, run `git init` in the current directory before recording tracker files, then record the command/result in the tracker and `docs/tasks/google-stitch-onboarding/state.md`.

Create top-level task `google-stitch-onboarding` and child tasks `google-stitch-onboarding-1` through `google-stitch-onboarding-4`.

Every top-level step row under `## Steps` must start with the exact relative Markdown link to its child task:

- Step 1: `[google-stitch-onboarding-1](google-stitch-onboarding-1.md) - ...`
- Step 2: `[google-stitch-onboarding-2](google-stitch-onboarding-2.md) - ...`
- Step 3: `[google-stitch-onboarding-3](google-stitch-onboarding-3.md) - ...`
- Step 4: `[google-stitch-onboarding-4](google-stitch-onboarding-4.md) - ...`

Step scope:

- Step 1: initialize from tech stack plus design docs and create `/design-standard`.
- Step 2: read product/design docs, scan every prototype page, and establish shared layout plus common components.
- Step 3: traverse all Stitch pages, implement them with mock data plus API boundaries, and record page acceptance evidence.
- Step 4: perform final quality acceptance across coverage, visual structure, interactions, and deviations.

Gate every step through `waiting_human_decision`. If a required decision is unclear, stop before guessing and record the exact question in both the top-level step and active child task. After a step's work and validation finish, set both rows to `waiting_human_decision`, ask for acceptance, and do not continue until the user confirms.

## 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, Google Stitch onboarding, frontend project initialization, UI landing from prototype.
- Requirements to read `tech-stack.md`, `design.md`, `prd.md`, 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 inputs: tech stack doc, design doc, PRD, and a Google Stitch export or ZIP whose page directories contain `code.html` and usually `screen.png`. Accept canonical names such as `tech-stack.md`, `docs/tech-stack.md`, `design.md`, `DESIGN.md`, `prd.md`, and `*_prd.md`, plus clearly named nested equivalents. Record any non-canonical mapping in the tracker and state file. Missing tech stack or design input is a Step 1 blocker unless the user explicitly approves a fallback.

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.
- `scripts/acceptance_check.sh` verifies source coverage, the page implementation contract, ledger entries, acceptance-manifest page entries, the integration test plan, runtime naming boundaries, and required route/critical-journey acceptance sections.
- `assets/acceptance-manifest-template.md` provides the required acceptance manifest structure.
- `assets/integration-test-plan-template.md` provides the required integration test plan structure.

Read [references/google-stitch-onboarding-workflow.md](references/google-stitch-onboarding-workflow.md) for detailed step instructions. Read [references/google-stitch-implementation-guide.md](references/google-stitch-implementation-guide.md) before translating Stitch HTML/images into frontend components.

## Operating principles

- Respect the selected tech stack document over all generic assumptions. Do not impose React/Vue/Next/Tailwind unless the stack document requires or permits it.
- Read the design document early enough to seed baseline color, typography, spacing, and tokens before creating styles or theme configuration.
- Stage 1 must create a runnable `/design-standard` preview using normal routing. Do not use `/` for this page unless explicitly requested; preserve it throughout later steps and never count it as a Stitch page.
- 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.
- Keep source identity separate from product identity. Source identity is the Stitch page directory, `code.html`, rendered image, and inventory number; use it only for traceability, coverage, and evidence. Product identity is the real product page name, route, component/page module, service/API boundary, and navigation label; use it for implementation.
- Step 2 must create a page implementation contract before product page implementation begins. Derive product identity in this order: PRD information architecture or feature modules, design document page titles or navigation, visible prototype title/menu text, semantic text from `code.html`, then source directory name only as a derivation clue. If product identity remains unclear, stop at `waiting_human_decision`; do not generate source-shaped implementation names.
- Runtime code must be named from product identity. Source identity terms such as prototype/stitch page names may remain in onboarding docs, ledgers, source inventories, and explicit prototype viewer or evidence tooling, but they must not become the default names for product pages, routes, components, service modules, mocks, or navigation entries.
- Step 2 must derive a project-specific shared shell contract from `design.md` plus the actual Stitch pages before building shared layout primitives. The contract must capture visible shell regions, spatial relationships, ownership of viewport space, responsive behavior when specified or visible, and required shell interactions from design docs or prototypes. Do not use a generic shell contract.
- Build shared layout primitives before duplicating page code: app shell, navigation regions, 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.
- Routing, entry state, and user journeys are part of the deliverable. Step 2 must define the route and navigation