Documentation

Claude — not connected

Documentation

How the spec-driven workflow runs, how to connect providers, and a full proof-of-concept walkthrough.

Try it

New here? Jump to the "Build a login UI" proof of concept below to see a task go from spec to working code.

Spec Forge — User Guide

Spec Forge is a spec-driven, agentic frontend orchestrator. You write a short specification of the UI you want; the system plans it, builds the React code, generates tests, and runs quality checks — all in one screen.

How it works

The orchestrator runs a small pipeline of agent roles on every build:

  1. Planner — reads your spec and breaks it into concrete frontend tasks.
  2. Builder — generates composable React components, following the enabled Skills as hard rules.
  3. Tester — writes a React Testing Library test for each component.
  4. Reviewer — runs lint, accessibility, and basic performance heuristics and reports a quality score.

The enabled Skills (see the Skills & Commands page) are injected into the prompt, so output stays consistent across runs — that is the difference between this tool and a plain chat wrapper.

Getting started

  1. Open Settings and paste an API key for at least one provider (Claude, OpenAI, Gemini, or HuggingFace).
  2. Choose a default model and, optionally, set the auto-fallback order. If your active provider's key is invalid, expired, or rate-limited, the next configured provider is tried automatically.
  3. Go to the Workspace, write a spec (or pick an example), and press Generate UI.

Choosing and switching providers

Each provider has its own API key, stored only in your browser's localStorage and proxied through this app's server route (so there are no CORS issues and keys are never written to a database).

If one provider's key expires mid-project, you don't lose momentum — set another provider active in Settings, or rely on the auto-fallback chain.

Proof of concept — "Build a login UI"

This is the canonical demo that takes a frontend task from requirement to implementation with minimal manual effort.

1. The spec

Build a clean, accessible login form with email and password fields,
a 'remember me' checkbox, inline validation, a submit button with a
loading state, and a 'forgot password' link.

2. What the orchestrator produces

  • A task breakdown (form scaffold → fields → validation → submit state → tests).
  • An /App.js entry plus a LoginForm component, styled and accessible.
  • A colocated test file using React Testing Library.
  • A quality report covering lint, accessibility, and performance hints.

3. The result

The live preview renders the working form immediately. The Code tab holds the runnable source, the Tests tab holds the generated tests, and the Quality tab shows the score and any findings. You can copy any file, or reopen the run later from History.

Tips for good specs

  • Be specific about fields, states, and interactions ("loading state", "inline validation", "empty state").
  • Mention accessibility needs explicitly if they matter for the task.
  • Keep one spec focused on one screen or component group for the cleanest output.

Quality checks explained

The Reviewer runs static, lint-style heuristics — not a full Lighthouse audit:

  • Lint — var usage, loose equality, leftover console statements.
  • Accessibility — missing alt, click handlers on non-interactive elements, unlabelled inputs.
  • Performance hints — array-index keys, missing list keys, excessive inline functions.

These map directly to the framework's Accessibility and Performance skills, and give you a fast, transparent signal on the generated code's health.