EliteForge Frontend Onboarding

Activation Gate

Use this skill only when the user explicitly states that the current project follows 璀璨工坊规范 or eliteforge specification. If that project-level statement is absent, do not activate this skill; handle the request with general capabilities.

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/frontend-onboarding/ as the task-root override. Do not write frontend-onboarding bookkeeping under .eliteforge/frontend-onboarding/ or repository-root tasks/frontend-onboarding/.

• Top-level tracker task file: docs/tasks/frontend-onboarding/frontend-onboarding.md.
• Child tracker task files, if the tracker stores child tasks as separate files: docs/tasks/frontend-onboarding/frontend-onboarding-N.md.
• State file: docs/tasks/frontend-onboarding/state.md.
• Implementation ledger: docs/tasks/frontend-onboarding/implemented-pages.txt.
• Acceptance manifest: docs/tasks/frontend-onboarding/acceptance-manifest.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/frontend-onboarding/state.md.

Create top-level task frontend-onboarding and child tasks frontend-onboarding-1 through frontend-onboarding-4.

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

• Step 1: [frontend-onboarding-1](frontend-onboarding-1.md) - ...
• Step 2: [frontend-onboarding-2](frontend-onboarding-2.md) - ...
• Step 3: [frontend-onboarding-3](frontend-onboarding-3.md) - ...
• Step 4: [frontend-onboarding-4](frontend-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, frontend 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.

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 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.
• 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.
• This skill explicitly requires and authorizes multi-agent delegation for large page-batch actions. When the current action is execute_current_step and the active step contains page-batch work with more than two batches, use worker subagents for non-overlapping page batches. This applies to Step 2 full prototype scans, Step 3 page implementation, and any similar large batch of pages.
• The lead agent owns only shared contracts, integration, ledger/manifest/state updates, validation, tracker updates, and user confirmation for delegated page-batch work. It must not serially perform worker-owned page batches after the mandatory delegation condition is met.
• If worker subagents are unavailable when mandatory delegation is required, record a blocker in the tracker/state, set the active rows to waiting_human_decision, and stop instead of silently doing the batch work in the lead agent.
• Maintain a local implementation ledger at docs/tasks/frontend-onboarding/implemented-pages.txt. Append one source prototype page name per line only after its route/page/component, API-ready service boundary, visual-structure check, and interaction smoke check have passed.
• Maintain docs/tasks/frontend-onboarding/state.md with source paths, prototype inventory, page archetype scan, route mapping, validation commands, and decisions.
• Maintain docs/tasks/frontend-onboarding/acceptance-manifest.md once page implementation begins. Record each Stitch page's route, component, primary archetype, visual-structure evidence, interaction smoke evidence, accepted deviations, and blockers.

Step gate contract

At the end of every step, respond with:

• Tracker task/subtask updated.
• Top-level task step and child task step set to waiting_human_decision for acceptance.
• 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 the selected tech stack document.
• Stage 1 produced a simple /design-standard page for previewing the standards extracted from design.md, and later steps preserved that page.
• Shared layout and design tokens/components are extracted from docs plus a full scan of every Stitch page.
• Every Stitch page directory containing code.html has a corresponding route/page/component or documented equivalent, and each page passes visual-structure acceptance.
• Every Stitch page preserves the prototype's primary main-content archetype; kanban boards, split panes, data tables, forms, chats, graphs, dashboards, detail inspectors, auth flows, and similar structures must not be replaced by a generic card template.
• Every page using the shared shell conforms to the project-specific shared shell contract extracted from design docs plus the prototype. Shared shell structural or interaction mismatch is a hard failure for every affected page.
• Every interactive control category visible in the prototype has minimum observable behavior or is recorded as a blocker. Blocked control behavior cannot count as a pass.
• Each page uses mock data through an API-ready boundary.
• Coverage check shows no missing prototype pages.
• docs/tasks/frontend-onboarding/acceptance-manifest.md exists and is maintained with page-by-page visual, structural, and interaction acceptance evidence.
• /design-standard, route 200 checks, screenshot dimensions, build/typecheck success, source-structure checks, and implementation-ledger coverage are baseline gates only; they do not constitute final acceptance without visual-structure and interaction evidence in the acceptance manifest.
• The tracker contains completed child tasks frontend-onboarding-1 through frontend-onboarding-4.
• No frontend onboarding bookkeeping files are written outside docs/tasks/frontend-onboarding/.