Summary

Add a first-class vigilante issue create --repo {org/repo} {prompt} command that turns a free-form prompt into an implementation-ready issue by invoking a supported coding-agent CLI with the vigilante-create-issue skill, then creates the resulting issue on the issue tracker configured for that repository instead of assuming GitHub everywhere.

Problem

• Vigilante can watch repositories and dispatch implementation work, but there is no corresponding operator command for turning a rough request into a structured issue through the same agent-driven workflow.
• Operators currently have to leave Vigilante to draft issues manually, which breaks the product loop where Vigilante should own both issue intake and issue execution.
• Repositories may not all use the same issue tracker. A repo configured for Linear should not require the operator to create the issue on GitHub first, while a GitHub-backed repo should continue to create a native GitHub issue.
• Without a repo-aware issue create flow, issue authoring remains inconsistent and backend-specific logic stays spread across manual operator steps.

Context

• Repository: aliengiraffe/vigilante
• Vigilante already has a vigilante-create-issue skill whose purpose is to convert a rough request into a concrete, execution-ready issue body and create the issue on GitHub when possible.
• The current CLI exposes watch, list, status, service, daemon, resume, recreate, cleanup, and related workflows, but there is no top-level issue create operator workflow yet.
• Vigilante already models backend separation for issue tracking versus git hosting / pull requests. That matters here because issue creation should respect the configured issue tracker for the target repository.
• The new command syntax requested here is: vigilante issue create --repo {org/repo} {prompt}.

Desired Outcome

• Operators can run vigilante issue create --repo owner/repo "<prompt>" to create a new work item for that repository without manually drafting the full issue first.
• Vigilante invokes a supported coding-agent CLI in a constrained issue-authoring mode that uses the vigilante-create-issue skill to transform the prompt into an implementation-ready issue body.
• The resulting issue is created on the issue tracker configured for the target repository.
• For repositories whose issue tracker is GitHub, the command creates a GitHub issue.
• For repositories whose issue tracker is Linear, the command creates a Linear issue instead of a GitHub issue.
• The command reports the created issue identifier and URL in a backend-appropriate way.
• Out of scope: implementing a generic natural-language planning assistant outside the issue-authoring workflow, replacing existing watch/dispatch behavior, or redesigning unrelated provider setup.

Implementation Notes

• Add a new CLI surface for vigilante issue create with an explicit required --repo flag and a prompt argument or prompt remainder that preserves the operator's free-form request text.
• Resolve repository-specific configuration before agent invocation so Vigilante knows which issue tracker backend should receive the created issue.
• Reuse the existing vigilante-create-issue skill as the authoring contract rather than introducing a second issue-drafting prompt format.
• The agent invocation should be responsible for producing a structured issue body, but backend selection and final creation should remain under Vigilante's orchestration so repo-specific policy stays centralized.
• Avoid hard-coding GitHub creation semantics into the new command. The flow should dispatch through the configured issue-tracker backend abstraction.
• Define the behavior when the target repo is unknown to Vigilante or does not yet have resolvable issue-tracker configuration. The command should fail clearly instead of guessing the backend.
• If the backend-specific CLI dependency or authentication is missing for the resolved issue tracker, fail before the agent-authored issue is submitted and tell the operator what needs to be installed or authenticated.
• Preserve space for future backends, but this issue should at minimum cover GitHub and Linear-backed repositories.

Acceptance Criteria

• Vigilante exposes vigilante issue create --repo {org/repo} {prompt} as a supported CLI workflow.
• The command rejects calls that omit --repo or omit the issue prompt with a clear usage error.
• The command resolves the configured issue tracker for the target repository before attempting issue creation.
• The command invokes a supported coding-agent CLI with the vigilante-create-issue skill to turn the prompt into an implementation-ready issue draft.
• For repositories configured to use GitHub for issue tracking, the command creates a GitHub issue and returns its number and URL.
• For repositories configured to use Linear for issue tracking, the command creates a Linear issue and returns its identifier and URL.
• If the target repository has no known issue-tracker configuration, the command fails with actionable guidance instead of defaulting silently to the wrong backend.
• If the backend-specific CLI dependency or auth is missing, the command fails with a clear preflight error and does not create a partial or duplicate issue.
• The final created issue body is specific enough for Vigilante's later implementation workflow and includes concrete acceptance criteria and testing expectations.
• Existing watch, dispatch, and mixed-backend behavior remain unchanged unless they are intentionally extended to support this feature.

Testing Expectations

• Add CLI tests for vigilante issue create usage, argument parsing, repo resolution, and backend selection.
• Add tests covering the agent invocation contract so Vigilante passes the expected issue-authoring context and skill selection into the provider runtime.
• Add backend tests for GitHub-backed issue creation and Linear-backed issue creation through the same orchestration entry point.
• Cover failure paths for missing repo configuration, unsupported backends, missing provider CLI, missing issue-tracker CLI, and missing authentication.
• Verify that the command returns backend-appropriate created issue metadata and does not create duplicates on retried failures.

Operational / UX Considerations

• Document the new command in the README and command help text, including how --repo is resolved against repository-specific configuration.
• Keep the operator-facing command simple: the free-form prompt should not require users to learn the internal issue template.
• Log enough context to diagnose provider/backend failures without leaking raw prompt text or credentials into telemetry or logs.
• Be explicit about whether the target repo must already be watched or otherwise registered before issue create can infer the correct issue tracker.
• If the skill can only draft while backend creation is blocked, define whether the command should print the draft, write it somewhere local, or fail hard; the behavior should be deterministic and documented.