Treat Multica skills as operating knowledge, not prompt storage

The fastest way to misuse Multica skills is to turn every useful prompt into one.

A better review starts with the work pattern itself:

Candidate skill	Should become a Multica skill?	Reason
Release-note draft process	Yes	Repeated work with stable inputs and review
One-off customer analysis	No	Context is temporary and sensitive
Security triage runbook	Maybe	Useful, but needs owner, approvals, and logging
Personal writing preference	Usually no	Better kept local unless a team standard exists

That table is the real decision. A Multica skill is not a longer prompt. It is a piece of operating knowledge the team is willing to package, attach to agents, review, and keep current.

Multica describes skills as knowledge packs for agents: a SKILL.md file plus optional supporting files such as scripts, configs, references, and templates Multica Skills. The Agent Skills open format describes the same basic shape: a folder with SKILL.md, required metadata, instructions, and optional scripts or reference material Agent Skills overview.

The useful question is not “can we make a skill?” It is “which work deserves to become shared agent capability?”

A skill should earn its place

Good skills usually come from repeated work where the team already has a preferred way to act.

For example, a support operations team may have a specific process for turning escalation notes into an internal incident brief. A platform team may have a preferred sequence for checking a failing deployment. A content team may have a house style, source policy, and reviewer handoff contract. Those are not just prompts. They are work agreements.

Putting that agreement into a skill can make sense when five conditions are true:

1. The task recurs often enough to maintain the skill.
2. The inputs are knowable before the task starts.
3. The expected output has reviewable quality standards.
4. The skill owner can update it when the process changes.
5. The agent using it has the right permissions and boundaries.

If those conditions are not true, a skill may only make the system harder to reason about. A vague skill gives the agent a vague procedure with a professional-sounding name. That is worse than a visible one-off instruction because future operators may assume the skill has been reviewed.

What Multica changes

Multica adds a team operating layer around the file format.

The public Multica docs distinguish workspace skills, local skills, and repository-scoped skills. Workspace skills are stored in Multica and can be shared across a team once attached to agents. Local skills stay on a machine and are useful for testing or sensitive local material. Repository-scoped skills can live inside a repo and be discovered by the underlying coding tool when the task checks out that repo Multica Skills.

That distinction matters because it changes ownership:

Skill location	Best use	Main risk
Workspace skill	Team-standard process used by multiple agents	Stale capability spreading across workflows
Local skill	Private experiment or sensitive local context	Useful practice never becomes team-reviewed
Repository skill	Project-specific coding convention	Hidden collision with broader workspace habits

Multica also separates importing from attaching. A skill can exist in the workspace without affecting an agent. It has to be attached to a specific agent to take effect, and the agent picks it up on a future task start rather than rewriting a task already in progress Multica Skills. That separation is useful. It lets a team review the skill as an artifact before deciding which agents should carry it.

Treat attachment as a permission decision, even when the skill itself is only text. The skill may not grant direct system access, but it changes how an agent interprets work, which files it may read, which scripts it may run, and which workflow it may follow.

Keep MCP and skills separate

A common mistake is to treat skills and MCP servers as two names for the same idea.

They are different controls. Multica’s docs frame a skill as static content and instructions that teach an agent how to work, while MCP is a tool channel for connecting to external services and invoking capabilities Multica Skills. The two can complement each other, but they should not be governed as one blob called “agent setup.”

A skill can say:

• how to prepare a pull request review
• which files to inspect first
• what evidence to include in a handoff
• which failure modes deserve escalation
• what not to do without explicit instruction

An MCP server can expose:

• repository data
• issue tracker actions
• calendar events
• filesystem access
• API calls
• database queries

If an agent needs both, review both. The skill should describe the operating procedure. The tool channel should define the actual external powers. A good governance review asks whether the procedure is correct and whether the tools are appropriately scoped.

The hidden cost is maintenance

Skills look cheap because a first version can be just one Markdown file. The ongoing cost is not writing the file. It is keeping the skill true.

Anthropic’s original Agent Skills article emphasizes progressive disclosure: skill metadata helps an agent decide whether to load a skill, then the full SKILL.md and supporting files can be loaded only when relevant Anthropic Agent Skills. That is good for context management, but it puts pressure on the skill’s name and description. If those are too broad, the agent may reach for the skill at the wrong time. If they are too narrow, the skill may sit unused.

Maintenance should include:

• an owner who can change the skill
• a short purpose statement
• examples of tasks where it should and should not apply
• a list of supporting files and what they are for
• a review date
• a record of agents that have the skill attached
• a security note for scripts, network calls, credentials, or sensitive references

This is not bureaucracy for its own sake. It is how the team avoids accumulating invisible behavior.

Do not import trust blindly

Third-party skills are dependencies.

Multica’s docs warn that skills imported from GitHub or marketplaces may include scripts and executable content, and that Multica does not sign, audit, or sandbox those skills before handing them to the underlying AI coding tool Multica Skills. Anthropic gives similar guidance: skills can include instructions and code, so untrusted skills should be audited before use, with special attention to bundled files, dependencies, scripts, and instructions that connect to external sources Anthropic Agent Skills.

The practical review is simple:

Review question	Why it matters
What files ship with the skill?	Supporting files may carry the real behavior
Does it include executable code?	The coding tool may run scripts during the task
Does it mention secrets or tokens?	The skill may teach unsafe credential handling
Does it call external services?	Data may leave the workspace unexpectedly
Who updates the upstream skill?	Future imports may change behavior
Which agents will receive it?	A safe skill for one role may be wrong for another

For sensitive work, prefer a local or internally authored skill until the team has reviewed the content. For shared workflows, import only after the owner accepts responsibility for maintenance.

When to say no

Do not create a Multica skill when the task is still exploratory. Keep the instruction in the issue or project notes until the team has seen enough examples to know the stable procedure.

Do not create a skill for secrets, credentials, private customer details, or temporary incident facts. A skill is reusable context. It should not become a hidden data store.

Do not create a skill just to make a weak agent seem specialized. If the agent lacks the right tools, repository access, review loop, or domain owner, a skill will not fix the operating model.

Do create a skill when the team can say: this is how we want this class of work handled, this is who owns the procedure, these are the files the agent may rely on, and these are the review points before the output becomes real.

That is the point of skills in Multica. They let teams turn repeated agent work into shared, inspectable operating knowledge. The value is not that the agent remembers more. The value is that the team can decide what the agent is supposed to remember.