From a ChatGPT idea to release: a multi-tool AI product workflow
Emanuele Bartolesi describes a product workflow where no single agent does everything: ChatGPT settles requirements into a PRD, Antigravity turns it into a GitHub backlog, Copilot CLI implements, Claude Code reviews, and Playwright plus GitHub Actions carry validation. The durable part is the context that travels between tools: a PRD committed to the repo, AGENTS.md instructions and dotcraft, his plugin of skills and agents.
Key points
- Committing the PRD as docs/PRD.md keeps decisions from the ChatGPT session alive for Copilot CLI and Claude Code
- Antigravity with Gemini 3.8 Flash turns the PRD into epics and child issues via the GitHub CLI, using native parent/sub-issue links
- With dotcraft installed, Copilot CLI produces one commit per issue and a single PR; the epic closes only when every child issue is validated
- Manual model choice is reserved for cases like UI work (GPT-6.1 Sol or GPT-6 Astra); Copilot Fusion is the default elsewhere
- Playwright tests assert real journeys such as creating, editing and re-reading an entry, and CI uploads traces and screenshots on failure
- YOLO mode drops approval prompts but does not make commands safe; the responsibility stays with the developer
The workflow starts before any code exists: requirements are hammered out in ChatGPT and committed as docs/PRD.md, so vague lines like "users can export their data" get answered on data, format and archived records. Antigravity, running Gemini 3.8 Flash, turns that document into epics and child issues through the GitHub CLI using native parent/sub-issue links, and the backlog is still checked by hand before implementation.
On the code side, Copilot CLI runs with dotcraft installed: one commit per issue, a single pull request at the end, Playwright covering repeatable browser flows and validation mapped to acceptance criteria. Claude Code then reviews across the whole epic, but the author reads the diff and decides. The point is to keep the same context when models and tools rotate; dotcraft's skills and agents such as blazor-saas-stack, bunit-testing and csharp-expert carry the shared defaults.
Real-world use
- A solo developer juggling several agents on one product who does not want to re-explain architecture decisions every session
- Splitting a new feature into epics and issues generated from a PRD before any implementation starts
- A Blazor or MudBlazor SaaS where testing and validation expectations stay fixed no matter which agent implements the change
- Replacing manual click-throughs after each change with Playwright journeys wired into pull request validation
Why it matters
The real cost of switching agents is losing decisions made two sessions ago; keeping the PRD and skills inside the repository preserves most of that context. And a clean AI review still does not prove you asked for the right behavior, so the final read stays with a human.