Update to Servotab

{
  "description": "Finish a development change safely by inspecting the final tree, verifying at the right scope, and performing only the requested Git or PR actions.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 378
    },
    {
      "relative_path": "assets/icon-400.png",
      "size_in_bytes": 1251
    },
    {
      "relative_path": "assets/icon.svg",
      "size_in_bytes": 1076
    }
  ],
  "name": "finish",
  "skill_md_contents": "---\nname: finish\ndescription: \"Finish a development change safely by inspecting the final tree, verifying at the right scope, and performing only the requested Git or PR actions.\"\n---\n\n# Finish\n\nClose the work without turning completion into an automatic merge ritual.\n\n## 1. Inspect final state\n\nCheck:\n\n- Current branch and workspace type\n- `git status --short`\n- Final diff and diff statistics\n- Untracked, generated, or temporary files\n- Debug logging, TODOs, fixtures, snapshots, or local config accidentally changed\n- Secrets or sensitive data\n- Whether unrelated user changes are present\n- The canonical active path and its callers, including any superseded helper, flag, test, or documentation claim left by the replacement\n\nDo not modify or discard unrelated changes.\n\nWhen replacement is complete, remove the superseded path in the same change. Retain compatibility only for an evidenced current caller or staged boundary, and name the reason and removal condition; an inert parallel implementation is not a rollback plan.\n\n## 2. Check requirements\n\nMap the final implementation to the requested behavior:\n\n- Completed acceptance criteria\n- Intentionally omitted items\n- Plan deviations\n- Alignment with the applicable authorized goal and current programme\n- Compatibility or migration status\n- Documentation or setup changes\n- Remaining risks\n\nDo this once. Do not reopen accepted design decisions without evidence. Treat implementation deviations as evidence to review, not as authority that settles product meaning. Before integration, require applicable approval for any change to programme order, trust boundaries, or accepted product scope.\n\n## 3. Verify\n\nUse a risk-matched verification ladder:\n\n- Focused regression or behavior checks\n- Adjacent suite or build for shared code\n- Broad checks for integration, migration, security, or public contracts\n- Manual or visual verification where relevant\n- Fresh named-host acceptance after the final relevant deployment when the behavior is host-specific\n\nRun checks after the final relevant edit. State exactly what passed and what was not run.\n\n## 4. Review the diff\n\nPerform a compact self-review for:\n\n- Correctness\n- Accidental scope\n- Data/state consistency\n- Error paths\n- Compatibility\n- Test value\n- Avoidable complexity\n\nFor high-risk work, one independent reviewer can add value. Verify that reviewer’s findings yourself. Do not require duplicate reviewers for ordinary changes.\n\n## 5. Documentation\n\nUpdate durable documentation when the change affects:\n\n- Public behavior or APIs\n- Setup, configuration, or operations\n- Data contracts or migrations\n- Architecture decisions another person will need\n- User-facing workflows\n\nDo not add changelog noise for invisible local refactors unless repository policy requires it.\n\n## 6. Git and integration\n\nOnly commit, push, merge, or create a PR when the user requests that action or applicable repository/global instructions delegate it.\n\nWhen committing:\n\n- Preserve unrelated user changes.\n- Stage intentionally, not with blind `git add .`.\n- Use focused commits when it improves review or rollback.\n- Follow repository message conventions.\n\nWhen preparing a PR:\n\n- Identify the correct base branch.\n- Summarize behavior and risk.\n- Include verification evidence.\n- Mention migrations, rollout, screenshots, or follow-up where relevant.\n\nWhen work remains local, report the branch and workspace path.\n\n## Destructive cleanup\n\nFor workspace cleanup, read and apply the Worktree method’s shared removal and authorization contract before acting. From the router use `references/worktree.md`; from the explicit finish leaf use `../worktree/SKILL.md`. Incidental cleanup covers only this workflow’s resources; an explicit request can also select pre-existing worktrees. Present exact targets and actions, protect ignored/local data and current tips, recheck each candidate immediately before removal, and verify preserved refs afterward. Existing authorization for the exact batch is sufficient; do not request it again.\n\nParking may remove an unmerged checkout while preserving a durable named ref and restoration route. Removing a checkout does not authorize deleting its branch, discarding data, or pruning registrations. Deletion of branches, changes, generated data, or stashes requires explicit authority for that action. Respect active tasks, locks, and the host’s lifecycle; use supported host cleanup for host-managed worktrees. Leave uncertain items pending while completing independent authorized items.\n\n## Completion report\n\nProvide:\n\n- Result\n- Main areas changed\n- Verification and exact outcomes\n- Git/PR state\n- Remaining risk or blocked checks\n\nKeep it compact and factual.\n"
}