Multica Skills vs Code Knowledge Graph

Multica Skills and a code knowledge graph are complementary layers. A Skill tells an agent how to perform a reusable procedure; a graph supplies queryable claims about how the current repository is connected. Put investigation steps, output formats, and review rules in Skills. Put modules, symbols, dependencies, tests, provenance, and revision data in the graph. Require the Skill to verify graph results against current source.

This comparison is easy to blur because both layers can reduce repeated explanation. The boundary is authority. A procedure can say, “Find direct and indirect callers and report unknowns.” It cannot make a stale caller edge true. A graph can return a caller path. It cannot decide whether the task needs a security review or which evidence format the team accepts.

As of Multica v0.4.10, the product documents Skills, workspace context, Project Resources, and task/session coordination. It does not document native code-graph ingestion, edge extraction, or graph freshness. The graph in this article is an external repository context layer.

Supported provider sessions can resume within Multica's task lifecycle, but that continuity belongs to one run and does not reconcile graph facts across agents.

Quick Verdict

Multica Skills package repeatable procedures, while a code knowledge graph supplies changing repository relationships with provenance.

Use reusable agent skills for repeatable behavior:

• task intake and precondition checks;
• tool sequence and read-only defaults;
• required evidence fields;
• review and escalation steps;
• organization-specific output formats.

Use a code knowledge graph for structural facts:

• module and symbol ownership;
• definitions, imports, calls, registrations, and event flows;
• generated-source relationships;
• schema, API, database, and queue dependencies;
• tests and architecture decisions connected to code;
• source location, indexed commit, and extraction method.

Use neither as unquestioned authority. A Skill can be malicious or stale. A graph can be incomplete or wrong. Current source, executable tests, and approved policy remain the verification anchors.

What Multica Skills Are Best For

Well-governed reusable agent skills standardize how agents gather and report evidence without freezing volatile code relationships into prose.

A Multica Skill is an Agent Skills-compatible package centered on SKILL.md, with optional supporting files. Teams can create or import Skills and explicitly attach them to agents. Workspace, local, and repository-scoped Skills have different storage and discovery behavior, but their common job is to package instructions and reference material for an underlying coding tool.

A repository-analysis Skill might require this workflow:

1. confirm repository and base revision;
2. identify likely entry points;
3. query direct callers and registrations;
4. map affected tests and contracts;
5. mark inferred or unresolved edges;
6. verify material paths in source;
7. return a fixed evidence table.

That structure improves consistency across agents. It also makes failure visible: if the graph is unavailable or the task revision differs, the Skill can stop instead of improvising.

The lifecycle is explicit. The current documentation describes create or import, attach, and update. It does not establish an automatic “successful task becomes a Skill” mechanism. An edited workspace Skill reaches newly created tasks; existing tasks keep the copy they already received.

Searches for Multica pricing often appear near product evaluation, but pricing does not change the architectural boundary. No public fixed cloud price was listed at the verification cutoff. A free-trial invitation is not proof of a permanent free tier. Evaluate Skills on governance and workflow fit, then obtain current commercial terms from the vendor.

Third-party Skills require review. Multica does not document signing, auditing, or sandboxing imported Skills. The underlying tool receives their content, so a Skill can influence commands, file access, and data handling. Treat it like executable operational configuration even when it is written in Markdown.

What Code Knowledge Graphs Are Best For

Searches for Multica pricing belong to commercial evaluation, while this layer comparison turns on evidence quality, freshness, and governance rather than price alone.

A code knowledge graph models relationships that change as the repository changes. It can answer questions that prose instructions should not try to memorize:

• Which services consume this event?
• Which symbols call this function directly or through registration?
• Which schema generates this client?
• Which tests cover this contract?
• Which architecture record constrains this dependency?
• Which edges could not be resolved at the indexed commit?

Useful results carry provenance. A CALLS edge without a source path, revision, and derivation is merely an assertion. A mature layer stores direct and inferred edges separately, records parse failures, restricts queries by repository permissions, and expires or rebuilds data when the task base moves.

The graph should be read-only to ordinary task agents. Otherwise an agent can alter the context used to validate its own patch. Index writes belong to a reviewed extraction process with audit logs and access controls.

Graph coverage also has limits. Dynamic dispatch, reflection, runtime configuration, generated code, and cross-repository contracts can produce missing or ambiguous edges. The correct graph response is “unknown with evidence,” not a confident empty set.

Why Workflow Memory Cannot Replace System Knowledge

Workflow memory describes what the team wants an agent to do. System knowledge describes what the current code demonstrates. The two drift differently.

Suppose a Skill says that all payment changes must inspect packages/billing. Six months later, payment authorization moves into a service and event consumer. The procedure may still be valid at the intent level—trace the payment path—but its hard-coded directory is stale. A graph built from the current revision can reveal the new relationships, while the Skill supplies the review process.

The reverse failure also occurs. A graph can correctly show a dependency path but omit the organization rule that security must review it. The graph supplies structure, not governance.

Keep stable rules in workspace context or Skills. Keep volatile relationship claims in the graph. Keep task decisions in the issue. Keep proof in source and tests. This separation lets the team refresh one layer without silently rewriting the others.

How the Two Layers Work Together

The integration contract should be small and testable:

1. The Skill receives the task and extracts repository, revision, entity, and change intent.
2. It calls a read-only graph query through a provider-supported adapter.
3. The graph returns bounded paths, provenance, coverage gaps, and index age.
4. The Skill requires current-source verification of high-impact edges.
5. It maps the verified path to tests, owners, and review rules.
6. It records unknowns rather than widening the search indefinitely.

Multica’s MCP configuration is provider-specific, so do not assume every attached agent can call one MCP graph server. Some tools may need a CLI or provider-native extension. The Skill can hide that adapter detail while keeping the returned evidence schema consistent.

Test the combination with fixture repositories. Include direct calls, aliases, generated code, an unresolved dynamic edge, a stale graph revision, and a denied path. Passing means the workflow reports correct evidence and honest unknowns. It does not mean every future repository relationship is solved.

Keep the returned graph packet out of the Skill package itself. Embedding a captured result beside the procedure makes the two lifecycles look like one and encourages agents to reuse old edges. The Skill may include a response schema, example with synthetic paths, and adapter documentation. The live result should identify the task, repository, indexed commit, query time, and access scope. Store it with the work item when auditability matters, then expire it when the base revision moves. This distinction also makes incident review easier: maintainers can tell whether the agent followed a bad procedure, received stale evidence, or ignored accurate evidence.

Log adapter and schema versions as well. The same Skill can produce different results after a query contract changes, even when its Markdown is unchanged.

FAQ

Can a Skill call graph queries?

Yes, if the underlying provider has an approved adapter such as MCP, a CLI, or an extension. The Skill should request a bounded read-only query, validate the revision, and require source citations. This is a team integration, not a documented native Multica graph feature.

Who owns stale Skill cleanup?

Assign an owner and review date to every shared Skill. The owner removes obsolete commands, tests provider compatibility, checks permission assumptions, and announces changes that affect newly created tasks.

What evidence proves dependency impact?

Use source locations for definitions and relationship paths, the indexed commit, relevant generated-source or configuration evidence, and tests at the affected contract. A graph edge alone is a lead; verified source plus suitable tests support the conclusion.

What is the best multi-agent system?

There is no context-free winner. Evaluate coordination, provider support, permission boundaries, self-hosting terms, auditability, and failure recovery against your workflow. This article only establishes how Multica Skills and an external graph divide responsibility.

Conclusion

Multica Skills should make work repeatable. A code knowledge graph should make structural claims queryable and auditable. Connect them through a narrow read-only interface, retain provenance, and verify results in current source. When procedure, facts, and proof remain separate, the team can improve each layer without turning instructions into architecture mythology.