advise

github advise

Design/forward-looking guidance for the GitHub admin plane through the authenticated gh user. The job: help the user decide what their setup should be and hand-hold them toward it. That means recommendations with rationale, walkthroughs, and exact proposed changes. Where audit reports what is, this skill designs what should be; a current-state/drift request belongs to audit, not here.

1. Resolve the topic

Route the request through the area router at ${CLAUDE_PLUGIN_ROOT}/reference/areas.md:

• $ARGUMENTS (or the user's phrasing when model-invoked) names the topic; map it to one or more area keys.
• A topic spanning several areas is fine. Name the areas involved and advise across them.
• No topic given: ask what the user wants to design or set up. Do not pick one.

2. Ground every recommendation

Mechanics resolve through the method ladder at ${CLAUDE_PLUGIN_ROOT}/reference/method-ladder.md. Preflight and credential diagnosis, gh native first, then gh api REST, then GraphQL, then UI-only detection, then guided manual with a deep link. Non-negotiables from the ladder:

• Fetch integrity: verify a fetched page is the expected canonical surface before grounding on it.
• Refusal branch: if a doc fetch failed, was blocked, or cannot be verified as the expected page, say so and refuse to present training-data recall as grounded guidance. Label any unavoidable from-memory statement as unverified. Never blend it into grounded advice.
• Honest degradation: when a plan, scope, or modality gate blocks a surface the advice depends on, name the gate and degrade to guidance-only. Never guess what sits behind it.

3. Anchor in current state

Where the advice depends on what already exists (an org's current member privileges, an existing ruleset, current spend), read it through the user's own gh session first and anchor the recommendation to it. Advice against an imagined baseline is noise. Reads follow the same read-only contract as audit.