zagrosi-forge

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.

Resolve absolute plugin_root: the plugin directory two levels above this skill's folder, containing scripts/zagrosi_skills.py; never the target repo. Claude Code substitutes it when loading this skill: ${CLAUDE_PLUGIN_ROOT}. Literal text there means the file was read directly: derive the path; no such shell variable exists. Run every helper command, including returned argv arrays, with the exact prefix python3 "{plugin_root}/scripts/zagrosi_skills.py" (Python 3.11+; python or py -3 on Windows); host pre-approvals match that text.

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	Load
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

Load a phase by invoking its skill, such as zagrosi-forge:zagrosi-plan, where the host supports skill invocation; otherwise read and follow its SKILL.md.

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. State-first lean is opt-in: use it only when the user asks or status.json already exists.

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 another provider's 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.