Fix Failed Paperclip Run

Own the failure from evidence through a tested repair and a green PR. A diagnosis, a proposed plan, a successful provider turn, and a passing unit test are intermediate results. The finish line is a verified user workflow and a PR whose current commit passes the required checks and review.

Honor an explicit diagnosis-only request or a calling workflow's approval boundary. Otherwise proceed through implementation without a separate plan-approval pause. Carry forward existing authorization for merge, rollout, and recovery; do not ask again. When the assignment ends at a PR, distinguish local verification from deployment and recovery of the original task. This skill does not itself authorize merging or deploying.

1. Establish the incident and the finish line

Start from the supplied task/run URL or failure report. Resolve these facts from available tools and records before asking the user for missing information:

• Instance, company, task, affected run(s), time window, and intended useful result.
• Current state versus state at failure; parent/child tasks and pending interactions only where they control progress. Multiple failed runs can have different causes.
• The code actually served, runner/provider pack versions, operating system and architecture, adapter, model/effort, execution workspace, trust mode, and credential source. Trace effective values back through task overrides, inherited settings, defaults, and saved session state. Redact credential values.
• Which endpoint is authorized: verified fix and green PR, or also rollout and recovery. Preserve the requested work and success criteria throughout.

Use authorized diagnostic access. If company scoping blocks a read, use an already-authorized diagnostic path or label the missing evidence; do not bypass the boundary.