AI Product Team and Forge

I want AI-built work to keep its reasons attached. AI Product Team organizes product decisions and their evidence, while Forge challenges the plan and coordinates the build. Both are open source and now have editions for Claude Code and Codex. Each works on its own; using them together means giving the next workflow the approved records from the last.

For a small, well-defined edit, one assistant is often enough.

The case for these tools begins when work passes between people or agents. A restriction can disappear from a brief, leaving the builder to solve a different problem. Even a passing test can mislead if it belongs to an earlier version. The next person needs to see what was decided and which checks still apply.

What each project does

AI Product Team contains 64 specialist roles, 28 shared methods, and 12 workflows. You choose a task, such as shaping a feature or reviewing a release, and the workflow selects the relevant roles. Your current session dispatches their work and maintains a record connecting sources to decisions.

Forge picks up the planning and coding work. Its six skills cover the initial interview, plan review, single-unit builds, coordinated builds, documentation, and recovery. A second model challenges the plan before building begins. Larger jobs can use separate Git worktrees, giving each worker its own checkout.

In the Claude Code edition, Claude directs the work and Codex reviews or builds assigned units. Ten agents divide the responsibilities, while four scripted workflows handle plan review, decomposition, build waves, and recovery audits. The driver reviews the results and holds commit authority.

The Codex edition reverses those roles. Codex directs the work and reaches Claude through a local bridge for starting and supervising jobs. Five custom Codex agents cover execution, planning, verification, progress monitoring, and documentation. Here, the skills supply the workflow steps; the four scripted workflows belong to the Claude edition. Automated recovery in Codex is currently paused.

Think of a cabinetmaker’s drawing and cutting list. The drawing records what must fit, and the cutting list turns that intent into pieces. A well-cut panel can still belong to the wrong cabinet. The handoff keeps the finished object answerable to the drawing.

Start with a task you recognize

Turn conflicting documents into a feature proposal. The fictional support-copilot example in AI Product Team pairs an old presentation proposing automatic replies with a current policy permitting drafts only. Run aipt-shape-feature and check whether that restriction survives into the requirements and acceptance checks. Losing it means the exercise failed, however fluent the proposal sounds.

Repair a bug whose cause you already understand. Give Forge the reproduction and expected behavior. Use forge to develop the plan, or forge-build with an approved work order. Ask for a test that fails before the repair and passes afterward, then inspect the changed code alongside those results.

Decide whether a prototype is ready for a pilot. Give aipt-review-release the build version, intended audience, and test results. It examines the evidence against the proposed rollout and identifies unresolved findings for a human decision. Deployment remains a separate step.

Connect the work through shared records

For the support-copilot example, keep the approved brief and acceptance checks in the project alongside the code. Ask Forge to read that version, then ask AI Product Team to review the resulting build and evidence. The session can read the files directly; you do not need to copy every agent’s output between tools.

The human work is to approve scope and explicitly invoke the next workflow with the right records. Each toolkit coordinates its own agents. Forge’s bridge connects Claude and Codex within Forge, but the two repositories do not yet share a controller that starts the next workflow automatically. That is the connection still to build.

1. Shape the feature with AI Product Team. Preserve the drafts-only requirement and its source, with an acceptance check proving that sending needs a human action.
2. Give Forge a bounded work order. Point it at the approved requirements and their version, allowed files, and expected checks. Begin with one change.
3. Review the plan before building. Return any proposed requirement change for a product decision, then update the approved record before work continues.
4. Review the result against the brief. Ask AI Product Team to read the exact code version and command results alongside the acceptance checks. Failed checks return to repair.

For that first handoff, an instruction could read:

Read the approved brief in this project and plan a reply-drafting prototype. Preserve the rule that sending requires a human action. Identify the files you need to change and how you will test that boundary. Return any proposed requirement change for my decision before building.

Keep the first experiment small enough to trace one requirement through the plan, code, and test yourself.

What the checks establish

AI Product Team’s ledger rules distinguish claimed results from observed command output, and historical passes from evidence for the current build. Enforcement relies on agent instructions and host restrictions; the experimental controller is unfinished and disconnected from the hosts. Live workflow behavior remains unvalidated.

Forge adds executable launch checks. The Codex edition’s scheduler records Claude jobs and native Codex work in a shared ledger, reserving declared files and capacity together before launch. That reduces the chance of two workers being admitted against the same available slot. The sprint profile uses a targeted check; assured adds cross-model review and a driver rerun.

Execution settings differ by edition. The Codex bridge configures sandboxed Claude jobs and refuses an unavailable sandbox. The Claude edition’s Codex build templates bypass sandboxing, so review the settings for the route you choose.

Forge publishes offline tests, with known test limitations including stale replay fingerprints and timing-sensitive cases. This is evidence about particular mechanisms. It does not establish that either project, or the proposed combination, produces better work than one assistant.

Get the code and try one workflow

Both repositories use the MIT license, so you can adapt them or keep only the parts you need.

Start AI Product Team with its support-copilot walkthrough, using Python 3.12 or later and either coding assistant. After installation, open the example project and try:

/aipt-shape-feature Turn the documents in support-copilot/corpus into a feature proposal.

In Codex, use $aipt-shape-feature.

For Forge, choose the Claude Code setup or install the Codex edition:

codex plugin marketplace add 3orionkings/forge
codex plugin add forge@forge

Start a new Codex session, review and trust the workspace hook through /hooks, and copy the five custom agents as the README describes. The plugin installation does not include those agents, and the bridge refuses calls without the trusted hook. Try forge-review on an existing plan before commissioning a build.

Would a studio application earn its place?

A custom studio could put the approved brief beside the current build, with failed checks and pending decisions visible together. It could carry the handoff and preserve the history across sessions. That would require a coordinator connecting both projects, beyond Forge’s existing model bridge.

Would that save enough effort to justify another application, or do these tools belong inside the coding assistants people already use? A run report describing an awkward handoff would help me decide. I will return to this page if I pursue the studio. For now, I want to see where shared records and explicit approvals stop being enough.