claude-harness

Project-grounded blast-radius tracing for code changes, PRs, diffs, files, symbols, or bugfixes, especially in Helpdesk-style repos. Use before editing, committing, merging, or reviewing when downstream callers, tests, routes, SQL, configs, schema, auth/tenant boundaries, external integrations, sibling bugs, or review-derived trap replays could be affected.

Standard rigorous multi-agent pipeline for bugs and build tasks that "must be workflowed". Engage when the user says "workflow this", "must be workflowed", "run the bug factory", "process the open bugs", "sweep and fix the bugs", or flags a build/bug task for the full pipeline. Sweeps open issues tagged `bug` (closes already-resolved ones), then runs each surviving bug through: confirm to plan/zoom-out/blast-radius convergence loop (fresh eyes) to build (one agent per file) to test to review (blast-radius + patch-or-fix + zoom-out) to verify (computer-use + Chrome on the local Cortex instance, explicit demonstrative proof) to ship (PR to dev, babysit, test on dev, PR to main, babysit, confirm on main). One agent = one job. Proof-or-STFU. The main merge is the only human-gated step.

Audit pull requests, branches, diffs, or local source files for semantically suspicious variable, identifier, member-access, and payload-field usage. Use when checking wrong-object bugs such as product.id versus rexProduct.id, source-system identity confusion, alias erasure, mismatched payload keys, or cross-system variable mixups; optionally publishes open-PR comments or merged-PR investigation issues and hands explicit issue targets to issue-to-green-pr when publication is authorized.

Review plans, fixes, and designs before implementation so code can be built mechanically. Use before coding, contract review, spec audit, readiness checks, or post-implementation contract verification. Fails vague contracts and missing Mechanical Build Packet fields.

Use when choosing daily Helpdesk service-to-domain migration candidates, table ownership moves, write seam consolidation, domain README gaps, or A-plus architecture burn-down work before implementation.

Use when inspecting Helpdesk domains for SRP, README, write-boundary, table ownership, or service-migration opportunities and when running one selected domain refactor lane through enterprise gates, PR audits, review loops, and explicit dev merge authorization.

Mandatory read-only pre-action and plan-review protocol for substantive coding, debugging, design, review, refactor, system-analysis, workflow, and business-context work. Use this skill to prevent first-match excitement by forcing source-grounded reading, explicit zoom-out system mapping, operator/business framing, root-cause, blast-radius, ownership, status/lifecycle coverage, plan viability, edge-case, SRP/refactor, schema/live-DB, headless UI, and verification thinking before implementation. Deep Think must not edit files, create worktrees, delegate coding, mutate systems, or fix bugs; it produces a decision-quality handoff only. Apply by default on bug fixes, feature work, refactors, plan reviews, code reviews, incidents, architecture, risky config, schema/query/data-sensitive work, and UI/PDF/file workflows. Exempt only pure chat and tiny low-risk housekeeping.

Use when preparing to deploy code to production, merging to main, running migrations on production databases, or setting environment variables on Render. Use when the user mentions "deploy", "push to production", "merge to main", "run migrations", or asks about pending deploy items. Also use when reviewing what needs to happen before a feature goes live.

Use when debugging bugs, failures, regressions, stale proof, recurring whack-a-mole fixes, unclear ownership, poor seams, missing domain boundaries, write/leak risks, or behavior needing coordinated root-cause investigation.

Bounded consensus workflow for diagnostic skills, root-cause handoffs, fix evals, and pasteable /goal prompts. Use when Ben asks for a cohort, committee, looping agreement, multi-agent diagnostic review, but-why style assumption challenge, or when diagnose, patch-or-fix, blast-radius, or another diagnostic gate needs agreement on the issue, root cause, resolution, evals, and next goal before implementation.

Turn a vague or product-shaped enterprise request into a Technical Design Document. Extract intent, read source, design the product/workflow, then write a source-grounded TDD for plan/contract.

Use when a locked enterprise contract and mechanical build packet exist and implementation must proceed through strict TDD, contract traceability, receipt-only progress, and staged review handoffs. Always use this for enterprise build-stage work; stop if the complete build body is unavailable.

Use when verified enterprise work or a resolved debugging session should be captured as searchable institutional knowledge with prevention guidance

Use when an enterprise implementation plan exists and work needs a locked contract with postconditions, invariants, consumer mapping, and traceability before build starts

Systematic enterprise debugging for bugs, failing tests, and unexpected behavior. Reproduce, trace, scan blast radius, identify root cause, then fix with TDD and prevention records.

Full enterprise workflow for legacy enterprise-dev invocations. Use when starting a feature, significant refactor, enterprise hardening effort, GitHub issue intake/processing, or multi-stage bugfix that needs end-to-end workflow control, portable repo-local artifacts, and explicit proof scope.

Use when starting enterprise work in a new repo, new worktree, unfamiliar package, or new computer, or whenever commands, paths, conventions, portability, or project traps are not yet known

Use when reviewed enterprise work still needs adversarial probing, mechanical checks, and recycle-loop bug closure before final verification

Use when enterprise work has been built and reviewed and needs a final mechanical ship or release gate before merge, PR readiness, install, deploy, or signoff. Checks proof trace, current diff, architecture, post-merge test kit, rollback, observability, security/privacy, and performance regression readiness.

Use when an approved enterprise design exists and the next step is to turn it into an exact implementation plan with file paths, task boundaries, and verification commands

End-to-end enterprise workflow for turning multiple refactor opportunities into serial green pull requests. Use when the user asks to identify refactor/domain opportunities, create lane plans, run Helpdesk enterprise gates, use specialist subagents, loop code reviews such as /review, CodeRabbit, Copilot, or GitHub review threads until no findings remain, create PRs, or merge approved refactor lanes to dev with proof.

Use when enterprise implementation is complete enough for a structured review that separates spec compliance from code quality and classifies drift explicitly

Use when starting a feature, significant refactor, enterprise hardening effort, GitHub issue intake/processing, or multi-stage bugfix that needs end-to-end workflow control, portable repo-local artifacts, and explicit proof scope

Tech stack decision phase for the enterprise pipeline. Auto-detects which technology domains need decisions (runtime, framework, database, auth, etc.), presents options with decision matrices, and locks choices into stack-decisions.json for downstream consumption by enterprise-plan. Incumbent bias for existing projects. Only triggers on FULL path. Use between enterprise-brainstorm and enterprise-plan.

Use when enterprise work is about to be declared complete and the claim needs fresh evidence, postcondition tracing, and an explicit proof-scope verdict

Plan, implement, or review frontend UI code with clean architecture guardrails and a default single-purpose file architecture. Use for React, TypeScript, UI components, custom hooks, client-side services, API integration views, design-system components, frontend feature setup, frontend refactors, and code review where separation of presentation, state/use-case logic, data access, accessibility, loading/error/empty states, or test seams matter. Do not use as a replacement for repo route cards, enterprise gates, product-design visual work, live proof, browser proof, or local project conventions.

Use when turning a diagnose.build_packet.v1 JSON packet, bug diagnosis, or agent handoff into GitHub issues or issue comments, especially when the user wants ready-for-agent work items created without implementing code.

Use when approaching context limits (70%+ usage), switching tasks mid-stream, ending a session with incomplete work, or when the user says "write a handover", "save progress", "I need to stop", or "context is getting full". Also use proactively when you detect that context compression has started occurring.

Standards-enforcement gate that runs BEFORE implementation. Takes a plan, TDD, or fix proposal and hard-blocks it if SRP, seam, ownership, blast radius, edge cases, or root-cause reasoning are missing. Emits a hardening-report.md that downstream skills (enterprise-plan, enterprise-contract, patch-or-fix, b-deep-debug) require. Use this whenever you are about to commit to an implementation approach.

Pull latest skills from claude-harness repo and sync to ~/.claude/skills/ and ~/.codex/skills/. Run this in any project to get the latest enterprise skills. Use when the user says 'update skills', 'sync skills', 'pull latest harness', or invokes /harness-update.

Oldest-first Helpdesk dev PR queue closeout orchestrator. Use when Ben asks to drain, close out, babysit, green, reply to review threads, or merge eligible open Helpdesk pull requests targeting dev. Requires live GitHub truth, clean isolated worktrees, full PR blast-radius fan-out, patch-or-fix for bugfix or behavior PRs, non-mock proof, evidence replies on every review thread, current-head checks, explicit current merge authorization, GitHub issues for non-blocking follow-ups, and worktree cleanup after verified dev merge. Do not use for promote, ship to main, production deploys, or generic single-PR review unless the task is queue closeout.

Apply final Claude/Codex consensus quality gates for Helpdesk PRs, goals, skills, and workflows before claiming ready, green, done, merge-ready, or workflow-complete.

Use when reviewing, creating, enabling, disabling, or troubleshooting Codex hooks; when hooks may be adding context noise, hidden state, stale disabled entries, or surprise behavior; or when proposing a guardrail hook. Keeps hooks mechanical, low-noise, PreToolUse-first, deterministic, and separate from skill decision logic.

Use when writing or modifying code that interacts with REX (Retail Express), Shopify, or any external integration/sync system. Triggers on work involving SOAP calls, REX API, Shopify API, inventory sync, order sync, product sync, fulfillment sync, or any code in services/retailExpress/, services/shopify*, or queue workers. Use before writing any integration code to avoid known pitfalls.

Use after GitHub issues are created, discovered, pushed, or handed off and the operator asks "now what", "which issue should an agent do", "make this ready for a build agent", "turn these issues into agent prompts", or "classify the queue". Fetches live issue state, separates intake from proof, routes through diagnose/pre-code-hardening/specialist-dispatch, and produces the next exact agent prompt without implementing code.

Control nested single-job subagents without overrunning thread capacity. Use when the user asks for nested agents, subagents, bug-factory style one-agent-one-job delegation, review coordinators, multi-agent build/review/proof loops, or when prior agent loops hit thread limits and need disciplined orchestration.

Evidence-gated post-fix review that classifies whether a bug change removes the root cause or only masks the symptom. Any invocation, including a one-sentence prompt, requires the full canonical workflow and Required Output sections: Evidence Ledger, Assumption Ledger, Boundary Ledger, Specialist Reviews, Causal Chain, Structural Checks, Falsification, Required Fix, and Verification. Requires code/runtime proof, specialist subagents, assumption review, SRP/ownership/domain boundary checks, recurrence guards, a diagnose.build_packet.v1 JSON handoff for gh-issues/build follow-up, and finite stop rules before any FIX verdict.

Use when a plan, design, migration, or deployment checklist is drafted and needs review before passing a planning gate or proceeding to implementation. Triggers on phrases like "review this plan", "is this ready", "gate check", "audit the plan", "stakeholder review", or whenever a document in docs/plans/, .claude/designs/, or docs/handovers/ is about to be acted on. Also use proactively before any implementation begins. Every plan must pass stakeholder audit, enterprise architecture review, and root-cause structural review before code is written; plans that do not prove root cause, ownership, SRP/cohesion, domain boundaries, correct seams, fix-now refactors, and recurrence guards must fail.

Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible. For refactor, debugging, lifecycle/status, or system-design plans, require source grounding plus a bounded zoom-out across callers, consumers, sibling flows, ownership, state/status cohorts, and verification before approving tasks.

Create or run a post-merge validation kit for a PR after it lands. Use when the user asks how to test a merged PR, validate a release, smoke-test production, verify deploy behavior, or choose agent-run versus human-run post-merge checks.