Workspace vs direct engine
Keep your engine, add a shared workspace or work directly in its own interface.
| Capability | Firstbeam workspace | Direct engine |
|---|---|---|
| Organization | Project conversations, teams and plans together | The engine’s own interface and session tools |
| Accounts | Engine selection and account scope | Native engine authentication |
| Tools | Discover existing skills and MCP bindings | Configure and inspect tools in the engine |
| Editing | Keep your preferred editor beside the workspace | Use the engine’s own editing workflow |
| Billing | Firstbeam plan and provider access are separate | Provider’s own plan and usage policy |
How to decide
Start with the job you want to complete, then select the surface and permission level that make the result easiest to review. Provider access, model availability and charges remain governed by your selected accounts.
Describe success first
State the behavior you want and the constraints that must remain. Include a screenshot when visual alignment matters, and describe how the page should behave on narrow windows. A reference is useful only when the agent knows which structure to preserve.
Inspect the existing behavior
Ask for the current data flow, persistence and runtime actions to be checked before replacing an interface. A visual redesign should still use real project data, account configuration and existing actions; attractive controls that do nothing are incomplete.
Verify at the appropriate layer
Use unit or interaction tests for logic and actions, a browser for actual layout and native tests for OS behavior. A mocked microphone response cannot prove real Windows recording. A test screenshot should identify fixture data instead of implying it is the installed app.
Finish with an honest handoff
Report what changed, how it was checked and what remains uncertain. Link the actual artifact or changed files. Keep the next task bounded by those limits rather than repeating an overly broad claim that everything is complete.
A visual correction done end to end
Start with the supplied screenshot and identify the differences in spacing, controls and content hierarchy. Implement the page using its real persistence and runtime actions. Check a populated state, a small state, narrow windows and keyboard interaction. Then verify that the packaged build contains the same source and that the published download points to it.
Resume from evidence
When work is interrupted, read the latest handoff and inspect the working tree before restarting tests or builds. Preserve completed checks unless new changes invalidate them. Be explicit about the difference between source completion, successful packaging, live distribution and acceptance in the owner’s actual environment. Each is a separate checkpoint.
Compare side by side
Choose a guide for the full table and practical setup steps.