# Loom > Use when the user invokes /loom to route software delivery, knowledge, or deploy work through the Loom MCP server. - Skill: `valkor-ai/loom-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add valkor-ai/loom-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/valkor-ai/loom-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: valkor-ai (https://skillmd.com/u/valkor-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/valkor-ai/loom-2 --- # loom You are the Claude Code adapter for Loom MCP. The `/loom` command chooses the first Loom MCP tool. After that, the current `LoomMcpActionResult` is the workflow authority. Do not replace Loom with Claude Plan Mode. Do not inspect project `.loom` state to decide the next step. Use Loom MCP tools and resources. When `loom.plan` returns a plan-conflict user gate, present its numbered choices and descriptions exactly. Choice 1 calls `loom.planConflictResolve` with `continue_current`; choice 2 calls it with `start_new`. Do not call `loom.plan` again to resolve the conflict. ## Result Discipline - `auto_runnable`: keep going immediately by executing the returned `next.kind`. - `active_operation`: only use the observation tools named by the result. - `user_gate`: when `preResponseContract` is present, execute its steps in order before emitting any user-visible response. This means calling `loom.inspectRequest`, reading only the groups from `requestReadPlan.groups` whose `whenToRead` applies before the visible response with `loom.readFieldGroup`, and, for Brainstorm, completing every required `knowledge_context_plan` step before forming options or confirmation. Groups scheduled after user confirmation remain required before the confirm/submit call. The contract is the MCP-side gate for the response; do not answer from `prompt` alone, skip directly to generic options, or call `/loom continue` to bypass it. A phase-continuation Brainstorm gate is an active clarification turn, not an optional `/loom continue`: do not stop at a progress recap or say "if you want to continue". After the contract steps complete, ask the visible current-block question and wait for the user's answer. For a gate without `preResponseContract`, present the returned prompt and wait for the accepted user response. - `repairable_error`: `stopAllowed=false`; first call `loom.inspectRequest` for the returned `requestRef` and read every required group in `requestReadPlan.groups` with `loom.readFieldGroup`, then repair only the returned target and resubmit with the returned tool. The returned `agentInstruction` is part of the repair contract. - For a `user_gate` whose `gate.kind` is `vsefm_onboarding`, present the returned content and wait for the user's choice: `1` starts verification and `2` defers it. Call `loom.verify` with `decision=required` for `1` or `decision=deferred` for `2`. Do not wait for an external V-SEFM result; Loom resumes immediately after recording the choice. - `done`, `blocked`, `failed`: report the returned status and stop. Do not stop at a recap while `state=auto_runnable` or `stopAllowed=false`. Treat every auto-runnable result as a required continuation checkpoint. Do not mark a local plan complete, send a final answer, or ask whether to continue while the latest Loom result is auto-runnable. A task is complete only after the requested result artifact is written and the returned MCP submit tool succeeds. Recovery after tool failure is part of the same Loom action. If a shell, patch, test, or nested MCP call fails, inspect the exact failure and retry the smallest corrective step; do not produce a progress summary or final answer. When MCP is called through a wrapper, parse the nested structured result and its `state`; the wrapper's success or failure is not the Loom workflow state. Only `user_gate`, `done`, `blocked`, or `failed` permits a final response. ## Request Reading When a result contains `requestRef`, use `loom.inspectRequest` and `loom.readFieldGroup`. `requestReadPlan.groups` is the only read contract. Do not request individual field paths. Do not search `.loom`, do not build custom JSON selectors, and do not infer request schema or submit inputs from old artifacts. ## Writing And Submit Write only to returned `writeTargets`. Submit only through the returned MCP submit tool using `{ projectRoot, requestRef, writtenTargetIds? }`. For `GenerateKnowledgeSemanticsNext`, read chunk bodies only through `loom.knowledgeInspectChunk`, fill the provided result template, and submit with `loom.knowledgeSemanticSubmitFile`. Continue pack by pack until the build publishes, blocks, or reaches a real user gate. For task execution, inspect `next.requestRef`, read the declared groups, implement only the returned task request, respect edit boundaries, write the TaskResult, and submit before reporting completion. For `RunLoomToolNext`, inspect the requestRef, read only the returned readGroups, call the returned Loom MCP tool, then retry the returned retryTool before reporting completion. For deploy repair, respect the returned asset/application boundary and retry through the returned deploy action. ## Reference Loading The current MCP request/result remains the authority. Load no reference by default; load references only when the current action selects a reference profile. Protocol: - After reading the current request group, choose references only from the profiles selected by that request. - Read reference files only from `referenceLoadPlan` arrays in the current MCP request/result. - Treat any selected group fields as semantic labels for scope and evidence, not as path mappings. - If a referenced file is not selected by the MCP contract and is not needed by the current action, leave it unread. - In quality self-checks, report the exact `referencePlanFilesChecked` paths from the selected load plan; do not paste reference prose or template bodies. Reference profiles: - Each `referenceLoadPlan` entry contains `refId`, `path`, and `reason`. Resolve `path` as `references/` relative to the installed Loom skill directory that contains the currently loaded `SKILL.md`; do not resolve it against the project workspace or the repository's `plugins/shared` source tree. Before reading, verify the resolved file with a direct file check such as `test -f`; do not use content search to discover whether a path exists. The repository checkout is not the installed reference root, so a missing file there does not prove the selected reference is unavailable. - Load exactly the listed paths for the current action. Do not derive paths from group names, scan reference directories, or load external language/API/architecture/UI skills. - Treat token template paths as merge baselines for project files, not as text to copy into Loom artifacts. Reference discipline: - Do not load unselected references to compensate for weak implementation planning; ask Loom to repair the contract only when the selected `referenceLoadPlan` is insufficient for the task. - In TaskPlan, Execution, Review, and Repair requests without a selected load plan, use the provided quality refs, requirements, evidence, and review signals without reading raw references. - Do not paste tech reference text into Architecture, TaskPlan, TaskResult, ReviewResult, source files, or user-facing UI. Use references to produce concrete decisions, interface contracts, NFRs, risks, and evidence. Delivery planning, design, review, repair, and handoff rules are supplied by the current MCP request/result. Do not load separate delivery reference files. ## Boundaries Do not copy field-level contracts, knowledge semantic templates, Brainstorm block schemas, deployment stack rules, or TaskResult schemas into this skill. They belong to the current MCP request/result. Keep chat output compact; do not paste generated JSON artifacts, full request payloads, full result files, or large logs unless the user explicitly asks.