Software Development Skills

Use when a shared interface needs consumer, compatibility, error, permission, or migration design before implementation, including REST, GraphQL, CLI, event, module, component, file-format, packet, worker, or cross-system contracts.

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.

Manages Loom audits: prepares, records, finds, summarizes, and consumes fresh-context adversarial review of claims, code changes, Loom records, evidence, risks, acceptance, and follow-through. Use when claims, code changes, Loom records, evidence, risks, acceptance, or follow-through need fresh-context adversarial review before they can be trusted.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Use when an operator's rough product, engineering, workflow, research, or opportunity idea lacks clear problem, audience, constraints, success criteria, direction, or next Core record move.

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.

Manages Loom knowledge: creates, updates, finds, loads, prunes, and summarizes reusable preferences, procedures, concepts, references, troubleshooting notes, atlases, entities, and other current knowledge records. Use when reusable understanding or task-relevant recall should remain available beyond the current session.

Use when multiple independent tasks or packets can run concurrently and need coordination, non-overlapping write scopes, worker packet boundaries, integration reconciliation, and combined evidence/audit.

Use when a concrete performance claim, symptom, budget, regression, or metric needs measure-first work: baseline, bottleneck identification, optimization, remeasurement, guardrail, and evidence.

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.

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.

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.

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.