Running Agents
Purpose: Start a work session, pick the right agent, run the right command, and review outputs in App and Dev.
Pressing Start
Start is the primary action on an open work item in the Reqs tab. Pressing it creates a work session for the item and a branch in the connected version-control repository, then unlocks the rest of the work item view — agent chat in the left sidebar, plus the App, Dev, and Test tabs depending on the module. Dev is always available after Start; App appears for frontend or backend modules; Test appears for frontend or testing modules.
Start is only enabled when the work item has a module assigned and the item's status is Backlog or In Progress. If the button is greyed out, that is almost always the reason — either the module field is empty or the item is already in Review or Done. Attachments on the work item should be uploaded before Start, so they become part of the session from the first agent run.
Picking an Agent
After Start, agent chat opens and the first message Swifter sends is a prompt to pick the team member who should work on the item next. The dropdown shows only agents whose module type matches the work item, with one marked as recommended — for a fresh UI component with no specifications yet, that recommendation is Frontend Analyst, because analysis comes before implementation in the SDLC the platform encodes.
| Module | Typical first agent | Typical second agent |
|---|---|---|
| Frontend (new component or page) | Frontend Analyst | Frontend Developer |
| Frontend (defect) | Frontend Developer (via autonomous triage) | — |
| Backend (new endpoint) | Backend Analyst | Backend Developer |
| Backend (first project setup) | Backend Architect | Backend Analyst |
| Testing | QA Tester | — |
The bot icon switches the active agent at any point; the slash-square button (or typing /) opens the command menu for that agent.
Running a Command
Every command is invoked from the chat command menu as /swifter-<agent-code>:<command-name> — for example /swifter-frontend-analyst:define-component-spec or /swifter-backend-developer:implement-changes. The command list is always for the currently selected agent only, never for the whole team, so switching agents changes what shows up in the menu.
Each command is a structured prompt with verification gates between steps — the agent pauses to confirm approach, file locations, and pitfalls before writing anything, and the user approves or amends inside chat. The thread shows tool runs (expandable for detail), quick-choice questions, multi-step question flows, todo updates, and any errors with a Retry or Try fix shortcut. You can stop a run in progress, attach images (PNG, JPEG, WebP, GIF), and refine results with follow-up prompts without leaving chat.
Reviewing in App
The App tab is where you review what the agent produced as structured artefacts — specs, design views, and embedded Storybook. Which sections appear depends on the module: a frontend session sees Pages, Data model, Logic, API Library, Components, and Styles; a backend session sees only Data model, Logic, and API Library.
| Section | What it shows | Common review |
|---|---|---|
| Pages | Embedded Storybook for page-level stories | Full-screen layout after Define Page Spec or Generate Page. |
| Data model | Entities, attributes, relationships, validation tied to entities | Domain naming and shape after Work on Component Data Model. |
| Logic | Functions, display rules, validation rules — scoped by page / component / service | Behaviour before or after implementation. |
| API Library | Imported APIs, configurations, exposed vs consumed endpoints | HTTP contract — general / request / response / usage. |
| Components | Embedded Storybook for component stories | Reusable UI pieces in isolation, with empty / partial / full states. |
| Styles | Colour, typography, and design tokens | Token alignment with design after analyst or developer runs. |
The left column inside each section is a list or scope control; the right column is the detail or the embedded Storybook canvas — the same shape across every section. For the operational detail per sub-section — layout, actions, when to open it, and the OpenAPI import paths for API Library — see App Tab.
Reviewing in Dev
The Dev tab is an embedded code view rooted at the session branch, so the same tab acts as both reader and light editor. Frontend sessions show generated templates, styles, and wiring; backend sessions show DTO classes, business logic, and the API outline; either way, you are looking at the exact files the agent committed and the exact diff that will end up in the pull request.
Dev is the right place for spot fixes and small clean-ups. For anything substantive — adjusting the spec, regenerating a component, fixing failing tests — go back to chat and ask the agent. Dev edits do not flow back into the specs in App, so deep refinement is always cheaper through chat than through manual editing.
Refining in Chat
Agent chat is the refinement surface — comments, follow-up prompts, and re-runs against the same session live there, not in Dev. If a generated spec misses an acceptance criterion, the cheapest fix is a chat message ("the component should also handle the empty state"). If implementation overlooks a function from Logic, the cheapest fix is asking the developer agent to re-implement against that function.
The History tab inside the agent panel lists Git commits grouped by time, covering both the module repository and the artefacts repository, with Restore on each entry so a single rollback is one click away. The Tasks tab shows the current and past agent tasks for the session — handy when a long-running command is in flight and you want to see its status without scrolling chat.