Claude Skills by SeongwoongCho

Complete the primary implementation, then switch roles: become an attacker whose goal is to break your own work. Write adversarial test cases, probe edge cases, attempt common exploit patterns, and challenge architectural decisions. Fix everything found. Repeat up to 3 attack-fix cycles. ---

Improve code structure without changing observable behavior. Use the Mikado method: one atomic step at a time, with test verification after every step. ---

Evaluate code changes across four dimensions: security, quality, performance, and maintainability. Produce findings with severity ratings and concrete fix suggestions. ---

Clarify ambiguous tasks through structured interviews before executing. Never write code against an unclear spec. ---

Break the task into 2–5 independent sub-tasks, solve each in isolation with its own verification, then integrate the results and verify the system as a whole. Each sub-task boundary is an explicit contract — integration is a planned phase, not an afterthought. ---

Produce accurate, complete, and well-styled documentation by reading source truth first. Never document from memory. ---

Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with persistent history and trend tracking. Team-aware: identifies the current user, then analyzes every contributor with per-person praise and growth areas. ---

Execute migrations — schema changes, dependency upgrades, API version changes, large-scale restructuring — with complete audit trails and verified rollback plans. ---

Decompose a task into 2–5 independent sub-tasks and emit a structured JSON so the orchestrator can fan them out in parallel worktrees. This harness only decomposes — it does NOT implement anything. Implementation is done by the fan-out agents in subsequent steps. **Key distinction from ensemble**: Ensemble runs the *same* task through *different* harnesses for comparison. Parallel-dispatch runs *different* sub-tasks (potentially through the *same* harness) to exploit genuine independence. ---

Improve performance through measurement-driven cycles. Never optimize without a baseline. Never ship an optimization that breaks tests. ---

Thoroughly review an engineering plan before any code is written. Combines an engineering review (architecture, code quality, tests, performance) with mode selection for scope posture. Interactive: one issue per question, opinionated recommendations, required completion summary. ---

Analyze the current branch's diff against main for structural issues that tests don't catch. Two-pass review: Critical issues block merge; Informational issues are advisory. Read-only by default — only modifies files if user explicitly chooses to fix a critical issue. ---

Produce a working solution first, then iteratively improve the weakest quality dimension. Each pass is measured before and after to prevent regressions. Stop when all dimensions meet threshold or the budget is exhausted. ---

Systematically QA test an application like a real user. Click everything, fill every form, check every state. Produce a structured report with health score and evidence. Four modes: diff-aware (automatic on feature branches), full (systematic exploration), quick (30-second smoke test), and regression (compare against baseline). ---

Persistent execution loop. Keep working on the task until all acceptance criteria pass, retrying with adapted strategies on each failure. ---

Create a structured implementation plan with self-review. Analyze the task, explore the codebase, propose an approach, identify risks, and challenge your own assumptions before handing the plan to downstream execution. ---

Build the minimum viable implementation of a feature as fast as possible. Cut scope aggressively. Prove the concept works. Document everything deferred. ---

Explore high-uncertainty problems through hypothesis-driven cycles. Measure everything. Document everything — including what failed. ---

Audit a codebase or change for security vulnerabilities. Produce a structured, actionable report. Never implement fixes — report and recommend only. ---

Fully automated ship workflow: merge main, run tests, review diff, bump version, update changelog, commit bisectable chunks, push, and create PR. Non-interactive — runs straight through and outputs the PR URL at the end. ---

Execute trivial, well-defined tasks directly. No planning, no TDD overhead. Read, change, verify, done. ---

Build a fast, disposable prototype to learn the problem space, extract its learnings, then implement a production-quality version from scratch informed by what the spike revealed. The spike is a learning tool — it is never shipped. ---

Merge two or more independent codebases (from ensemble worktrees) into a single, coherent, working project in the main workspace. This is not a summary — you physically read, compare, and write files. ---

Design and implement multi-component systems from scratch. This harness handles greenfield projects that span multiple services, external integrations, and infrastructure — going beyond single-module TDD to produce deployable, production-ready systems. ---

Diagnose and fix bugs through four strict phases. Never guess — every hypothesis is tested with evidence before a fix is applied. ---

Execute changes using strict red-green-refactor cycles. Every behavior is specified by a failing test before any production code is written. ---

Manage the adaptive-harness pool: list, inspect, promote, demote harnesses. Use when user asks about harness status or wants to manage the pool.

Manually invoke the adaptive-harness migration to update a project's .adaptive-harness directory to the current plugin version. Adds missing harnesses, updates config schema, and reports what changed.

Reference for the 6-axis task taxonomy used by adaptive-harness routing. Use when user asks how tasks are classified.

Auto-mode bootstrap for adaptive-harness. Intercepts tasks, routes to optimal harness, evaluates results. Use on every task when adaptive-harness auto-mode is active.