skill-forge

Use when the user wants a pull request, diff, commit, patch, branch, or set of changed files reviewed through independent specialist passes for actionable issues introduced or worsened by the change. Orchestrate mandatory correctness and contract-test reviews, conditionally add security, reliability, architecture, or infrastructure reviews, independently verify candidate findings, remove root-cause duplicates, and synthesize only confirmed issues into an evidence-backed verdict. Do not use for simple code explanations, implementation-only requests, formatting-only cleanup, generic programming advice, or full-codebase audits unrelated to a specific change.

Use when the user asks to design, evaluate, document, or review software architecture for a new or existing system, including architecture alternatives, ADRs, component or integration boundaries, layered or modular monolith design, service decomposition, scalability, availability, quality attributes, runtime or deployment views, architecture risks, or migration plans. Inspect repository evidence when available, compare explicit tradeoffs, separate facts from assumptions, and produce decision-ready artifacts. Do not use for simple architecture definitions, generic brainstorming, isolated bug fixes, feature implementation, or behavior-preserving refactoring unless an explicit architecture decision is the task.

Use when the user wants to grill, stress-test, pressure-test, or otherwise validate a plan, design, product idea, architecture decision, implementation plan, business strategy, writing direction, research question, learning plan, personal decision, or Agent Skill design through Socratic, one-question-at-a-time interrogation with options and session logging. Also trigger on casual pre-execution phrasing like "X 하려고 하는데 파헤쳐줘", "빈틈없이 검증해줘", "질문으로 털어줘", "반대신문하듯 봐줘", "압박 검증해줘", or vague validation asks such as "이거 괜찮아?". Do not use for simple factual Q&A, brainstorming lists, text formatting, direct summaries, direct rewrites, or immediate code/plan generation.

Use when the user asks to fix broken, incorrect, failing, flaky, or regressed behavior, such as failing tests, wrong status codes, crashes, ignored CLI flags, duplicate output, wrong UI rendering, infinite retries, stack traces, or behavior that used to work and no longer does. This skill guides regression-test-driven bug fixing through Reproduce → Root Cause → Regression Test → Minimal Fix → Verify by capturing the symptom, reproducing or representing the failure, defining expected behavior, localizing the root cause, adding or updating a failing regression test when feasible, applying the smallest safe fix, and verifying honestly. Do not use for new feature development, behavior-preserving refactoring, speculative cleanup, architecture redesign, dependency upgrades, documentation-only work, test-only cleanup, or general investigation without a fix.

Use when the user asks to add, implement, create, support, enable, expose, integrate, or build a new capability, API, UI behavior, command, option, workflow, or product behavior in a codebase using strict test-driven development. This skill guides feature development through Red → Green → Refactor by framing the requested behavior, writing or updating tests before production code, confirming meaningful failure, implementing the smallest passing change, refactoring only after green, and reporting real validation. Do not use for bug fixing, behavior-preserving refactoring, investigation-only tasks, documentation-only changes, test-only cleanup, or dependency upgrades unless the upgrade is directly required for the feature.

Use when the user asks to refactor, clean up, simplify, extract, rename, remove duplication, improve readability, split files, improve separation of concerns, or make code easier to test while preserving externally observable behavior. This skill guides conservative, test-protected refactoring through Baseline → Transform → Same Tests by defining the behavior boundary, running baseline tests before editing, applying one small safe transformation at a time, re-running the same tests, and stopping if behavior preservation cannot be verified. Do not use for feature development, bug fixing, intentional behavior changes, speculative rewrites, architectural redesigns, dependency upgrades, or broad cleanup.

Use when the user needs a specific repeatable workflow. Describe the trigger clearly. Do not use for unrelated tasks, simple factual Q&A, or requests that should be handled directly without this workflow.