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.…
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…
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.
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.
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…
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 dynamicsteps only after explicit user confirmation…
A quality-assurance workflow for checking completed features and releases against their requirements. It covers functional, regression, and integration testing and produces a QA report.
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.
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.
Execute plan tasks via isolated subagents with reviewer checkpoints. Handles DONE/BLOCKED/NEEDSCONTEXT states. Use when: a confirmed plan should be implemented through isolated subagents with reviewer checkpoints.
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.
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.
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.