{"id":46328086,"url":"https://github.com/chrisallenlane/claude-swe-workflows","last_synced_at":"2026-04-28T02:02:09.617Z","repository":{"id":335201010,"uuid":"1144703340","full_name":"chrisallenlane/claude-swe-workflows","owner":"chrisallenlane","description":"Software Engineering workflows for Claude Code (MIRROR)","archived":false,"fork":false,"pushed_at":"2026-04-21T15:30:47.000Z","size":762,"stargazers_count":12,"open_issues_count":0,"forks_count":2,"subscribers_count":1,"default_branch":"master","last_synced_at":"2026-04-21T16:34:45.469Z","etag":null,"topics":["agentic-coding","ai-agents","ai-workflows","anthropic","automation","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","code-quality","code-review","developer-tools","llm","orchestration","software-engineering","workflow"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/chrisallenlane.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-01-29T00:36:01.000Z","updated_at":"2026-04-21T15:30:51.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/chrisallenlane/claude-swe-workflows","commit_stats":null,"previous_names":["chrisallenlane/claude-plugins","chrisallenlane/claude-swe-workflows"],"tags_count":13,"template":false,"template_full_name":null,"purl":"pkg:github/chrisallenlane/claude-swe-workflows","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chrisallenlane%2Fclaude-swe-workflows","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chrisallenlane%2Fclaude-swe-workflows/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chrisallenlane%2Fclaude-swe-workflows/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chrisallenlane%2Fclaude-swe-workflows/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/chrisallenlane","download_url":"https://codeload.github.com/chrisallenlane/claude-swe-workflows/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chrisallenlane%2Fclaude-swe-workflows/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32362782,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-27T20:07:02.737Z","status":"online","status_checked_at":"2026-04-28T02:00:07.250Z","response_time":56,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agentic-coding","ai-agents","ai-workflows","anthropic","automation","claude","claude-code","claude-code-plugin","claude-code-skills","claude-skills","code-quality","code-review","developer-tools","llm","orchestration","software-engineering","workflow"],"created_at":"2026-03-04T17:01:16.573Z","updated_at":"2026-04-28T02:02:09.609Z","avatar_url":"https://github.com/chrisallenlane.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# claude-swe-workflows\n\nA system of composable software engineering workflows for [Claude Code][cc].\nPlan projects, implement tickets, and run quality passes — from a single\nticket to a multi-batch project, using the same layered architecture.\n\n## Installation\n\n```bash\nclaude plugin marketplace add https://github.com/chrisallenlane/claude-swe-workflows.git\nclaude plugin install claude-swe-workflows@claude-swe-workflows\n```\n\n## How It Works\n\nThese workflows form a layered system where higher-level workflows\norchestrate lower-level ones. Each layer adds coordination, quality gates,\nand autonomy.\n\n```\n/lead-project                                   ← autonomous tech lead (OODA loop)\n└── invokes any skill below, driven by commander's intent\n\n/implement-project                              ← full project lifecycle\n├── /implement-batch (per batch)                ← multi-ticket orchestration\n│   ├── /implement (per ticket)         ← single-ticket implementation\n│   │   ├── SME implementation        ← language-specific specialist\n│   │   ├── QA verification           ← practical + coverage\n│   │   ├── Code review               ← security, refactor, perf\n│   │   └── Documentation             ← targeted doc updates\n│   ├── /refactor                     ← per-batch cleanup\n│   └── /review-doc                   ← per-batch doc audit\n├── /refactor (MAXIMUM aggression)    ← project-level cleanup\n├── /review-arch                      ← architectural restructuring\n├── /refactor (conditional)           ← post-restructuring cleanup\n├── /review-test                      ← test suite review\n├── /review-doc                       ← documentation audit\n└── /review-release                   ← pre-release readiness\n```\n\nPlanning feeds implementation. `/scope-project` plans a multi-batch\nproject with adversarial review, producing tagged tickets that `/implement-project`\nconsumes directly:\n\n```\n/scope-project  →  /implement-project\n    plan             implement + verify + polish\n```\n\nFor single tickets: `/scope` plans, `/implement` implements.\n\nFor open-ended work where the next step depends on the outcome of the last,\n`/lead-project` runs an OODA loop — observing project state, deciding what\nto work on next, and invoking lower-level skills until commander's intent is\nfulfilled.\n\nSupporting workflows are available at any level:\n\n**Reasoning and decisions:**\n\n- `/think-reframe` — problem redefinition\n- `/think-brainstorm` — divergent idea generation\n- `/think-diagnose` — abductive reasoning about causes\n- `/think-ach` — analysis of competing hypotheses\n- `/think-deliberate` — adversarial decision-making\n- `/think-premortem` — prospective failure imagination\n- `/think-scrutinize` — adversarial idea critique\n- `/think-reflect` — retrospective learning\n\n**Bug work:**\n\n- `/bug-fix` — diagnosis-first bug fixing\n- `/bug-hunt` — proactive bug discovery\n\n**Quality pipelines:**\n\n- `/test-mutation` — mutation testing\n- `/refactor-deep` — full tactical + architectural + tactical refactoring cycle\n- `/review-deep` — comprehensive pre-release review pipeline\n\n## Choosing a Workflow\n\nNot everything needs the full pipeline. Enter at the level that matches\nyour task:\n\n| You want to...                                                          | Use                  |\n|-------------------------------------------------------------------------|----------------------|\n| Drive a project to completion autonomously, deciding what to work on    | `/lead-project`      |\n| Implement an entire multi-batch project autonomously                    | `/implement-project` |\n| Implement a batch of related tickets                                    | `/implement-batch`   |\n| Implement a single ticket or feature                                    | `/implement`         |\n| Plan a multi-batch project with adversarial review                      | `/scope-project`     |\n| Plan a single feature and create a ticket                               | `/scope`             |\n| Fix a bug with diagnosis and root-cause analysis                        | `/bug-fix`           |\n| Proactively hunt for bugs before they're reported                       | `/bug-hunt`          |\n| Pressure-test a problem's framing before solving it                     | `/think-reframe`     |\n| Brainstorm approaches to a goal                                         | `/think-brainstorm`  |\n| Reason about why a phenomenon is happening                              | `/think-diagnose`    |\n| Narrow among competing hypotheses against evidence                      | `/think-ach`         |\n| Make a hard decision with adversarial deliberation                      | `/think-deliberate`  |\n| Imagine how a plan could fail, or how a hypothetical catastrophe could hit a running system | `/think-premortem`   |\n| Scrutinize an idea or plan before committing to it                      | `/think-scrutinize`  |\n| Reflect on a completed experience to update beliefs                     | `/think-reflect`     |\n| Clean up code quality (DRY, dead code, naming)                          | `/refactor`          |\n| Rethink module boundaries and architecture                              | `/review-arch`       |\n| Review and strengthen the test suite                                    | `/review-test`       |\n| Verify test quality via mutation testing                                | `/test-mutation`     |\n| Audit all project documentation                                         | `/review-doc`        |\n| Pre-release readiness check                                             | `/review-release`    |\n| Audit web content for accessibility barriers                            | `/review-a11y`       |\n| First-pass strategic orientation on a repo                              | `/review-health`     |\n| Review performance (compute and/or web)                                 | `/review-perf`       |\n| Perform a white-box security audit                                      | `/review-security`   |\n| Run every review dimension before a release, in one go                  | `/review-deep`       |\n\n**Rules of thumb:**\n- Open-ended work where the next step depends on the outcome of the last? `/lead-project`\n- Multiple batches of tickets forming a project? `/implement-project`\n- One batch of 2+ related tickets? `/implement-batch`\n- One ticket? `/implement` (or `/bug-fix` if it's a bug)\n- Not sure what to build yet? Start with `/scope` or `/scope-project`\n\n## Skills\n\n### Orchestration\n\nThese workflows manage the lifecycle of tickets — from implementation\nthrough quality passes to a merge-ready branch.\n\n#### /lead-project — Autonomous Technical Lead\n\nDrives a project from a stated commander's intent to completion with\nminimal user involvement. Takes structured intent from the user at startup\n(purpose, key tasks, end state, constraints, non-goals), then runs an OODA\nloop — observing project state, orienting against intent, deciding what to\nwork on next, and acting by invoking other skills (`/scope`, `/implement`,\n`/refactor`, `/review-*`, `/bug-*`, `/think-*`). The user acts as product\nowner; the skill acts as project manager and tech lead.\n\nStops autonomously when mechanical end-state conditions are met and reviews\nare clean, or pulls an andon cord when it hits a genuine blocker. Includes\nperiodic trajectory audits (every 10 cycles) and a capped run (50 cycles)\nto prevent drift or thrash.\n\n[Detailed documentation](skills/lead-project/references/README.md)\n\n#### /implement-project — Full-Lifecycle Project Workflow\n\nOrchestrates an entire project from tickets to release-ready code. Takes\nbatched tickets, implements each batch via `/implement-batch` in autonomous mode,\nruns smoke tests, then executes a comprehensive quality pipeline (refactor,\nreview-arch, review-test, review-doc, review-release). The result is a\nsingle project branch ready for human review and merge.\n\nMaximizes autonomy — the andon cord (stop-the-line escalation) is the only\nplanned intervention path.\n\n[Detailed documentation](skills/implement-project/SKILL.md)\n\n#### /implement-batch — Multi-Ticket Orchestration\n\nTakes a batch of tickets, plans their execution order, implements each\nsequentially using `/implement` in autonomous mode, runs cross-cutting\nquality passes (`/refactor`, `/review-doc`), and presents results for\nfinal review.\n\n[Detailed documentation](skills/implement-batch/SKILL.md)\n\n#### /implement — Single-Ticket Development\n\nOrchestrates a complete development cycle through specialist agents:\nrequirements → planning → implementation → QA → code review →\ndocumentation. Detects project type and dispatches to language-specific\nSMEs (Go, GraphQL, Docker, Makefile, Ansible, Zig, HTML, CSS,\nJavaScript, TypeScript).\n\n[Detailed documentation](skills/implement/SKILL.md)\n\n### Planning\n\nThese workflows explore problem spaces and produce well-specified tickets\nwithout doing implementation work.\n\n#### /scope-project — Adversarial Project Planning\n\nPlans an entire project through layered adversarial review loops.\nExplores the problem space, drafts tickets organized into batches, then\nruns a mandatory UX loop (\"should we build this?\"), zero or more\ndiscretionary specialist loops (security, performance) for projects with\narchitectural implications in those domains, and a mandatory implementer\nloop (\"could we build this?\") to find gaps, ambiguities, and missing\nwork. The architectural filter governs specialist loop invocation,\npreventing checklist behavior on projects where the domain isn't\nload-bearing. Locked elements (UX-locked, security-locked,\nperformance-locked) become hard constraints on downstream loops. Only\nwhen every applicable loop signs off do tickets go upstream — already\ntagged with batch labels ready for `/implement-project` to consume.\n\n[Detailed documentation](skills/scope-project/SKILL.md)\n\n#### /scope — Problem Space Exploration\n\nExplores problem spaces through iterative dialogue and codebase analysis,\nthen creates a detailed ticket in your issue tracker. For single features,\nbug investigations, or refactoring proposals.\n\n[Detailed documentation](skills/scope/SKILL.md)\n\n### Quality\n\nThese workflows improve code, tests, architecture, and documentation.\nThey run as part of `/implement-project`'s quality pipeline, but each works\nstandalone too.\n\n#### /refactor — Iterative Code Quality Improvement\n\nAutonomously scans for tactical improvements (DRY violations, dead code,\nnaming issues, unnecessary complexity), implements through specialist\nagents with QA verification, and loops until no improvements remain. Works\nwithin existing architecture — for structural changes, use `/review-arch`.\n\n[Detailed documentation](skills/refactor/SKILL.md)\n\n#### /review-arch — Blueprint-Driven Architectural Improvement\n\nAnalyzes codebase architecture via noun analysis, produces a target\nblueprint, then collaborates with the user to decide what to implement.\nFor module boundaries, responsibility overlap, utility grab-bag\ndissolution, and structural rethinking.\n\n[Detailed documentation](skills/review-arch/SKILL.md)\n\n#### /review-test — Comprehensive Test Suite Review\n\nFive-phase review: fills unit coverage gaps, surveys integration coverage,\nsurveys E2E (browser) coverage for webapps, identifies missing fuzz tests,\nand audits test quality. Each phase has its own analysis → present →\nselect → implement → verify cycle. Phase 3 (E2E) cleanly skips when the\nproject is not a webapp; integration and E2E phases verify by compile-check\nand prompt the user to run the suite ad-hoc rather than auto-running.\n\n[Detailed documentation](skills/review-test/SKILL.md)\n\n#### /test-mutation — Mutation Testing\n\nSystematically introduces mutations into source code and checks if tests\ncatch them. Surviving mutations reveal genuine coverage gaps that line\ncoverage misses. Multi-session with progress tracking.\n\n[Detailed documentation](skills/test-mutation/SKILL.md)\n\n#### /review-doc — Documentation Quality Audit\n\nComprehensively reviews all project documentation for correctness,\ncompleteness, and freshness. Fixes issues autonomously within its\nauthority.\n\n[Detailed documentation](skills/review-doc/SKILL.md)\n\n#### /review-release — Pre-Release Readiness Check\n\nPre-flight check before cutting a release. Scans for debug artifacts,\nversion mismatches, changelog gaps, git hygiene issues, breaking API\nchanges, and license compliance. Interactive — presents findings and lets\nyou decide what to fix.\n\n[Detailed documentation](skills/review-release/SKILL.md)\n\n#### /review-a11y — Accessibility Audit\n\nAudits web content against WCAG 2.2 Level AA. Detects web content files\n(HTML, JSX/TSX, Vue, Svelte, CSS, templates), dispatches accessibility\nauditor agents to evaluate conformance, and produces a consolidated\nreport prioritized by real-world user impact. Advisory only — no\nchanges made.\n\n[Detailed documentation](skills/review-a11y/SKILL.md)\n\n#### /review-health — Strategic Orientation Review\n\nFirst-pass strategic-orientation review of a repository. Use when you want\nto step back and assess a repo strategically — inheriting a work project,\nevaluating a FOSS library, revisiting your own repo, onboarding a\nteammate. Produces an evidence-cited map (not a grade) calibrated to a\nreference class, built to inform decisions about where to engage, where\nto tread carefully, and where to leave alone. OODA-structured workflow\n(Observe → Orient → Decide → Act) with per-class rubrics, ASHI severity\ntiers on individual findings, and an explicit coverage manifest for\nunavailable tooling. Advisory only — no changes made. Routes to sibling\nspecialists (`/review-arch`, `/refactor`, `/review-test`, etc.) when\nfindings warrant deeper follow-up.\n\n[Detailed documentation](skills/review-health/SKILL.md)\n\n#### /review-perf — Performance Review\n\nReviews a project for performance issues across two domains: compute\nperformance (algorithms, memory, CPU, benchmarking) and web performance\n(caching, asset delivery, loading strategy, Core Web Vitals). Detects the\nproject type and dispatches the appropriate specialist(s) in parallel.\nAdvisory only — no changes made.\n\n[Detailed documentation](skills/review-perf/SKILL.md)\n\n#### /review-deep — Comprehensive Pre-Release Review Pipeline\n\nThin orchestrator that runs every `/review-*` skill in sequence:\n`/review-health`, `/review-arch`, `/review-security`, `/review-perf`,\n`/review-a11y`, `/review-test`, `/review-doc`, `/review-release`. Each\nsub-skill keeps its normal interactive behavior — the operator\nparticipates throughout. Auto-detects phases that don't apply (no web\ncontent → skip `/review-a11y`; no tests → skip `/review-test`; etc.)\nand asks for confirmation on the skip list before starting. Ends with\na consolidated report that synthesizes findings across all phases.\n\n[Detailed documentation](skills/review-deep/SKILL.md)\n\n### Security\n\n#### /review-security — White-Box Security Audit\n\nOrchestrates a comprehensive security assessment of the project's source code\nusing both defensive and offensive analysis. A blue-teamer evaluates the\ndefensive posture first, then red-teamers attack informed by the defensive\ngaps. Dedicated red-teamers investigate each attack vector in depth. Findings\nare synthesized, exploit chains are explored, and the process iterates until\nno new chains emerge. Heavy and thorough by design.\n\n[Detailed documentation](skills/review-security/SKILL.md)\n\n### Decision and Diagnosis\n\nThe `/think-*` skills share a common design discipline — each is a structured countermeasure to a specific cognitive failure mode, sourced from a practitioner tradition (decision research, reflective practice, adversarial proceduralism, NGT, and others). See [THINK.md](THINK.md) for the family's design discipline, the five-test admission gate for new `/think-*` skills, and the intellectual lineage.\n\n#### /think-reframe — Problem Redefinition Before Problem Solving\n\nPressure-tests how a problem is framed before anyone tries to solve it.\nExtracts the premises embedded in the stated problem, then spawns\nparallel reframers applying different lenses in isolation\n(problem-vs-symptom, scope-shift, stakeholder-shift, level-of-abstraction,\ntime-horizon, inversion, category-shift, constraints-shift), and\nsynthesizes the alternatives into a report with a clear recommendation:\nkeep the original framing, adopt a specific reframing, or explore further.\nProduces feedback only — no code, no tickets, no artifacts. Sits upstream\nof `/think-brainstorm` in the natural pipeline.\n\n[Detailed documentation](skills/think-reframe/SKILL.md)\n\n#### /think-brainstorm — Divergent Idea Generation\n\nGenerates candidate approaches for a goal. Validates the assumptions\nembedded in the goal, then spawns parallel brainstormers running\ndifferent techniques in isolation (first-principles, working-backwards,\nlateral, analogical, constraints-shift, etc.), and synthesizes the pool\ninto a catalog of standouts, hybrid ideas, and reasonable alternatives.\nProduces feedback only — no code, no tickets, no artifacts. Natural\nhandoff to `/think-deliberate` (choose) or `/think-scrutinize`\n(stress-test).\n\n[Detailed documentation](skills/think-brainstorm/SKILL.md)\n\n#### /think-diagnose — Abductive Reasoning About Causes\n\nFigures out *why* something is happening. Takes a phenomenon, separates\nobservations from interpretations, then spawns parallel diagnosticians\napplying different reasoning lenses in isolation (technical,\nhuman-factors, process, incentive-structure, environmental, temporal,\nmeasurement-artifact, statistical). The orchestrator evaluates candidate\ncauses against evidence, calibrates confidence honestly (qualitative\ncategories — no fabricated percentages), and reports leading candidates\nwith distinguishing tests the user can run. Applicable to non-code\nphenomena. Produces feedback only — no code, no tickets, no artifacts.\n\n[Detailed documentation](skills/think-diagnose/SKILL.md)\n\n#### /think-ach — Analysis of Competing Hypotheses\n\nSystematically narrows among multiple hypotheses against evidence using\nRichards Heuer's Analysis of Competing Hypotheses (ACH) — a CIA-tradition\ntechnique designed to counter confirmation bias, premature closure,\nanchoring, and cherry-picking. Spawns parallel hypothesizers in isolation\nacross angles (leading, alternative, adversarial, null, deceptive,\nsurprise) and parallel evidence-gatherers across classes\n(direct-observational, documentary-historical, structural, behavioral,\nabsent, anomalous). Builds an explicit hypothesis-vs-evidence matrix.\n**Ranks hypotheses by least disconfirming evidence**, not most confirming\n— the central insight: hypotheses cannot be proven, only failed-to-be-\ndisproven. Includes diagnosticity analysis (which evidence actually\ndiscriminates), sensitivity analysis (what if load-bearing evidence is\nwrong?), and falsification milestones (what future observations would\ndistinguish the top candidates). Produces feedback only — no code, no\ntickets, no artifacts. Natural composition: `/think-diagnose` generates\ncandidate causes, `/think-ach` rigorously narrows among them.\n\n[Detailed documentation](skills/think-ach/SKILL.md)\n\n#### /think-deliberate — Adversarial Decision Making\n\nUses adversarial representation to make decisions. Spawns advocate agents\nfor each option who argue their cases, rebut each other, and respond to\nprobing questions before a judge renders a verdict with reasoning and\ntrade-offs.\n\n[Detailed documentation](skills/think-deliberate/SKILL.md)\n\n#### /think-premortem — Prospective Failure Imagination\n\nTreats a catastrophic failure as already-having-happened and reasons backward\nto the causes. Operates in two modes: **plan mode** (a not-yet-committed plan;\nimagine its catastrophic failure broadly across lenses) and **scenario mode**\n(a specific catastrophic scenario posed against an existing system;\ninvestigate the actual code and architecture for causes that could have\nallowed it). Spawns parallel pre-mortemers in isolation across failure-class\nlenses (technical, operational, estimation, scope, adoption,\ndependency-and-environment, team-and-coordination, incentive, detection,\nreversibility, adversarial). Synthesizes into a prioritized risk register\nwith early-warning signals the user can monitor for, calibrated qualitatively\n(*high / moderate / low / uncertain*) rather than with fabricated percentages.\nProduces feedback only — no code, no tickets, no artifacts. Sourced from\nKlein's pre-mortem methodology and the *prospective hindsight* finding from\ndecision research.\n\n[Detailed documentation](skills/think-premortem/SKILL.md)\n\n#### /think-scrutinize — Devil's Advocate for Ideas\n\nStress-tests an idea or plan before you commit to implementing it. Spawns\ncritical skeptics from multiple angles (technical, economic,\noperational, etc.), pairs them with an advocate defending the idea in\ngood faith, then synthesizes a report of faults that survived\ncross-examination. Produces feedback only — no code, no tickets, no\nartifacts.\n\n[Detailed documentation](skills/think-scrutinize/SKILL.md)\n\n#### /think-reflect — Retrospective Learning\n\nExtracts learnings from a completed experience — a project that shipped,\nan incident that resolved, a decision that played out. Gathers ground\ntruth (observations) separately from recollections (memory), actively\nloads external sources (logs, timelines, notes, git history), then spawns\nparallel reflectors applying different lenses in isolation\n(what-worked-vs-got-lucky, what-didn't, what-surprised,\nsystem-rewards-vs-intent, decisions-that-aged, what-to-tell-past-self,\npatterns-that-recur). The headline output is **updated mental models** —\nchanged beliefs — not a findings document. Produces feedback only.\n\n[Detailed documentation](skills/think-reflect/SKILL.md)\n\n#### /bug-fix — Diagnosis-First Bug Fixing\n\nCoordinates specialist agents through a diagnosis-first bug-fixing cycle:\nreproduce with a failing test, perform root-cause analysis with git\narchaeology, implement a targeted fix, and verify. Same review pipeline as\n`/implement`.\n\n[Detailed documentation](skills/bug-fix/SKILL.md)\n\n#### /bug-hunt — Proactive Bug Discovery\n\nSystematically hunts for bugs before they reach users. A risk assessor\ncross-references code complexity, test coverage gaps, and structural risk\nfactors to produce a ranked hotspot list. Dedicated hunters then\ndeep-dive into each hotspot, writing reproducing tests to validate or\ninvalidate suspected bugs. Every confirmed finding is backed by a\nreproducing test — no speculative reports. Optionally routes confirmed\nbugs to SME agents for fixing.\n\n[Detailed documentation](skills/bug-hunt/SKILL.md)\n\n## Agents\n\nSpecialist agents spawned by the workflows above:\n\n| Agent                          | Purpose                                                                                                    |\n|--------------------------------|------------------------------------------------------------------------------------------------------------|\n| `thk-ach-evidence-gatherer`    | Good-faith evidence enumerator for ACH proceedings, parameterized by an evidence class                     |\n| `thk-ach-hypothesizer`         | Good-faith hypothesis generator for ACH proceedings, parameterized by a hypothesis-generation angle        |\n| `thk-advocate`                 | Argues for an assigned position in adversarial proceedings                                                 |\n| `thk-brainstormer`             | Good-faith idea generator parameterized by a specific brainstorming technique                              |\n| `thk-diagnostician`            | Good-faith abductive reasoner that generates candidate causes through an assigned reasoning lens           |\n| `thk-premortemer`              | Good-faith failure imaginer that uses prospective hindsight to identify causes through an assigned failure-class lens |\n| `thk-reflector`                | Good-faith reflector that extracts learnings from an experience through an assigned reflection lens        |\n| `thk-reframer`                 | Good-faith reframer that restates a problem through an assigned reframing lens                             |\n| `thk-skeptic`                  | Good-faith skeptic that identifies faults in an idea through an assigned critical lens                     |\n| `swe-planner`                  | Decomposes complex tasks into implementation plans                                                         |\n| `swe-sme-golang`               | Go implementation specialist                                                                               |\n| `swe-sme-graphql`              | GraphQL schema and resolver specialist                                                                     |\n| `swe-sme-docker`               | Dockerfile and container specialist                                                                        |\n| `swe-sme-makefile`             | Makefile and build system specialist                                                                       |\n| `swe-sme-ansible`              | Ansible automation specialist                                                                              |\n| `swe-sme-zig`                  | Zig implementation specialist                                                                              |\n| `swe-sme-html`                 | HTML structure, semantics, and accessibility specialist                                                    |\n| `swe-sme-css`                  | CSS styling, layout, and responsive design specialist                                                      |\n| `swe-sme-javascript`           | Vanilla JavaScript implementation specialist                                                               |\n| `swe-sme-typescript`           | TypeScript implementation and type design specialist                                                       |\n| `swe-code-reviewer`            | Tactical code quality reviewer (DRY, dead code, naming, complexity)                                        |\n| `swe-arch-reviewer`            | Architecture reviewer (noun analysis, module boundaries, blueprints)                                       |\n| `swe-bug-assessor`             | Codebase risk assessor (complexity, coverage, structural risk, git churn — produces ranked hotspot list)   |\n| `swe-bug-hunter`               | Focused bug investigator (deep-dives hotspots, writes reproducing tests, validates findings)               |\n| `swe-bug-investigator`         | Bug root-cause investigator (execution tracing, git archaeology, diagnosis reports)                        |\n| `swe-perf-reviewer`            | Compute performance reviewer (algorithmic complexity, benchmarking, profiling, optimization)               |\n| `swe-web-perf-reviewer`        | Web performance reviewer (caching, asset delivery, loading strategy, Core Web Vitals)                      |\n| `qa-engineer`                  | Practical verification and test coverage                                                                   |\n| `qa-web-a11y-reviewer`         | WCAG accessibility reviewer (keyboard navigation, ARIA, contrast, semantic structure)                      |\n| `qa-test-reviewer`             | Test quality reviewer (brittle, tautological, useless tests)                                               |\n| `qa-test-coverage-reviewer`    | Coverage gap reviewer (coverage reports, risk prioritization, testability suggestions)                     |\n| `qa-test-integration-reviewer` | Integration test gap reviewer (seam survey, Mode A starter strategy, Mode B gaps and strategy expansion)   |\n| `qa-test-e2e-reviewer`         | E2E browser test gap reviewer (webapp detection, journey classification, Playwright-prescriptive Mode A)   |\n| `qa-test-fuzz-reviewer`        | Fuzz testing gap reviewer (fuzz infrastructure detection, candidate identification)                        |\n| `qa-test-mutator`              | Mutation testing worker (applies mutations, records results)                                               |\n| `qa-release-engineer`          | Pre-release scanner (debug artifacts, versioning, changelog, git hygiene, breaking changes, licenses)      |\n| `sec-blue-teamer`              | Defensive security analyst (control inventory, consistency, defense-in-depth, configuration)               |\n| `sec-red-teamer`               | Adversarial security analyst (attack surface mapping, exploitation, trust boundary analysis)               |\n| `ux-reviewer`                  | Methodical UX advocate for `/scope-project`'s pre-implementation review loop (seven-concern spine, target-type detection) |\n| `doc-maintainer`               | Documentation updates and verification                                                                     |\n\n## Development\n\nSee [HACKING.md](HACKING.md) for local development and testing instructions. See [CHANGELOG.md](CHANGELOG.md) for release history and [CONTRIBUTING.md](CONTRIBUTING.md) for contribution policy.\n\n## Versioning\n\nThis project follows [Semantic Versioning](https://semver.org/). Skills (slash commands like `/implement`, `/review-perf`, etc.) are the public interface. Subagent names are internal implementation details and may be renamed or restructured without constituting a breaking change.\n\n## Requirements\n\n- `git` repository\n- For ticket creation: integration with your issue tracker (CLI, MCP server, or API)\n\n[cc]: https://claude.ai/code\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchrisallenlane%2Fclaude-swe-workflows","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fchrisallenlane%2Fclaude-swe-workflows","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchrisallenlane%2Fclaude-swe-workflows/lists"}