Frontend Screen Video Guide — Component
What this guide is: Watch a Swifter component built from scratch — an empty work item all the way to shipped Angular code — in eighteen short narrated clips. Each clip shows one trigger: a click, a command send, a tab open. The agent runs and the Q&A happen off-camera, so every video stays under a minute and the narration tells you what is happening while it does.
Who it is for: Anyone who wants to see the full component flow before sitting down to run it, or who prefers watching over reading a step-by-step walkthrough.
What you'll build
By the end of these clips you will have watched one Component work item go from empty to shipped, reviewable Angular code — a real pull request merged into main, in eighteen short clips of roughly half a minute each.
Three agents carry the work, and the hand-offs between them are the spine of the whole flow. The swifter-default Coordinator triages the work item and brings in a specialist; the Frontend Analyst turns the brief and the Figma design into a specification; the Frontend Developer turns that specification into framework-native code. The active agent changes at step 5 (Coordinator → Analyst) and again at step 13 (Analyst → Developer) — watch for those two switches and the rest of the sequence reads as a map.
About 12–15 minutes of watching across all 18 clips. No keyboard needed — this is a watch-and-read tour. When you want to do it yourself, the Frontend Screen Happy Path is the command-by-command companion.
The eighteen clips fall into four phases, one agent driving each:
This flow assumes a project and a work item already exist. To do this yourself, set up the project first — see Setting Up the Swifter Project.
How to use it: Play each clip in order. Read the few sentences under the heading to know what to notice, then watch. The After this clip line under each video names the one thing that is now true. You do not need to follow along at the keyboard — the Frontend Screen Happy Path is the companion guide for that.
Set up the work item
You are driving here, with the swifter-default Coordinator. These four clips get a well-formed work item open and a session started — the brief you author now is what every later agent reads, so this phase decides how much rework you avoid later.
Step 1 — Open the project workspace
What happens: the project workspace opens, and the New Work Item button is the entry point for the whole flow.
The project workspace is where every component you build lives, organised as work items. Notice the New Work Item button — that is where the flow begins.
After this clip: you are in the workspace and ready to create a work item.
Step 2 — Create the component work item
What happens: a Component work item is filled in — type, Angular module, user story, IF/THEN display rules, and the Figma frame in its own field.
Watch the work item get filled in: type set to Component, the Angular module chosen, a real user story in the description, display rules written as plain IF/THEN lines, and the Figma frame pasted into its own dedicated field — not the description. This brief is what the Frontend Analyst reads later, and it is read literally: the analyst follows the IF/THEN rules as written, treats anything you scope out as off-limits, and looks for the design in the Figma field. The care you take here directly shapes what gets built.
After this clip: a complete, agent-readable Component work item exists.
Conditional behaviour belongs in IF/THEN display rules (one rule per line), anything excluded belongs in an explicit scope-out, and the Figma URL belongs in its own field. Prose buried in the description is easy for an agent to misread. See Work-Item Description Composition.
Step 3 — Note the Front-End Angular module
What happens: the work-item header shows the Angular module, so both agents already know the target framework.
The module indicator in the header tells the analyst and developer agents which framework they are in. Because the module was set at creation, neither agent has to be told which framework to target.
After this clip: the framework target (Angular) is fixed for the whole session.
Step 4 — Press Start
What happens: Start creates the session branch, opens the origin chat, and wakes the swifter-default Coordinator.
Start creates the session branch, opens the origin chat, and wakes the swifter-default Coordinator — Swifter's triage agent. Notice the App, Dev, and Test tabs go live. The Coordinator immediately asks setup questions in the chat; those are answered off-camera before the next step.
After this clip: a live session exists and the Coordinator is awaiting your answers.
The Coordinator is the triage agent that picks up a fresh work item and routes it to a specialist. See Agents Inventory → Invoking an agent.
Specify with the Frontend Analyst
The Frontend Analyst now drives, from step 5 through step 12. This phase produces a specification — acceptance criteria, a component spec, a data model, and logic rules — and deliberately no production code yet. It comes first because the developer agent in the next phase builds straight from these artefacts; a spec reviewed and corrected here is far cheaper than code corrected later.
Swifter splits the work on purpose: the Frontend Analyst decides what to build (the spec), and the Frontend Developer decides how (the code). Everything in this phase is specification — design tokens, stories, a data model, logic rules — and there is no production component code yet. That arrives in the Build phase. See Agentic SDLC → Proficiencies and agents.
Several steps pause at an Approve gate — steps 10 and 11 in this phase, and again at steps 14 and 15 in the Build phase: the agent shows you a proposal and writes nothing to disk until you approve it. Read the proposal, then approve. The gate is your chance to catch drift before it becomes a file. See Work-Item Lifecycle → Why every gate matters.
Step 5 — Bring in the Frontend Analyst
What happens: the Coordinator surfaces a team-member picker, and the Frontend Analyst is selected.
Once the Coordinator's setup questions are answered, it surfaces a team-member picker. Watch the Frontend Analyst option selected and the answer submitted. This is the first agent hand-off: from here the Analyst drives, turning the work item and Figma design into a specification — no production code yet.
After this clip: the Frontend Analyst is the active agent on this work item.
The Frontend Analyst is the spec proficiency — it produces the contract the developer agent builds from. See Agentic SDLC → Proficiencies and agents.
Step 6 — Generate the acceptance criteria
What happens: /swifter-frontend-analyst:generate-acceptance-criteria reads the work item and derives a numbered list of user-observable criteria.
The command /swifter-frontend-analyst:generate-acceptance-criteria takes no arguments — it reads the work item directly. Notice the slash-command autocomplete accepted with Enter, then the Send click. From the user story, display rules, and scope, the agent derives a numbered list of testable, user-observable criteria. The recording stops at the trigger; the run finishes off-camera. This is the first artefact in the chain, and every later step is checked against it.
After this clip: the work item has machine-readable acceptance criteria.
This kicks off the Component (UI) sequence — acceptance criteria first, then the spec. See Technical Execution → Component (UI).
Step 7 — Review the generated acceptance criteria
What happens: the Acceptance criteria section, empty before, now holds the numbered list the agent derived.
The Acceptance criteria section was empty before; now it holds a numbered list derived from the brief. Each entry is a plain, testable statement with no framework or code terms. This list is the contract the specification, the code, and the tests are all checked against.
After this clip: you have confirmed the criteria match the intent of the brief.
The acceptance criteria are the contract every downstream gate measures against. See Work-Item Lifecycle → Why every gate matters.
Step 8 — Define the component specification
What happens: /swifter-frontend-analyst:define-component-spec runs a ten-step orchestration — Figma to tokens to HTML/CSS to a placeholder component in Storybook.
/swifter-frontend-analyst:define-component-spec is the Analyst's main orchestrator. It runs ten internal steps: fetching Figma, matching design tokens, generating HTML and CSS, building a placeholder component, onboarding it into Storybook, and verifying the build. It may pause to confirm low-confidence style matches; those prompts are answered in chat off-camera. Watch the trigger send and the agent start; the full run resumes off-camera. Remember this is still specification — the placeholder is a visual stand-in, not production code.
After this clip: a full component spec and a Storybook placeholder exist.
The ten sub-steps, and resuming a failed one
define-component-spec chains: fetch Figma → match style tokens → generate HTML/CSS → refresh framework knowledge → build the placeholder component → refresh Storybook knowledge → onboard the component → verify the Storybook build. If a sub-step fails, the agent surfaces a narrower resume command (for example to re-cache Figma or re-walk the style mapping) rather than re-running the whole thing. The full sequence is documented in Technical Execution → Component (UI).
Step 9 — Review the generated specification in the App tab
What happens: the App tab now shows the component under Components → workitem-content-tabs with a named Storybook story per state.
After the spec run finishes, open the App tab. Notice the component under Components → workitem-content-tabs with named Storybook stories for each state. This is the highest-leverage checkpoint in the flow: drift caught here costs minutes, while the same drift caught after code generation costs a full session. Walk each story and compare it against the Figma frame before you move on.
After this clip: the spec is verified to match the design, or you have noted what to refine.
This is the cheapest place to catch design drift. The companion happy-path step lists exactly what to check in each App-tab view — see Frontend Screen Happy Path → Step 7.
Step 10 — Specify the data model
What happens: /swifter-frontend-analyst:work-on-component-data-model proposes the typed entities and fields, then waits at an Approve gate before writing.
/swifter-frontend-analyst:work-on-component-data-model proposes the typed entities, fields, and enumerations the component renders, then waits at an Approve gate before writing anything. Notice the command trigger; the proposal review and Approve are handled in chat off-camera. The developer agent will later import these types, so getting them right here keeps types from being re-invented inline.
After this clip: the component's typed data model is approved and written.
The proposal you approve becomes the data-model artefact the developer imports. See Technical Execution → Component (UI).
Step 11 — Specify the component logic
What happens: /swifter-frontend-analyst:work-on-component-logic captures display rules, validation, and function signatures, and also waits at an Approve gate.
/swifter-frontend-analyst:work-on-component-logic captures the display rules, validation rules, and function signatures — for example, which tab is active and what happens when you switch tabs. It also waits at an Approve gate. These are specifications only; no code is written at this stage.
After this clip: the component's logic specification is approved and written.
Step 12 — Review the data model and logic in the App tab
What happens: the App tab's Data model and Logic views are now populated — the blueprint the developer builds from.
With both specs written, the App tab's Data model and Logic views are now populated. Notice the typed entities in the data model view and the display rules in the logic view — and that the display rules now live here as parseable rules, traced from the IF/THEN lines in the brief. This is the blueprint the Frontend Developer builds from in the next section.
After this clip: the complete specification is reviewable and ready to hand to the developer.
The display rules you see here trace back to the IF/THEN lines you authored in step 2. See Work-Item Description Composition → Principle 4.
Build with the Frontend Developer
The Frontend Developer takes over at step 13 and drives through step 15. This phase turns the specification into real Angular source — logic modules first, then the production component — and runs the project build as it goes. It comes after Specify because the developer imports the analyst's artefacts directly rather than re-deriving them.
Step 13 — Switch the chat to the Frontend Developer
What happens: the agent selector switches from Frontend Analyst to Frontend Developer in the same chat.
Watch the agent selector at the bottom of the chat switch from Frontend Analyst to Frontend Developer — the agent that has the commands and tools to turn the specification into real Angular code. This is the second agent hand-off; the chat stays the same, only who is driving it changes.
After this clip: the Frontend Developer is the active agent on this work item.
The Frontend Developer is the implementation proficiency — it compiles the analyst's spec into framework-native code. See Agentic SDLC → Proficiencies and agents.
Step 14 — Generate the standalone logic modules
What happens: /swifter-frontend-developer:work-on-component-logic workitem-content-tabs all emits types, validators, display-rule utilities, and function modules, waits at an Approve gate, then builds.
/swifter-frontend-developer:work-on-component-logic workitem-content-tabs all generates types, validators, display-rule utilities, and function modules together. Types are emitted first because the component implementation imports them. It waits at an Approve gate, then runs the project build; notice the trigger send — the gate and run are handled off-camera. These are real source files now, generated straight from the analyst's logic spec rather than re-derived.
After this clip: the component's logic exists as built, importable Angular modules.
These standalone modules are emitted before the component so the implementation can import them. See Technical Execution → Component (UI).
Step 15 — Generate the production component
What happens: /swifter-frontend-developer:generate-component workitem-content-tabs replaces the placeholder with Angular code, pauses at a mapping Approve gate, then rebuilds.
/swifter-frontend-developer:generate-component workitem-content-tabs replaces the Analyst's placeholder with framework-native Angular code: it applies the data-model types, wires in the logic modules from the previous step, maps the design onto the project's component library, and rebuilds Storybook. It pauses at an Approve gate on the mapping — confirm the library mapping there — then builds. Watch the trigger; the run finishes off-camera.
After this clip: the production Angular component exists and the build is green.
The Approve gate here confirms how the design maps onto the project's existing component library before any code is written. See Technical Execution → Component (UI).
Ship it
You are back in the driver's seat for the last three clips. This phase reviews the generated code, opens the pull request, and completes the work item — turning the build into a merged, reviewable change on main.
Step 16 — Review the generated code in the Dev tab
What happens: the Dev tab's Changes panel shows every file the developer touched — including whether package.json changed.
Open the Dev tab and the Changes panel to see every file the developer touched. Notice the component imports its types from the generated types module and reuses the display rules rather than re-implementing them. Check that package.json is not in the changed-files list unless the work item explicitly authorised a new dependency — an unauthorised dependency is a classic thing to catch here before CI does.
After this clip: you have confirmed the diff is clean and dependency-safe.
An unexpected dependency in the diff is the cheapest thing to catch now and the most annoying to catch in review. See Work-Item Description Composition → Authoring anti-patterns.
Step 17 — Create the pull request
What happens: Swifter opens the PR from the session branch into main and writes the description from the session activity.
Swifter opens the PR from the session branch into main and writes the description from the session activity. Notice the Check pull request status click immediately after — this refreshes the CI state into the work item. The CI checks run in the background; the green result arrives off-camera.
After this clip: a pull request is open and its CI status is tracked on the work item.
PR creation is the back half of the work-item lifecycle — the build becomes a reviewable change. See Work-Item Lifecycle → The seven steps.
Step 18 — Complete the work item
What happens: once CI is green, Complete merges the PR, closes the session, and moves the work item to Done.
Once the checks are green, Complete merges the pull request into main, closes the session, and moves the work item to Done. From an empty work item to shipped, reviewable Angular code.
After this clip: the component is shipped, and the work item is Done.
origin ABANDONED but Done is normalIf the work item is Done but the origin chat shows ABANDONED, that is the expected baseline pattern, not an error. See Troubleshooting → Cheat sheet.
That's the full arc
You watched one Component work item travel through three agents: the swifter-default Coordinator triaged it and handed off to the Frontend Analyst at step 5; the Analyst specified it; the Frontend Developer built it from step 13; and you shipped it. The two hand-offs — Coordinator → Analyst, Analyst → Developer — are the spine of every Swifter component, and once you can spot them, the eighteen clips read as one continuous flow.
Ready to run it yourself? The Frontend Screen Happy Path is the command-by-command companion: same flow, with the exact commands, the inline verifications, and what to do when a check fails.