vigilante-issue-implementation

Vigilante Issue Implementation

Overview

Implement one GitHub issue from Vigilante dispatch through validated code changes, a pushed branch, and an opened pull request from the provided worktree. Always work inside the assigned worktree, always respect repository instructions, and always keep the GitHub issue updated with start, plan, progress, PR, and failure comments.

Inputs

Require these inputs from Vigilante:

• issue number
• issue title and URL
• repository slug
• local repository path
• assigned worktree path
• branch name

Workflow

1. Inspect issue and repository constraints

• Read the issue details supplied by Vigilante and confirm the issue scope before coding.
• Read development constraints from repository markdown files before making changes:
  • AGENTS.md when present
  • README.md
  • other root or area-specific docs that affect touched files
• If repository instructions conflict, follow the more specific instruction.

1. Announce session start on GitHub

• Post a comment on the issue as soon as work begins using vigilante gh issue comment.
• Include that Vigilante launched the session, the working branch, and that implementation is in progress.

1. Post an implementation plan early

• After inspecting the issue and repository constraints, post a concise implementation plan to the issue using vigilante gh issue comment.
• The plan comment should describe the intended development steps before substantial code changes begin.
• Keep the plan concrete and short so readers can understand what will happen next.

1. Detect a stacked base branch

• Before implementing, scan the issue body for an explicit, single-line directive of the form Base branch: <branch-name> (label is case-insensitive; <branch-name> is trimmed and may be surrounded by backticks).
• Only honor the directive when it appears as its own top-level line in the issue body. Do not infer a stacked base from prose, linked issue numbers, native sub-issue relationships, or branch names mentioned elsewhere in the issue.
• If no such directive is present, follow the default workflow: branch from and target the watch target's base branch as today.
• If the directive is present:
  • Run git fetch origin <base> from inside the assigned worktree before any other code changes.
  • If git fetch origin <base> fails because the branch does not exist on the remote, stop work, post a failure comment on the issue explaining that the specified stacked base branch is missing on the remote, and do not silently fall back to the default branch.
  • When the fetch succeeds, re-root the work branch onto origin/<base> with either git reset --hard origin/<base> (preferred when the assigned branch has no commits yet) or git rebase origin/<base> (when commits already exist on the work branch).
  • Use <base> instead of the repository default branch when opening the pull request later in the workflow.
  • Mention the stacked base branch in the implementation-plan comment so reviewers see it before code changes start.