loom

Read-only cross-artifact consistency analysis after planning and before approval. Verifies that spec.md, requirements.json, plan.md, tasks/Tn.md, traceability.json are mutually consistent: no duplicate/ambiguous requirements, every behavior mapped to a task, no orphan tasks, no coverage gaps, no contradictions. Outputs artifact-analysis.json with coverage% and severity. CRITICAL/HIGH findings block the approval gate. Use when: planning produced plan.md + tasks + traceability.json, before the user approves the plan.

Explore 2-3 implementation options with trade-offs when the user describes a new feature or requirement. Use when: the user asks for a new feature design, implementation options, or technical trade-off analysis.

After implementation and before final verification, compare current code/tests against the intent inventory (requirements.json + traceability.json). Classify each requirement/behavior as covered, missing, partial, contradicts, or unrequested. Append missing/partial/contradicts as new tasks back to executing. Repeat until converged: zero blocker findings. Outputs convergence-report.json. Use when: executing produced test-report.md but before loom-verification-before-completion.

Expand each requirement into verifiable Behavior Obligations across 15 fixed dimensions (happy-path, boundary, invalid-input, authorization, state-transition, idempotency, concurrency, atomicity, external-failure, compatibility, security, performance, observability, recovery, forbidden-behavior) before planning. Use when: brainstorming produced requirements.json and spec is approved, but behaviors are still placeholders or only happy-path; before loom-writing-plans.

Read-only adversarial reviewer that looks for what SHOULD exist but doesn't, by cross-checking Behavior Obligations against code, tests, expected side effects, forbidden side effects, failure scenarios, and public API changes. Focuses on negative space: events that should not repeat, permissions that should not be bypassed, partial writes that should not happen, old APIs that should not change, swallowed exceptions, leaked secrets. Outputs findings.json. Use when: executing or converge needs an independent omission sweep.

Analyze user request + collect signals (file scope, keywords, worktree state, spec existence), then select pipeline steps via rule short-circuit / AI fallback / rule-based fallback. Select steps first, expose the choice to the user, and persist selected dynamic_steps only after explicit user confirmation; pipeline-plan.md is optional for manual review. Use when: user is unsure which pipeline type to pick, or wants AI to choose steps automatically.

Execute plan tasks via isolated subagents with reviewer checkpoints. Handles DONE/BLOCKED/NEEDS_CONTEXT states. Use when: a confirmed plan should be implemented through isolated subagents with reviewer checkpoints.

Overview of the loom engineering framework: pipeline stages, skills catalog, and review dimensions. Load when the user asks about loom capabilities or how to use it. Use when: the user asks how loom works, what skills exist, or how to run the engineering pipeline.

Final integrity check before declaring work complete: compile, test, placeholder scan, spec coverage. Use when: code changes appear complete and need final compile, test, and integrity verification.

Break a confirmed spec into ordered, independently-verifiable task files with dependency analysis. Use when: an approved spec must be decomposed into ordered, testable implementation tasks.

Clean up a feature branch after verification: merge, create PR, keep, or discard. Follows conventional commits. Use when: a development branch has passed verification and needs merge, PR, keep, or discard handling.

Synchronize graph backend index, structured memory, and entry docs with code after verification passes. Use when: verified code changes need graph index sync, memory updates, or entry documentation refresh.

Bootstrap .loom/ context files for a new repository: constitution, structured memory, workflow, and agent entry files. Use when: initializing loom context for a repository that lacks .loom/ files or standard agent entry docs.

Prepare a code review request with change summary, self-test results, and focus areas for reviewers. Use when: verified changes are ready for reviewer handoff or a PR needs a review request summary.

Route a user request to the appropriate loom capability without replacing pipeline selection. Use when: a user request needs intent classification before choosing a skill, pipeline selector, QA, review, debugging, or branch finishing path.

Dispatch multiple independent tasks to parallel subagents when no shared file conflicts exist. Use when: a confirmed plan has independent tasks that can run concurrently without touching shared files.

QA 验收流水线编排器：从需求变更分析到功能测试、回归测试、集成测试， 维护持久化测试用例库，输出 qa-report.md。 Use when: 测试人员对新功能或 release 进行验收测试，需要完整的功能测试覆盖。

Process code review feedback: classify items, implement fixes, push back with reasoning when needed. Triggered after receiving review comments on a PR or branch. Use when: code review comments have arrived and need triage, fixes, or reasoned disagreement.

Structured debugging when facing bugs, test failures, or unexpected runtime behavior. Follows a phased approach: reproduce → gather info → hypothesize → verify → fix. Use when: diagnosing bugs, failing tests, flaky behavior, or unexplained runtime errors.

Implement features using strict Red-Green-Refactor TDD cycle. No production code without a failing test first. Use when: implementing behavior where tests can define expected outcomes before production code changes.

Create an isolated git branch/worktree before coding begins. Verifies baseline tests pass. Use when: starting implementation work that should be isolated from the current branch or workspace.

Author or modify a loom skill file. Provides SKILL.md structure, frontmatter format, and quality checklist. Use when: creating or updating loom skills, their frontmatter, triggers, or quality checklist.