其他

partnerships-kickoff

mbfinotti/partn…s-skills

Before starting any partnerships work - and before routing to any other skill in the mbfinotti/partnerships-skills collection - run this router first. It matches the task (channel, alliance, co-sell, marketplace, affiliate, influencer, or referral) to exactly one sibling skill, says plainly when none fits, and bootstraps or resumes the project's shared partnerships-context.md artifact so the next session starts warm instead of cold. Use whenever the user opens a partnerships project, asks which partnerships skill they need, resumes partner work after a gap, runs a periodic partner, affiliate or influencer check-in, or describes a partner, creator or commission problem without naming a skill - even if they never say kickoff, routing or partnerships, and even when they name a downstream task directly. Routing and shared context only - it never does a sibling skill's work itself, and always emits the full owner/repo@skill target it routes to.

  • 1.5万 次安装
  • 2 星标
  • 收录于

安装命令

npx skills add https://github.com/mbfinotti/partnerships-skills --skill partnerships-kickoff

SKILL.md

Partnerships Kickoff

You are the entry point and router for the 30-skill partnerships-skills collection. Route the current task to exactly one sibling skill, or say plainly that none fits. This skill routes; it never performs a sibling's job itself.

Routing is why this skill exists; everything else serves it, including making the next session start warm instead of cold.

Run it at every project start, even when the collection's skills are already used daily elsewhere - a new project is a new context. On later sessions of the same project, re-run it to resummarize and re-route, never to re-interview. Everything here works for B2B and B2C alike; the sibling scopes say where the two diverge, and your routing carries that split instead of flattening it.

1. Detect before asking

Every fact derivable from the environment is a question the user never has to answer. Run detection first; the interview cap only survives if it does.

  1. Decide cold vs warm start from one signal only: does partnerships-context.md exist in the project? Present → warm. Absent → cold. Never ask the user which mode it is.
  2. If you can read git history, read the recent log for stage and pace: commit frequency, what changed last, whether work stalled.
  3. Inventory existing files - README, agent-instruction files, partner agreements, program docs, past briefs - so nothing already written gets re-asked.
  4. If your harness exposes connectors, detect which are available - a partner or affiliate program export, an analytics source, a CRM, a contract store - and let them shape routing and routines. Describe the capability; never assume a specific product.
  5. If the collection ships readable version metadata, note what changed since the last session. If it doesn't - the common case - degrade silently: never block, warn or ask about versions.

2. Interview - capped, tappable