---

name: zagrosi-forge description: Take a software request through the appropriate Forge workflow, from a brief or existing plan to verified code. Use for end-to-end feature work, fixes, or continuing Forge work in Codex or Claude Code.

Forge

For a Git target, check team status --target-dir "{target_dir}" with Forge’s helper before work or resume. Follow team coordination when configured or unavailable; reuse the same task across phases and delegated agents.

Choose the shortest route that completes the user's request. Inspect repository instructions, the working tree, relevant callers/tests, and any existing Forge artifacts before creating new ones. Preserve unrelated work.

Route once

Starting point	Read and follow
Several independent products or planning units	Project, then each ready unit
Feature, bug, or coherent change without an admitted plan	Plan, then Implement
Unfinished or unadmitted plan	Plan; finish its existing contract
Admitted plan or interrupted implementation	Implement; resume persisted progress
Simplify a repository or remove accumulated bad code	Cleanup

For a small change, keep one compact section; do not split it into a project. Use lean unless the user requests standard/deep or material risk warrants more investigation. Explain a depth change briefly. Every depth preserves the same behavior, ownership, and verification obligations.

An implementation request authorizes moving through planning and implementation; continue without asking again at each phase. A plan, audit, or review-only request stops at that deliverable. Ask only about unresolved decisions that materially affect the result. Existing user authorization governs commits and publication.

Quality and review

Apply the shared engineering standard throughout. Repair encountered bad code within the task's execution path, with before/after behavioral checks. Before delivery, review the changed code and relevant callers once for unnecessary complexity and regressions. Record broader debt separately instead of expanding a completed PR indefinitely.

When the user requests multiple providers/models, or an independent perspective addresses a concrete risk, use provider reviews. Keep one primary writer and consolidate findings into the existing review. Never substitute another provider/model silently or treat reviewer agreement as proof that tests pass.

Finish with the result, actual verification, remaining limitations, and the saved artifact location. Distinguish code completion, PR/CI state, and deployment.