z3z1ma
UserThe missing middle between prompt and patch: a Markdown-native protocol that turns AI coding sessions into durable work products agents can continue, audit, and trust
Categories
Indexed Skills (36)
loom-api-and-interface-design
Use when a shared interface needs consumer, compatibility, error, permission, or migration design before implementation, including REST, GraphQL, CLI, event, module, component, file-format, worker, or cross-system contracts.
loom-architecture-deepening
Use when architecture work is about increasing module depth, leverage, locality, test seams, or caller simplicity in tangled or shallow code, not local readability cleanup.
loom-branch-finish
Use when code work on an isolated branch or worktree appears complete and the next decision is branch disposition: local merge, PR, keep, discard, cleanup, or follow-up routing.
loom-browser-testing-with-devtools
Use when a browser-run UI or client claim needs real runtime observation: visual state, DOM, accessibility tree, console, network, CORS, viewport, screenshot, or browser performance.
loom-ci-cd-and-automation
Use when changing pipeline or automation behavior itself: CI gates, build/deploy workflows, release automation, preview/staging/prod environments, credentials, artifacts, or pipeline-specific failure recovery.
loom-code-review-and-quality
Use when a code diff, branch, PR, worker output, or implementation-complete ticket needs a code-focused quality review across correctness, tests, architecture, security, performance, scope, and evidence before audit or closure.
loom-code-simplification
Use when working code needs behavior-preserving simplification because readability, duplication, dead code, naming, nesting, wrappers, or abstraction debt is the problem; not when behavior is still wrong.
loom-codebase-atlas
Use when an unfamiliar code area needs a reusable map of modules, callers, interfaces, data flow, constraints, and related records before safe implementation, review, debugging, or planning.
loom-debugging-and-error-recovery
Use when an unexpected or unexplained failure needs diagnosis before fixes: failing tests/builds/CI/runtime/UI behavior, bug reports, regressions, intermittent failures, reproduction, localization, guard tests, or recovery evidence.
loom-deprecation-and-migration
Use when the work is a safe removal or replacement path: deprecating APIs/features, migrating users/data/config/integrations, consolidating duplicate implementations, proving zero usage, or retiring legacy behavior.
loom-domain-language-and-decisions
Use when work is blocked by ambiguous project/domain vocabulary, conflicting terms, code-vs-operator language mismatch, cross-domain ownership questions, or an architectural tradeoff that may need durable precedent.
loom-doubt-driven-development
Use when a non-trivial in-flight claim needs a challenge posture before more work depends on it, especially claims about behavior, safety, migration, compatibility, ordering, permissions, evidence, or review conclusions.
loom-frontend-ui-engineering
Use when user-facing UI engineering needs coordinated behavior/design handling: components, pages, flows, layouts, interactions, responsive/accessibility/visual quality, frontend state, data fetching, or browser runtime evidence.
loom-git-workspace-isolation
Use when implementation needs workspace isolation or provenance because unrelated changes, worker write scopes, baseline ambiguity, branch/worktree setup, or later cleanup/finish decisions could affect safety.
loom-idea-refine
Use when an operator's rough product, engineering, workflow, research, or opportunity idea lacks clear problem, audience, scope decisions, system-shape, data-model or state implications, success criteria, design coherence, direction, or next Loom record move.
loom-incremental-implementation
Use when non-trivial ticket or plan execution needs bounded implementation slices, sequencing, multiple-file/record changes, feature flags, refactor/behavior separation, worker handoff, evidence, and continuation state; not for unshaped asks with unresolved scope, system-shape, data-model, state, or coherence choices.
loom-intake-triage
Use when incoming bugs, feature requests, or external issues need intake disposition before a ready Loom ticket exists: classification, reproduction, info request, worker/operator readiness, duplicate handling, or rejection rationale.
loom-parallel-worker-coordination
Use when multiple independent tickets or ticket-defined worker scopes can run concurrently and need coordination, non-overlapping write scopes, integration reconciliation, and combined evidence/audit.
loom-prototype-and-spike
Use when the next step is building a disposable prototype/spike to answer a specific design, state-model, UI, interface, or integration question before committing production implementation.
loom-review-response
Use when incoming human, audit, PR, worker, or external feedback is multi-item, unclear, disputed, scope-changing, or technically questionable and needs verification, pushback, implementation, or disposition.
loom-security-and-hardening
Use when the work touches security-sensitive boundaries: untrusted input, authn/authz, secrets, sensitive data, uploads, webhooks, command/database execution, external integrations, dependencies, or hardening review.
loom-shipping-and-launch
Use when release readiness or launch coordination is the work: production deploys, feature-flag enablement, staged rollout, migrations/API/infrastructure release, rollback, monitoring, changelog, or launch communication.
loom-source-driven-development
Use when correctness depends on current source authority: framework/library/platform versions, official docs, standards, changelogs, migration guides, peer repos, project source reality, or conflicting documented patterns.
loom-test-driven-development
Use when implementation should be driven by test-first verification: a focused executable check can fail before the change, pass after it, and provide evidence for a behavior, bug, logic, edge case, or acceptance claim.
loom
Use when starting any conversation - establishes how to manage knowledge, context, user interaction, and execution discipline for the project.
loom-audit
Use when claims, code changes, Loom records, evidence, risks, acceptance, or follow-through need Ralph-backed adversarial review before they can be trusted.
loom-constitution
Use before work that may depend on or change durable project judgment, including identity, policy, principles, constraints, ADRs, roadmap direction, architectural precedent, or code changes where that judgment matters.
loom-evidence
Use when observations, validation outputs, reproductions, logs, screenshots, scans, command results, or artifact pointers should remain available for review or closure claims.
loom-knowledge
Use when reusable understanding, preferences, procedures, concepts, references, troubleshooting notes, atlases, entities, or task-relevant recall should remain available beyond the current session.
loom-plans
Use when high-level work must be decomposed into multiple ticket-ready execution units, or when sequencing, dependencies, rollout, milestones, recovery strategy, or multi-ticket coordination matters.
loom-ralph
Use when Loom work needs a bounded Ralph subagent, harness run, implementation slice, review pass, or worker handoff built from tickets, records, files, evidence, claims, or other bounded context.
loom-research
Use when investigation, source synthesis, option comparison, rejected paths, null results, tradeoffs, or evidence-backed conclusions should remain available to future Loom work.
loom-retrospective
Use after significant completed or reviewed work when durable lessons, prevention notes, follow-up routing, or reusable knowledge should survive the session.
loom-specs
Use when behavior, interfaces, invariants, requirements, scenarios, or intended outcomes need a stable source before tickets, worker runs, evidence, or audit rely on them.
loom-tickets
Use whenever the user mentions tickets, scoped implementation work, continuation from prior work, acceptance changes, review state, closure, cancellation, or a bounded work item that needs live execution state.
using-loom
Always activate at session start before any response or action, unless this doctrine and references are already preloaded.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.