loom

name	loom
description	Use when the user invokes /loom to route software delivery, knowledge, or deploy work through the Loom MCP server.

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.

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 requestRef is present, first inspect the request and read required requestReadPlan.groups; for Brainstorm gates, run required knowledge_context_plan steps before asking the visible question or presenting confirmation.
• repairable_error: repair only the returned target and resubmit with the returned tool.
• done, blocked, failed: report the returned status and stop.

Do not stop at a recap while state=auto_runnable or stopAllowed=false. 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.

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 selected groups plus the exact referenceFilesChecked paths from the load plan; do not paste reference prose or template bodies.

Reference profiles:

• Each referenceLoadPlan entry contains refId, path, and reason. In this Claude Code skill, resolve path as references/<path> relative to this SKILL.md directory, not relative to the project workspace.
• 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.