Menú
Wrap up a work session - organize commits, push branch to remote, update task state
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | wrap |
| description | Wrap up a work session - organize commits, push branch to remote, update task state |
Wrap up a work session by organizing changes into logical commits, pushing the branch to remote, and capturing task state. Work is NOT complete until git push succeeds.
/wrap
hive hc tasks that were explicitly worked on during this session.Execute ALL steps in order.
git status
git diff --stat
git log --oneline -10
Understand what's changed, what's staged, and what's already committed.
If there are uncommitted changes:
git diff, git diff --cached, and untracked files.scratch.py - temporary test file").git add <files>.Do NOT use git add -A or git add .. Stage specific files for each logical commit.
Discover available tasks and run checks:
mi --ls: Lists all available tasks across Taskfile, Makefile, and mise. Look for check, lint, test, fmt targets and run them with mi <task-name>.go test ./..., npm test, cargo test, etc.) only if mi finds no relevant targets.Run whatever applies. Fix failures before proceeding. Do not push broken code.
Skip this step if only documentation or non-code files changed.
Only for hive hc tasks explicitly worked on during this session:
# Mark completed tasks
hive hc update <issue-id> --status done
# Add progress notes to in-progress tasks
hive hc comment <issue-id> "Progress: <what was done>"
# Create follow-up tasks for incomplete work
hive hc create --title "Follow-up: description"
Skip this step entirely if no hive hc tasks were part of this session.
Determine push strategy:
git rev-parse --abbrev-ref @{upstream} 2>/dev/nullgit push -u origin <branch-name>git pushForce push policy: Check git reflog for rebase entries during this session. If a rebase occurred, use --force-with-lease. Otherwise, use a normal push. Never use --force.
If push is rejected (non-fast-forward) and no rebase happened during the session, do NOT auto-rebase. Ask the user:
Push was rejected. The remote branch has diverged. Options:
- Rebase onto remote and force-push with lease
- Merge remote changes
- Abort and investigate
git status
git log --oneline origin/main..HEAD
Confirm working tree is clean and branch is pushed to remote.
After completing all steps, report:
## Wrap Complete
### Branch
`<branch-name>` -> `origin/<branch-name>`
### Commits Pushed
- [sha] commit message
- [sha] commit message
### Skipped Files
- `file` - reason
### Tasks Updated
- Done: #[id] [title]
- Commented: #[id] [title]
- Created: #[id] [title]
### Status
- Working tree: Clean
- Remote: Up to date
- Remaining open tasks: [N]
Omit sections that have no content.
git add -A or git add . - Stage specific files per logical commitgit status output--force-with-lease (never --force) when force-pushing after rebaseDo NOT auto-rebase. Present options to the user and wait for direction.
Fix the issue, re-run tests, commit the fix, then push.
Ask the user for a branch name, create it, then continue with normal wrap workflow.
Best practices for working with Go codebases. Use when writing, debugging, or exploring Go code, including reading dependency sources and documentation.
Autonomous orchestration loop for hive hc tasks. The high-capability manager model reads pending tasks, delegates implementation to cheaper worker sub-agents, critically reviews their output, and commits only code that passes quality checks. Runs to completion without stopping to ask questions.
Post-implementation design re-evaluation. After a feature reaches a working state through iteration, step back and re-examine what actually got built: are the data structures and algorithms the right fit for the access patterns that emerged, can code paths that grew through iteration be consolidated, and what iteration residue (tests for abandoned designs, dead flags/scaffolding, debug logging) should be deleted. Produces a tiered proposal report and applies only approved changes. Use when the user says "rethink this", "step back and re-evaluate", "is this the right design/data structure", "apply CS fundamentals", or wants a design pass on a working feature branch before PR. Not for bug-hunting (/review) or expression-level polish (/simplify) — this questions the design those skills preserve.
Orchestrate parallel claude and codex CLI agents through tmux to deliver a feature end-to-end. The orchestrator delegates planning, work, and review to spawned agents in tmux windows; it does NOT write or edit code itself. User-invoked only.
Open the current branch's diff (or a specific PR) in Plannotator's browser-based code review UI and act on the returned feedback. Use when the user says "review my changes in plannotator", "open the diff for review", "review this PR in plannotator", "let me annotate the diff", or returns to a session to gate code the agent produced.
Single-pass code review of the current branch (or a diff) that routes the changes to relevant concerns, dispatches fresh-context reviewer sub-agents, verifies findings to strip false positives, and reports a ranked, evidence-backed review. Use when the user asks to review local changes, a branch, or a PR before it goes to humans.