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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
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.