ADR-363: Trim final-sign-off to near-no-op; split work-with-pr hand-off ops

[jodavis-claude]

Work item

ADR-363: Trim final-sign-off down to a near-no-op status report and work-with-pr's hand-off section down to bare, individually-callable mechanical operations, and remove all remaining REVIEW_ASSIGNEE_EMAIL references — because promote/assign/request-review behavior now lives in after-hand-off config instructions (shipped by ADR-360/ADR-361), executed generically by run-event-hooks, not hardcoded inside these two skills.

Changes

• plugins/dev-team/skills/final-sign-off/SKILL.md — deleted the former steps 1–5 (convert PR to ready, look up reviewer via $REVIEW_ASSIGNEE_EMAIL, assign Jira issue, request GitHub review, add Jira comment). Replaced with a single near-no-op step that writes a short, non-empty confirmation as the skill's own output, which workflow-worker places into the Handoff Result context section. Reworded the frontmatter description: and lead-in paragraph to state the promote/assign/request-review work is now performed by the pipeline event's after-hand-off instructions via run-event-hooks. argument-hint: <pr_url> <work-item-id> left unchanged since HandoffStep.get_actions() still passes both.
• plugins/dev-team/skills/work-with-pr/SKILL.md — replaced the "Requesting human review (approved sign-off only)" section (the fixed 3-step numbered sequence ending in $REVIEW_ASSIGNEE_EMAIL) with a new "Hand-off operations" section containing three separately-headed, independently-callable operations: convert-to-ready, request-review, and assign-issue (the last via work-with-Jira-tasks's lookupJiraAccountId then editJiraIssue). The $REVIEW_ASSIGNEE_EMAIL lookup is gone entirely — every operation now takes the reviewer/assignee identity as a literal argument the calling instruction supplies. All other sections ("Extracting PR details from a URL", "Reading the PR", "Posting a review", "Responding to and resolving threads") were left untouched, since review-sign-off, review, and fix-pr depend on them.

Design decisions

• Both components are classified Wrapper in the spec's Component Breakdown table (thin call-through, visual inspection sufficient per component-taxonomy), so verification is inspection-based: the exit criteria's Gherkin scenario was walked through manually against the updated skill text and this repo's own .dev-team/config.yaml after-hand-off instructions rather than built as an automated fixture harness.
• work-with-pr's assign-issue operation is documented and independently callable per the spec's literal Component Breakdown text, even though today's only caller (run-event-hooks, out of this task's ownership) currently dispatches Jira assignment directly against work-with-Jira-tasks rather than by this name. Flagged as a non-blocking known ambiguity.
• Opened a follow-up issue (Stale handoff/final-sign-off description in workflow-orchestrate plan assets (post-ADR-363) #98) for two adjacent, out-of-scope files whose prose still describes final-sign-off's old behavior, rather than touching them here.

Testing completed

No dedicated unit tests: both components are Wrapper-classified (thin, prose-only call-throughs), and per component-taxonomy/implement-direct guidance no dedicated unit test is written for this tier — visual inspection is the appropriate substitute. No new Gherkin feature file: the task brief's own exit-criteria scenario ("Hand-off promotes the PR and assigns the configured reviewer") was designated for manual walkthrough rather than an automated fixture harness (no such harness convention exists yet for prose-only Wrapper skills in this repo). The manual walkthrough traced every Then clause against the updated skill text and this repo's real after-hand-off config and confirmed all pass, with no REVIEW_ASSIGNEE_EMAIL read anywhere.

[jodavis-claude]

Reviewed against ADR-363's exit criteria in _spec_WorkflowEventHooks.md and the task brief.

Summary: Clean, tightly-scoped change. Both files match the exit criteria exactly:

• final-sign-off/SKILL.md is reduced to a single near-no-op step, with its description: reworded to stop overpromising.
• work-with-pr/SKILL.md's hand-off section is replaced by three independently-named, mechanical operations (convert-to-ready, request-review, assign-issue), each taking the reviewer/assignee identity as a literal argument.
• No REVIEW_ASSIGNEE_EMAIL reference remains in either file (confirmed via repo-wide grep — the only remaining hits are in the spec doc's narrative prose, which is out of scope here).
• Operation names (convert-to-ready, request-review) match run-event-hooks/SKILL.md's existing dispatch table verbatim, so no follow-up rename is needed.
• The other work-with-pr sections (Reading the PR, Posting a review, Responding to and resolving threads) are untouched, and review-sign-off, review, and fix-pr only reference those preserved sections — confirmed nothing broke for their callers.
• HandoffStep dispatches final-sign-off via dev-team:developer (full Jira+GitHub access), so the new assign-issue operation (via work-with-Jira-tasks) is reachable in the one place it's used today.
• Verification approach (manual Gherkin walkthrough, no new unit tests/fixtures) matches the Wrapper classification in component-taxonomy/SKILL.md and the spec's own "inspection-based" verification note.

No Priority 1-4 (requirements/correctness/security/performance) issues found. No inline comments needed — the diff is small and every criterion is met by direct inspection.

One non-blocking observation (already flagged by the author in the brief, not new): work-with-pr's assign-issue operation currently has no live caller going through it by name, since run-event-hooks's dispatch table resolves "Assign work item to " directly against work-with-Jira-tasks instead. That's a pre-existing inconsistency between run-event-hooks (out of this task's ownership) and the spec text, not something this PR needs to fix.

Approving.