vigilante-issue-implementation-on-gradle-multi-project

Vigilante Gradle Multi-Project 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, respect repository instructions, and keep the GitHub issue updated with start, plan, progress, PR, and failure comments.

Gradle Multi-Project Focus

• Read the repo/process context supplied in the prompt before changing code.
• Use settings.gradle or settings.gradle.kts, included project names, and repo docs to identify the relevant Gradle subproject scope before editing.
• Prefer repo-defined Gradle tasks and existing module names over guessed task or path conventions.
• Keep implementation and validation scoped to the affected subproject(s) when possible, then expand only if shared code or integration boundaries require it.
• Avoid JS workspace assumptions that do not apply to Gradle repositories.

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 Gradle subproject scope and validation approach before substantial coding work begins.

1. Detect a stacked base branch

• 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 or sub-issue links.
• If no directive is present, branch from and target the watch target's base branch as today.
• When the directive is present:
  • Run git fetch origin <base> inside the assigned worktree before code changes.
  • If the fetch fails because the branch does not exist on the remote, stop work, post a failure comment on the issue, and do not silently fall back to the default branch.
  • Re-root the work branch onto origin/<base> with git reset --hard origin/<base> (no commits yet) or git rebase origin/<base> (commits present).
  • Use <base> as the PR target later and mention it in the implementation-plan comment.