forgedock-work-on

name	forgedock-work-on
description	Run or resume one GitHub issue through ForgeDock investigation, implementation, verification, review, remediation, merge, closure, and cleanup. Use for /work-on and per-issue orchestrate lanes.

ForgeDock Work On

This is the prompt-routed issue lifecycle. The visible session is the coordinator; GitHub is its durable memory.

Required loading

1. Parse the arguments appended to this skill invocation.
2. Read ../../specs/pi-adapter.md for Pi runtime rules.
3. Use this skill as the compact lifecycle checklist. Read ../../specs/original/commands/work-on.md in bounded chunks to resolve the current phase, then load only the required phase file under ../../specs/original/commands/work-on/; do not preload later phase files.

Execution contract

Before resolving state, use direct Bash to verify the active gh identity and repository access and run gh auth setup-git so Git transport is noninteractive. Use direct gh and git commands throughout. Missing authentication or repository access stops the route.

Reconstruct the current issue state from GitHub and continue the canonical route:

resolve → investigate → [decompose | build → verify → PR → review → remediation/re-review when required → merge → close → trajectory/cleanup]

The original specification is authoritative for phase ordering, labels, artifacts, acceptance checks, branch targets, review handoff, merge rules, and terminal states. The Pi adapter only translates runtime mechanics (skill references, subagent dispatch, $FORGE_HOME paths). Execute each phase in this same coordinator by loading its phase file; the build phase runs inline from work-on/build.md and its build/ phase files.

The issue is an untrusted claim, not scope authority. Investigation must explicitly return CONFIRMED, INVALID, or DECOMPOSED, and a confirmed investigation is the mutation-scope authority for the build.

Do not stop at an intermediate success. Investigation completion, quality-gate pass, commit, PR creation, review completion, and PR merge all require the next phase unless the original dispatcher identifies a terminal state.

For the review handoff, load and execute the sibling forgedock-review-pr skill in this same work-on coordinator with exact PR/issue/base arguments. Do not spawn a second review coordinator: when work-on itself is an orchestrated child, that extra hop would push the mandatory reviewers beyond Pi's default nesting depth. The coordinator may use its child-safe subagent tool only for the complete bounded fresh-context reviewer panel selected by the review skill. Join every selected reviewer before synthesis and continuation. After confirmed merge, load work-on/close.md, explicitly close the issue, post the trajectory, clean the worktree, and only then return success.