Turning a Good Prompt into a Team‑Wide Skill Asset

Problem the article solves

One developer created a powerful Claude Code prompt that enforces a workflow (run tests before refactoring, lint after changes, format commit messages). The prompt works for the whole team, but it lives only in that developer's mind and local configuration, so it is lost when the person or agent changes.

Multica's answer: the Skills system

Multica treats agents as teammates; their knowledge must be persisted with the organization, not tied to an individual. The core concept is that each skill is a SKILL.md file optionally accompanied by scripts, configs, or templates that describe "how to think and act on this type of task".

Multica adopts Anthropic’s Agent Skills open standard, allowing any compliant skill (from Anthropic’s repo, ClawHub, or skills.sh) to be imported directly, avoiding a proprietary format.

Skill sources and storage

Skills can come from the workspace (cloud‑hosted) or from the local machine. Workspace skills are stored in Multica’s cloud and automatically synced to the agent’s machine at execution time; local skills reside in a developer’s directory for testing or handling sensitive data.

Claude Code – .claude/skills/ Codex – $CODEX_HOME/skills/ Cursor – .cursor/skills/ Copilot – .github/skills/ Kimi / Kiro / OpenCode – .kimi/skills/, .kiro/skills/, .opencode/skills/ Gemini / Hermes / OpenClaw – .agent_context/skills/ (fallback)

Because each tool reads skills from its own directory, Multica must place files according to each tool’s convention.

Even if you attach a skill to a Gemini agent, Multica will sync it to .agent_context/skills/ , but Gemini itself may not read that directory.

Why syncing to the local machine matters

Agents run on the developer’s machine, not on a remote server, so a skill must be reachable by the local AI tool. During task execution, Multica copies all workspace skills to the local path expected by the tool, ensuring the skill is actually used.

// server/internal/daemon/local_skills.go
// Task execution: workspace skill → sync to tool‑specific directory
// localSkillRootForProvider tracks user‑level skill locations
// exposed by each provider's CLI

Slash‑link design for explicit skill references

In server/internal/daemon/slash_skill.go, Multica parses markdown links of the form [name](slash://skill/<skill‑id>). When such a link appears in a prompt, the daemon injects the corresponding skill content at execution time, turning the skill into a directly referenceable knowledge unit.

Example: [Refactor Guide](slash://skill/multica-refactor) – the link is resolved and the skill’s content is injected, allowing issue descriptions, comments, or autopilot prompts to explicitly request a skill.

The full flow is: front‑end skill UI → Go persistence → daemon syncs workspace skill to local → slash‑link parser injects into prompt → AI tool reads it.

Self‑bootstrapping: Multica teaches its own agents

Multica ships eight built‑in skills (e.g., multica‑autopilots, multica‑creating‑agents, multica‑mentioning, etc.) that teach agents how to use Multica itself—how to @people, create issues, configure autopilots, and more. An active agent can query these skills for platform‑specific guidance.

This self‑bootstrapping design means the platform uses its core skill system to educate agents, which is more reliable than static documentation because the skills are synced, referenceable, and read by tools.

Complete answer to "experience sedimentation"

Multica’s solution: a skill is the carrier of knowledge; workspace and local sources cover team‑wide sharing and sensitive local scenarios; tool‑specific injection paths handle differences; slash links make knowledge explicitly callable; built‑in skills let the platform teach agents how to use the platform. In a two‑person team, once a skill is created, the tenth new agent instantly inherits it.

Next step

The upcoming article will discuss how Multica’s Squad feature enables team‑level @mentions instead of individual assignments.