Best way to contribute an agent-skill pack for the multica CLI?

[Tigatron]

TL;DR: #770 / #1468 discussed the idea of bundled / first-party skills, but nothing has shipped yet. I've put together a draft at Tigatron/multica-skills that I'd like to contribute upstream as an official resource. This post is about finding the right contribution shape — naming is a secondary question. The draft repo exists purely so you have something concrete to review; I'm not promoting it.

Background

The four skills referenced in skills-lock.json (anthropics / shadcn / nextlevelbuilder / vercel-labs) are all focused on frontend and UI design. There is no skill yet that lets other agents operate the Multica platform itself.

If Claude Code, Codex, Cursor, OpenCode, Gemini CLI, and the rest could drive the multica CLI through a skill — assigning work to agents, scheduling autopilots, inspecting runs, operating the daemon — Multica becomes a collaboration backend that any agent can plug into. That matches the direction sketched in #770 and #1468.

I'd like to ship this as a first-party resource.

What the draft contains

Pushed to Tigatron/multica-skills (MIT, draft only) so there's something concrete to review. Split into 6 modular skills along capability boundaries, with each description written as a "when to use me" predicate so agent frameworks route correctly:

Skill	Scope
multica-setup	Install, login, daemon bootstrap, profiles
multica-issues	Issue CRUD, comments, subscribers, runs / run-messages
multica-agents	Agent discovery + delegation flows
multica-projects	Sprints, epics, workstreams
multica-autopilot	Scheduled automations, cron triggers, run history
multica-daemon	Local runtime lifecycle, workspace watch, profiles

Beyond the command reference, each SKILL.md also includes:

• Common flows — cross-command patterns (batch-migrating issues at sprint close, polling run-messages, etc.)

• Gotchas — IANA timezone names, case-sensitive assignees, daemon running empty without an agent CLI installed, and similar traps

The layout matches vercel-labs/skills (the same tooling Multica already consumes), so it works with npx skills add out of the box across all 40+ supported agents. I haven't advertised the draft anywhere pending alignment with you on the contribution path.

Existing community work

Scanned what's already out there to avoid duplicating effort:

• panfu/multica-skill — single-file SKILL.md via CLI, installed by pasting a prompt into the agent

• ZhangBohan/multica-ops-skill — REST API + Python scripts, ops-focused

This draft's angle (modular + CLI + native npx skills) doesn't overlap with either. If the team adopts this, I'd hope the different community efforts eventually converge on one official entry point rather than fragmenting the ecosystem.

Primary question: preferred contribution shape

Which shape works best for you?

A. PR into the main multica repo Add a skills/ (or similar) directory inside multica-ai/multica, SKILL.md files shipped alongside the code. Upside: stays in lockstep with CLI versions, no chance of drift.

B. A sibling repo under multica-ai Something like multica-ai/skills or multica-ai/agent-skills, where I contribute the draft content via PR or transfer. Upside: users install with npx skills add multica-ai/skills, consistent with the external-skill pattern already in skills-lock.json.

C. Something else — for example as examples, docs, or a larger feature surface.

All three work for me. If useful, I can also transfer Tigatron/multica-skills directly to the multica-ai org (GitHub issues a 301 redirect, zero migration cost for any existing consumers) — but that's an execution detail once you've decided to adopt, not a precondition.

If option A looks right to you, I can open a PR against multica-ai/multica within a day — the draft is already structured that way. I'd rather wait for a signal from the team before opening anything, so I'm not presuming the answer.

Secondary question: naming convention

Skills currently use a multica-* prefix (multica-setup, multica-issues, and so on). If the contribution lands under A or B, is that prefix right? Or would you prefer:

• No prefix (setup / issues / ..., since the repo is already under the multica-ai namespace)

• A different prefix

• Keep multica-* as is

Misc

• License: MIT (same as the main repo)

• Sources: CLI_AND_DAEMON.md plus gotchas surfaced during hands-on use

• If the direction doesn't fit, or now's not the right time, that's completely fine

Feedback welcome.

> **TL;DR:** #770 / #1468 discussed the idea of bundled / first-party skills, but nothing has shipped yet. I've put together a draft at [[Tigatron/multica-skills](https://github.com/Tigatron/multica-skills)](https://github.com/Tigatron/multica-skills) that I'd like to contribute upstream as an official resource. This post is about finding the right contribution shape — naming is a secondary question. The draft repo exists purely so you have something concrete to review; I'm not promoting it.

Background

The four skills referenced in skills-lock.json (anthropics / shadcn / nextlevelbuilder / vercel-labs) are all focused on frontend and UI design. There is no skill yet that lets other agents operate the Multica platform itself.

If Claude Code, Codex, Cursor, OpenCode, Gemini CLI, and the rest could drive the multica CLI through a skill — assigning work to agents, scheduling autopilots, inspecting runs, operating the daemon — Multica becomes a collaboration backend that any agent can plug into. That matches the direction sketched in #770 and #1468.

I'd like to ship this as a first-party resource.

What the draft contains

Pushed to [Tigatron/multica-skills](https://github.com/Tigatron/multica-skills) (MIT, draft only) so there's something concrete to review. Split into 6 modular skills along capability boundaries, with each description written as a "when to use me" predicate so agent frameworks route correctly:

Skill	Scope
multica-setup	Install, login, daemon bootstrap, profiles
multica-issues	Issue CRUD, comments, subscribers, runs / run-messages
multica-agents	Agent discovery + delegation flows
multica-projects	Sprints, epics, workstreams
multica-autopilot	Scheduled automations, cron triggers, run history
multica-daemon	Local runtime lifecycle, workspace watch, profiles

Beyond the command reference, each SKILL.md also includes:

• Common flows — cross-command patterns (batch-migrating issues at sprint close, polling run-messages, etc.)
• Gotchas — IANA timezone names, case-sensitive assignees, daemon running empty without an agent CLI installed, and similar traps

The layout matches vercel-labs/skills (the same tooling Multica already consumes), so it works with npx skills add out of the box across all 40+ supported agents. I haven't advertised the draft anywhere pending alignment with you on the contribution path.

Existing community work

Scanned what's already out there to avoid duplicating effort:

• [panfu/multica-skill](https://github.com/panfu/multica-skill) — single-file SKILL.md via CLI, installed by pasting a prompt into the agent
• [ZhangBohan/multica-ops-skill](https://github.com/ZhangBohan/multica-ops-skill) — REST API + Python scripts, ops-focused

This draft's angle (modular + CLI + native npx skills) doesn't overlap with either. If the team adopts this, I'd hope the different community efforts eventually converge on one official entry point rather than fragmenting the ecosystem.

Primary question: preferred contribution shape

Which shape works best for you?

A. PR into the main multica repo
Add a skills/ (or similar) directory inside multica-ai/multica, SKILL.md files shipped alongside the code. Upside: stays in lockstep with CLI versions, no chance of drift.

B. A sibling repo under multica-ai
Something like multica-ai/skills or multica-ai/agent-skills, where I contribute the draft content via PR or transfer. Upside: users install with npx skills add multica-ai/skills, consistent with the external-skill pattern already in skills-lock.json.

C. Something else — for example as examples, docs, or a larger feature surface.

All three work for me. If useful, I can also transfer Tigatron/multica-skills directly to the multica-ai org (GitHub issues a 301 redirect, zero migration cost for any existing consumers) — but that's an execution detail once you've decided to adopt, not a precondition.

If option A looks right to you, I can open a PR against multica-ai/multica within a day — the draft is already structured that way. I'd rather wait for a signal from the team before opening anything, so I'm not presuming the answer.

Secondary question: naming convention

Skills currently use a multica-* prefix (multica-setup, multica-issues, and so on). If the contribution lands under A or B, is that prefix right? Or would you prefer:

• No prefix (setup / issues / ..., since the repo is already under the multica-ai namespace)
• A different prefix
• Keep multica-* as is

Misc

• License: MIT (same as the main repo)
• Sources: CLI_AND_DAEMON.md plus gotchas surfaced during hands-on use
• If the direction doesn't fit, or now's not the right time, that's completely fine

Feedback welcome:)