Summary

Update the local service dependency workflow so it explicitly checks vigilante logs when repository-native startup, fallback service launch, or readiness checks fail and the failure needs to be classified precisely.

Problem

• The local service dependency skill has good failure categories, but it does not tell the operator or agent to consult the persisted session log before concluding whether the problem was missing tooling, unsupported setup, startup failure, or readiness failure.
• That can lead to weaker blocker reports and repeated trial-and-error when the relevant command transcript already exists locally.

Context

• The skill is designed to keep service orchestration stack-specific and inside the assigned worktree while returning a structured result to the parent implementation flow.
• Service startup failures are often multi-step and can be hard to summarize accurately without the exact local execution trace.
• Vigilante already stores per-issue session logs and exposes them through vigilante logs.

Desired Outcome

• The service dependency workflow should explicitly instruct the agent to inspect vigilante logs --repo <owner/name> --issue <n> when startup or readiness checks fail or when classification is ambiguous.
• The log guidance should improve the quality of the returned failure summary and next-step recommendation.
• Non-goal: adding new orchestration behavior or forcing log checks when services are already healthy.

Implementation Notes

• Update skills/vigilante-local-service-dependencies/SKILL.md to mention vigilante logs in the failure reporting section and, if appropriate, in the execution rules or practical defaults.
• Keep the behavior conditional on failure or ambiguity so normal success paths stay lightweight.
• If parent implementation skills rely on the structured output from this skill, make sure the wording still emphasizes the same output contract.

Acceptance Criteria

• The local service dependency skill explicitly references vigilante logs --repo <owner/name> --issue <n> for startup, readiness, or classification failures.
• The guidance ties log inspection to the existing failure categories instead of introducing a parallel error taxonomy.
• The skill still returns a concise structured output contract after log-based diagnosis.

Testing Expectations

• Add or update tests if the repository validates generated skill prompts or helper text for this workflow.
• Manually verify that a failed service startup path now leads to an accurate, evidence-based blocker summary.

Operational / UX Considerations

• This should improve signal in downstream issue comments and reduce repeated ad hoc retries.
• The wording should stay compatible with both repository-native startup flows and generated fallback mechanisms.