MCP-OpenProject/.claude/commands/speckit.push.md

description
Push the current branch to the remote with branch protection checks and OpenProject integration.

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Outline

1. Resolve remote URL: Run git remote get-url origin to get the remote URL. All commit and branch references in this skill MUST use the remote URL (e.g., <remote-url>/commit/<hash>, <remote-url>/src/branch/<name>). Never use bare hashes or local-only references.
2. Check the current branch name with git branch --show-current.
3. If the branch is main or master, do NOT push. Instead:
   • Warn the user that this is a protected branch.
   • Suggest creating a new branch using one of these conventions based on the changes:
     • feat/<short-description> — for new features
     • fix/<short-description> — for bug fixes
     • docs/<short-description> — for documentation changes
     • refactor/<short-description> — for refactoring
     • build/<short-description> — for build/infra changes
     • test/<short-description> — for test additions or fixes
     • chore/<short-description> — for miscellaneous changes
   • Let the user decide the next action. Do NOT create the branch or push automatically.
4. OpenProject sync (BEFORE pushing):
   • Run /speckit.updateOP to ensure OpenProject work packages are in sync with current specs/tasks.
   • After sync completes, identify the relevant OpenProject work package for the current branch/feature (milestone or phase WP).
   • Run git log --oneline origin/HEAD..HEAD (or equivalent) to get the commits about to be pushed.
   • For each commit, construct a link using the remote URL resolved in step 1: <remote-url>/commit/<hash>
   • Add a comment to the relevant OpenProject work package via mcp__openproject__add_work_package_comment with:
     • Commit hash(es) as Gitea links
     • Brief summary of what is being pushed
   • If no relevant work package can be identified, warn the user and ask whether to proceed without logging.
5. If the branch is not protected, run git push (with -u origin <branch> if no upstream is set).
6. If the push succeeds, report success to the user including the OpenProject sync and comment logged.
7. If the push fails due to a git hook or any other error:
   • Summarize the error clearly and concisely for the user.
   • Do NOT attempt to fix the issue, amend commits, or re-push.
   • Let the user decide the next action.