squad-sdk-heterogeneous-import

# Generate Expert Squads heterogeneous import method Import a Multica agent team through the official local Multica configuration and the strict OpenCorvus adapter. You own source discovery, evidence interpretation, autonomous diagnosis and repair, and the final report. The tools own source validation and package writes. This Skill is the shared readable contract for the scheduler, import analyst, and contract reviewer. Loading it never grants a mutation tool. Only the scheduler projection owns `multica_catalog`, `multica_preview`, and `multica_import`; projected workers inspect the scheduler's exact preview evidence and follow their own role prompt without attempting scheduler-only discovery, preview, or mutation. ## Procedure 1. Call `multica_catalog` before choosing a squad. It returns every source Squad with its complete `members` roster and authoritative `installed` status from the combined user-global and current-project catalog. Keep already-installed rows visible as evidence, but treat only rows with `installed: false` as import candidates. 2. If no squad exists, report the exact tool error or empty catalog. If every row is installed, report those exact IDs as already installed and do not preview or import them. Do not search the database, scrape the Multica interface, use the Multica command-line interface, or invent another source. 3. If exactly one uninstalled squad exists, review its catalog declaration. If several plausible uninstalled squads exist and the visible user request does not identify one, show every row's exact ID, name, description, installed status, member count, and complete member roster, then ask the user which uninstalled squad to import. Keep already-installed rows visible but non-selectable. For every question option, set `label` to the exact Squad name and `value` to its exact Squad ID, set `disabled: true` for installed rows and `disabled: false` for uninstalled rows, and keep the remaining description, member count, and complete roster in `description`. Never infer identity from display-name similarity. 4. Build the smallest sufficient explicit `mapping` from the returned complete `members` roster. Start with `mcp_replacements: []` and `mcp_omissions: []`. Declare one `agents` entry for every source Agent with an evidence-backed OpenCorvus `base_role`. Ordinary Multica routing Squads normally need direct Task-scoped projected Agents and an explicit `virtual_workflows: {}`; do not fabricate Requirements, Architect, Delivery Slice, or dependency stages merely to make an import look structured. Declare a virtual workflow only when the visible source instructions establish a fixed multi-stage contract, and then map every node to the exact typed adapter that can produce its promised artifact. Never infer an adapter from a node name, display label, member order, Multica leader status, or keyword table. OpenCorvus supplies `universal-build` separately as a platform scheduler-only capability. Never map a Multica member to it, add it to imported package agents, or insert it into a virtual workflow. Imported manifest versions use the source Squad update date as `YYYY.MM.DD.1`; the source digest, not that display version, remains the freshness authority. OpenCorvus also supplies Task Artifact transport independently of package declarations: the scheduler and every worker receive `artifact_search`, `artifact_read`, and `artifact_select`; the scheduler additionally receives read-only `artifact_snapshot` for exact pre-dispatch Task inputs, while workers receive `artifact_snapshot` and `artifact_publish` for evidence resources and outputs. Never add or shadow those tool IDs in the mapping or generated package, copy Artifact bodies into prompts or dispatch outcomes, or reinterpret workflow `depends_on` edges as payload transport. Agents enumerate complete Task-owned evidence, pass each Host-minted `artifact_locator_ref` to `artifact_read` until complete, and pass the returned `artifact_read_ref` to `artifact_select` only for semantic sources of their typed output. Complete but unselected reads remain observations and zero selections are valid. Generic `artifact_publish` calls declare publication-specific `source_read_refs` returned by complete `artifact_read` calls in the same physical Turn; the Host alone resolves those short references to canonical source locators. 5. Generic artifact_publish selects its own semantic sources directly through source_read_refs from complete artifact_read results; a standalone artifact_select call is only needed for a consumer that requires a selection receipt. Call `multica_preview` for the exact squad ID and exact mapping. Explain its target ID, roster, skills, every Skill's `supportingFiles`, every discovered `mcpServers` entry and its exact tools/prompts/resources, every `mcpRepairCandidates`, `mcpReplacements`, and `mcpOmissions` entry, source digest, mapping digest, blockers, and non-portable evidence. 6. If `blockers` is non-empty or a tool call fails, investigate the root cause and autonomously repair every technical problem within the current task's authority using the existing Agent and development capabilities, then rebuild the mapping when necessary and preview again. Do not stop after merely reporting a repairable technical problem, ask the user to perform technical repair, weaken validation, or hide the failure with a fallback. 7. Treat each source Skill as one immutable directory closure: `skill.content` is its exact `SKILL.md`, and every safe entry in `skill.files[]` is a supporting file at that relative path. A multi-file Skill is not a blocker by itself. Do not omit, rename, flatten into `SKILL.md`, rewrite, or separately recreate supporting files. Block only the concrete defects returned by preview, such as unsafe paths, mismatched Skill ownership, invalid frontmatter, or another canonical package validation error. 8. Treat every source MCP declaration as immutable evidence. Import public remote HTTP/SSE endpoints after a real connection and complete paginated discovery. When one peripheral server is unavailable, unsupported, or intentionally outside the target Agent contract, add one exact `mcp_omissions` entry containing its source Agent ID, exact server name, and a concrete evidence reason, then preview again. Canonically sort omissions by source Agent and server. This removes only that exact projection and records it in the package README; it is not permission to ignore an unidentified declaration, redact evidence, or copy credentials. Redacted configuration without an exact server declaration, unsafe Skill paths, source identity defects, and invalid canonical package data remain blockers. 9. A structurally safe local MCP process appears in `mcpRepairCandidates` but remains a blocker until the mapping identifies its replacement. First resolve every unrelated blocker. When the complete visible agent instructions, roles, Skills, and server evidence establish that all remaining candidates are browser-automation dependencies, directly rebuild `mapping.mcp_replacements` from every listed candidate using its exact `agentID` as `source_agent_id`, exact `sourceName` as `source_server_name`, and `target: "opencorvus-browser"`. Canonically sort entries by source agent and server. Never infer browser meaning from a command-name keyword alone and never map an unknown capability. 10. Call `multica_preview` again with the repaired mapping, explain the returned `mcpReplacements` and `mcpOmissions`, and continue only if the new preview is blocker-free. Do not reuse the pre-repair digests. 11. Continue the diagnose-repair-preview loop until the preview is blocker-free. Do not call `question` to offer repair versus cancellation and do not pause for approval of a repair that is already within this Task's authority. If a remaining blocker genuinely requires unavailable credentials, new external authority, missing product intent, or an irreversible semantic decision, report that exact unresolved blocker instead of guessing, silently omitting evidence, or manufacturing success. 12. For a blocker-free preview, call `multica_import` with the exact latest `sourceDigest`, exact `mappingDigest`, and unchanged mapping. The source digest covers the complete Skill closures, discovered MCP inventory, applied MCP replacement capability refs, and exact MCP omissions, so any Skill path/content, MCP configuration, target Browser capability, omission, or mapping change requires a new preview. 13. If import reports that the canonical package already exists because it was installed after the catalog call, do not retry or replace it. Report the exact target ID as already installed and end that import attempt. 14. If the source or mapping changes after preview, preview again and reassess the evidence. Never reuse an outdated digest. 15. Report the problems repaired, whether the result is a direct simple Squad or an explicit workflow Squad, every applied local-to-Browser MCP replacement, every exact MCP omission and reason, the installed package ID and path, the exact `mutationOperation` (`installed` or byte-identical `unchanged`), the exact source and mapping digests, the preserved supporting-file counts/paths, imported remote MCP server identities/capabilities, and the non-portable source facts. State that source Agent instructions and Skill directories are immutable import-time snapshots rather than a synchronization loop, and that the imported expert squad remains inactive and can be reviewed or activated from `Expert Squads`. Do not modify `prompt_profile.active`. Do not create a synchronization loop, remote shadow catalog, compatibility alias, partial package, or hidden message.