Summary

Add a Vigilante workflow that can deterministically fork a target repository, run the normal issue implementation flow against that fork, push changes to the forked remote, and open a pull request back to the original repository with a clear implementation summary and benefits.

Problem

• Vigilante's current issue implementation model assumes it can push the issue branch to the watched repository and then open a pull request there.
• That does not cover repositories where the execution identity should work through a personal or bot fork instead of pushing directly to the upstream repository.
• Without a first-class fork flow, operators have to stitch together forking, remote setup, push behavior, and cross-repo PR creation manually, which weakens determinism and makes unattended execution less reliable.

Context

• Vigilante already owns deterministic orchestration concerns such as repository discovery, issue intake, worktree creation, branch naming, coding-agent launch, GitHub comments, and pull request creation.
• The coding step itself should remain provider-neutral and continue to use the existing repository-aware issue implementation skills once the workspace and remotes are prepared.
• The requested flow is a mix of deterministic GitHub and git setup using gh or the GitHub API plus the usual agent-driven implementation path.
• The resulting PR should target the original repository, not the fork, and should include a concise explanation of what changed and why it is beneficial.

Desired Outcome

• Vigilante can run an issue in a fork-based mode where it creates or reuses a fork of the target repository under the authenticated GitHub account or configured owner.
• The execution worktree is prepared against the original repository context, but pushes go to the fork remote and the final pull request targets the upstream default branch.
• The launched coding agent still receives the same repository-specific implementation skill and is responsible for the coding work, validation, commit, and PR content within the prepared fork-aware environment.
• The final PR body includes a clear summary of the implementation and the benefits of the change.
• Non-goals: changing repository classification, changing how skills are selected, or replacing the coding agent with a fully deterministic code-generation path.

Implementation Notes

• Add a first-class CLI entry point or execution mode for fork-based implementation rather than relying on ad hoc shell steps.
• Use vigilante gh / GitHub API calls to create or discover the fork, then configure remotes deterministically so upstream remains the source of truth for issue context and the fork is the push target.
• Define how branch naming, worktree creation, and remote naming behave in fork mode, including safe reuse when a fork and branch already exist.
• Ensure the generated execution prompt makes the fork context explicit where it affects push or PR behavior, while leaving repository-specific implementation to the existing skills.
• Create the final PR against the original repository with the fork branch as the head and require a concise summary plus benefits section in the PR body.
• Consider how this interacts with GitHub issue comments, session state, cleanup, redispatch, and resume flows so fork mode remains observable and recoverable.

Acceptance Criteria

• Vigilante can create or reuse a fork of the target repository through a deterministic gh or GitHub API flow before implementation starts.
• The issue execution environment is prepared so the coding agent works normally in an isolated worktree, but pushes go to the fork rather than directly to the upstream repository.
• The final pull request is opened against the original repository from the fork branch, not as a PR within the fork.
• The PR body includes a concise implementation summary and explicit benefits of the change.
• Session state and issue comments remain accurate for fork-based runs, including success and failure reporting.
• Resume, cleanup, and redispatch behavior have defined expectations for fork-based sessions, even if some follow-up implementation is deferred behind additional issues.

Testing Expectations

• Add unit and integration-style coverage for fork discovery/creation, remote configuration, branch push behavior, and cross-repo PR creation.
• Add or update tests for prompt assembly or session state when fork-specific context must be passed into the coding-agent workflow.
• Cover failure modes such as fork creation denied, fork already exists, missing push permissions, upstream/fork remote mismatch, and PR creation failure after a successful push.
• Manually verify the end-to-end flow against a repository where the authenticated user can fork and open a PR back to upstream.

Operational / UX Considerations

• The fork behavior should be explicit and observable in logs, session state, and issue comments so operators can see which remote received the branch and which repository received the PR.
• Preserve the existing provider-neutral architecture: deterministic orchestration should handle forking and remote setup, while the coding agent continues to own repository-specific implementation work.
• Keep config and CLI surface area narrow; prefer a small number of explicit fork-mode controls over broad new branching logic.