Menu
Open the right `type:new-assistant` / `type:vendor-evolution` GitHub issue from a free-form intent. Use when the user says they want to support / fix / evolve a vendor and has not yet filed an issue.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Verify gates one last time and merge an assistant PR (new-assistant or vendor-evolution). Use when the issue is at phase:merge-ready.
Scaffold (new-assistant) or refactor (vendor-evolution), document, test, and open a draft PR. Use when the issue is at phase:approved or phase:implementing and the contributor is starting or resuming work.
Review an open assistant PR against the dual-track checklist (dated documentation first, then code), with per-issue-type addenda for new vendors vs evolution. Use when the issue is at phase:review.
Routes to the correct sub-skill of the assistant family based on the issue's type:* and phase:* labels. Use when the user mentions a vendor onboarding or evolution and is unsure which skill to run.
Tally tester sign-off comments on a phase:testing issue, audit any attached connector logs for sanitization gaps, and draft follow-ups for incomplete confirmations. Use whenever a tester comments.
Help the maintainer triage a phase:proposed assistant issue (new-assistant or vendor-evolution) — duplicate check, scope sanity, kind:* label application, decision draft. Use when reviewing an incoming proposal.
| name | assistant-propose |
| description | Open the right `type:new-assistant` / `type:vendor-evolution` GitHub issue from a free-form intent. Use when the user says they want to support / fix / evolve a vendor and has not yet filed an issue. |
| model | sonnet |
Read docs/ASSISTANT-ONBOARDING.md; it owns the lifecycle, the issue
forms, and the label conventions. Read
.claude/rules/skill-handoff.md for the HITL execution pattern.
A free-form intent ("I'd like to add support for X", "the Y connector broke this week", etc.). No issue number — there is no issue yet.
Run the bootstrap check from assistant Phase 0. If labels are
missing, propose to run scripts/bootstrap-onboarding-labels.sh
before proceeding — without the labels, gh issue create --label …
will fail.
Decide between two issue forms based on the user's wording and on
docs/vendors/<slug>.md existence:
docs/vendors/<slug>.md →
new-assistant-request.yml.docs/vendors/<slug>.md exists → vendor-evolution-request.yml.If the slug is ambiguous, ask the user once. Do not invent a slug from
a marketing name without checking docs/vendors/.
For type:vendor-evolution, read docs/vendors/<slug>.md and the
related connector code to pre-populate the form's Drift summary,
Evidence, and Affected since fields when the user's intent
already contains that data. Do not invent evidence — leave a field
blank if the user has not provided it.
For type:new-assistant, mine the user's message for the slug,
display name, tint hex, credential sources, plan variants, API
references. Ask once for missing fields.
For kind:urgent-fix, surface the Affected since field explicitly —
its absence is the most common triage rejection reason.
Show the maintainer the complete pre-filled issue body (rendered as Markdown), the title, and the labels that will be applied. Ask for a single Y/n confirmation.
gh issue create \
--title "<rendered title>" \
--body "<rendered body>" \
--label "<type:...>" \
--label "phase:proposed"
(The issue forms apply phase:proposed automatically when filed from
the GitHub UI; this skill replicates the same labels because
gh issue create does not invoke the issue-form pipeline.)
Print the new issue URL. Name assistant-triage as the next skill
once the maintainer is ready to triage.