finishing-a-development-branch

<execution_workflow> Execute these steps strictly in sequence. DO NOT announce the skill.

1. PRE-FLIGHT TEST & SECURITY CHECK (ADAPTIVE):

   • Run the project's test suite (e.g., npm test, pytest, cargo test) to ensure NO existing tests are broken (Regression Check).
   • If TDD Mode was Enabled: Verify all newly written tests pass.
   • If TDD Mode was Skipped: Verify that the project successfully builds/compiles, AND ensure any required security tests (from secure-coding-standard) pass successfully.
   • If ANY required test or build FAILS: Show failures to the user and STOP. Do not proceed to Step 2.
   • If tests/build PASS: Proceed to Step 2.

2. MANDATORY COMMIT (THE CHECKPOINT):

   • Run git status to check for uncommitted/staged changes.
   • CRITICAL REVIEW GATE: You MUST ensure that the requesting-code-review skill was executed and explicitly approved before proceeding. "Inline execution", "I applied secure coding standards myself", or "Tests passed" are NOT valid excuses. If the requesting-code-review skill was NOT formally executed, you MUST STOP this workflow immediately and run requesting-code-review. Do not commit until the review is fully resolved.
   • CRITICAL REMINDER: If this skill was invoked AFTER review feedback was already received and applied inline, still verify that requesting-code-review was formally dispatched earlier in the session. Inline review execution (subagent dispatched directly without going through the requesting-code-review workflow) does NOT satisfy the review gate. If formal review was skipped, STOP and run requesting-code-review before proceeding.
   • Commit the approved STAGED changes using a descriptive, conventional commit message (e.g., git commit -m "feat: implement [feature] based on plan"). If critical security mitigations were applied, mention them briefly in the commit body.
   • NEVER merge or push without committing the approved work first.

3. DETERMINE BASE:

   • Identify base branch silently (git merge-base HEAD main or git merge-base HEAD master).

4. PRESENT OPTIONS:

   • PRE-FLIGHT: Before presenting options, check if the current feature branch is already merged into base (e.g., via fast-forward performed outside this skill). Run git merge-base --is-ancestor <current-feature-branch> <base-branch> silently. If it returns true (0), the branch is already merged. In this case, SKIP Options 1-4 selection and proceed directly to Step 7 (Memory Persistence). Do NOT ask the user to choose; the merge is already a fact. Present EXACTLY these 4 options to the user. Do not add any explanations or conversational filler: "Implementation, tests, and security reviews complete. Changes are committed. What would you like to do?
   1. Merge back to locally AND update Second Brain
   2. Push, create a Pull Request AND update Second Brain
   3. Keep the branch as-is (I'll handle it later)
   4. Discard this work" Wait for user selection.

5. EXECUTE CHOICE:

   • Dirty worktree guard (before Options 1, 2, or 4): run git status --short. If unrelated dirty files are present, STOP and ask the user whether to stash them. If stashing is approved, use a descriptive stash name and later report: stash name/message, captured files, why it was needed, and whether it was reapplied or dropped.
   • Option 1 (Merge): git checkout <base>, git pull, git merge <current-feature-branch>, run tests again on merged result. If pass, git branch -d <current-feature-branch>. Proceed to Step 6.
   • Option 2 (PR): Push branch (git push -u origin <branch>). Create PR using the GitHub connector/IDE tool when available, or gh pr create otherwise. The PR body MUST include Summary, Security Notes, and Test Plan sections. Bash-compatible fallback:

     gh pr create --title "<conventional-prefix>: <feature summary>" --body "$(cat <<'EOF'
     ## Summary
     - <2-3 bullets describing what changed and why>
     
     ## Security Notes
     - <list any secure-coding-standard mitigations applied; write "None applicable." if not relevant>
     
     ## Test Plan
     - [ ] <verification steps the reviewer should run>
     EOF
     )"
     

     PowerShell-compatible fallback: create the same body in a temporary markdown file, then run gh pr create --title "<conventional-prefix>: <feature summary>" --body-file <temp-file>. Do NOT cleanup worktree.
   • Option 3 (Keep): Do nothing. Report "Worktree preserved." Do NOT cleanup worktree.
   • Option 4 (Discard): Show the user this exact warning before deleting anything:

     This will permanently delete:
     - Branch: <branch-name>
     - Commits: <list of commit hashes + first lines>
     - Worktree at: <worktree-path>
     Type 'discard' to confirm.
     

     Require them to type EXACTLY "discard" to confirm. Any other input aborts. If confirmed: checkout base, git branch -D <current-feature-branch>. Proceed to Step 6.