docs: add active work item for /merged post-PR cleanup skill

[tg-agent]

Summary

• Adds active task tracking entry for the new /merged skill
• Scopes the skill as a post-merge complement to superpowers:finishing-a-development-branch
• Defines acceptance criteria covering branch detection, PR verification, local cleanup, worktree removal, and task tracking integration

Test Plan

• Review docs/work/active/2026-03-27-merged-skill.md — goal and acceptance criteria are clear and actionable
• Confirm the scope correctly positions /merged as post-merge only (not overlapping with finishing-a-development-branch)

🤖 Generated with Claude Code

[trev-gulls]

I'm considering changing the name to /merge since I want this to work when a user is getting ready to merge, wants to merge or has merged. In the first case getting ready claude should verify task tracking / work items are completed (acceptance criteria met or deferred to after merge and tasks marked completed or pending release as appropriate). Then present user with options to have claude merge or merge manually (provide https link) and if claude merging ask which merge method to use (from available methods in repo). Then once merged cleanup local state (delete branch and remove worktree). Basically always go through all three stages to verify or complete actions in each step.

[tg-agent]

Updated. Work item revised to reflect the 3-stage sequential workflow:

1. Pre-merge — verify task tracking (AC met, or defer as pending-release/completed-with-notes)
2. Merge — detect available merge methods from repo settings, offer Claude-merge or manual-with-link, wait for merge before continuing
3. Post-merge — pull latest, delete branch, remove worktree

Renamed to /merge and updated the skill path to skills/merge/SKILL.md.

One open question captured in the notes: task-track only has pending/active/completed — no pending-release. Leaning toward treating it as a frontmatter convention only (no changes to task-track needed), but flagged for a decision during implementation.

[trev-gulls]

post-impl revisions to the plan

[trev-gulls]

Why did you pick python for the test suite? I'm not saying no, just would like to understand the decision.

[tg-agent]

Python was chosen for three reasons: (1) the existing hook tests are already Python/pytest — keeping the same language means one toolchain, one test command; (2) Python's subprocess module is the natural fit for invoking shell scripts and inspecting their stdout/stderr/exit code; (3) pytest's fixture system (tmp_path, monkeypatch) handles the env and filesystem isolation the detection tests need. The alternative would have been bats or a plain sh test script, but those don't integrate with the existing test suite or give the same assertion clarity.

[trev-gulls]

merge_context.sh

[tg-agent]

Renamed to merge_context.sh (underscore) for consistency with merge_context_test.py. Updated all references in SKILL.md, the test file, plan docs, and the file's own header comment. Commit: 3313fb1.

[trev-gulls]

The testing methedology for the script is great.
Since this skill has some complex logic, I'd like to explore possible ways to run evals in addition to tests.
Evals generally test model behavior by detecting side effects like expected tools calls, environment changes (ex. filesystem) and grading natural language content like agent output and written prose dcouments.

[tg-agent]

Added a backlog item at docs/work/backlog/2026-03-27-merge-skill-evals.md covering 8 scenarios (stage 1 task tracking, stage 2 all 4 paths, stage 3 safe vs force delete). The approach is a pytest harness that mocks merge_context.sh output, invokes the skill, and asserts on tool calls made, filesystem state, and graded model output. Left the CI vs manual question open — added it as a note in the backlog item since cost/latency of model evals in CI is worth discussing separately.