antonarhipov

A method for organizing a prototype that illustrates an agentic, spec-driven PR review—the type a person employs to determine if a merge is acceptable without scrutinizing each alteration. Applicable when a user intends to create, outline, or develop a review interface, a review dashboard, a PR-review process, or a "verdict screen" for an agent-generated modification set, particularly one generated by a specification-driven development (SDD) workflow. Triggers encompass: "review flow", "PR review prototype", "review UI", "how should I present this review", "verdict-first review", "visualize the PR", or asking how a developer should review an agent's output. This is a METHOD skill — it tells you how to think about and lay out the prototype; it does not lock you to a single output format. Do NOT use for performing the code review itself (finding bugs, judging the author) — that is a different skill.

Reviews a pull request in two stages — first interrogating the author to verify they understand and can defend every decision in their own submission (catching AI-generated code forwarded without comprehension), then performing a structural design review of intent fidelity, abstractions, coupling, and failure behavior. The comprehension gate must pass before the design review runs. Use when reviewing a feature PR, vetting incoming code for author ownership, screening for AI slop, or running a deep structural review beyond what CI and linters cover.

Interview the user one question at a time, walking the decision tree, to clarify a feature proposal before implementation

Translate the spec into a complete, traceable set of acceptance criteria in EARS form

Capture feature-level design decisions and the technical constraints that follow, traceable to acceptance criteria

Stress-test the spec pipeline outputs against each other and the codebase before implementation begins

Generate an implementation task list from validated spec artifacts

Execute the implementation plan in spec/tasks.yaml task by task, validating each against its acceptance criteria and halting at checkpoints. Use this skill whenever the user asks to implement, execute, run, continue, or work on a plan; when a spec/ directory with tasks.yaml exists in the repo; when they reference task or phase IDs (task-N.M, phase-N); or when they ask to start the next task or phase.

Interview the user one question at a time, walking the decision tree, to clarify a feature proposal before implementation

Stress-test the spec pipeline outputs against each other and the codebase before implementation begins

Authoritative guidance on modern Kotlin language features (2.2.0 through 2.3.21) — writing idiomatic code, reviewing or modernizing older code, and upgrading across the 2.2 → 2.3 line. Make sure to use this skill whenever the user mentions Kotlin 2.2, 2.2.20, 2.3, 2.3.0, 2.3.20, or 2.3.21, or any of these features: guard conditions in `when`, non-local `break`/`continue` in inline lambdas, multi-dollar string interpolation, context parameters, context-sensitive resolution, nested type aliases, the `@all` annotation use-site target, unused return value checker, explicit backing fields, name-based destructuring, data-flow exhaustiveness for `when`, or `return` in expression-body functions. Also trigger for compiler flags `-Xreturn-value-checker`, `-Xexplicit-backing-fields`, `-Xname-based-destructuring`; annotations `@MustUseReturnValues` and `@IgnorableReturnValue`; or any question framed as "what's new in Kotlin" or "latest Kotlin features."

Debugger-first runtime root-cause analysis for JVM code in IntelliJ IDEA. Use when runtime state or control-flow evidence is needed (values, branches, call order, reachability), when the question spans long call chains across many files, or when the user explicitly requests the debugger. Evidence comes from logpoints/breakpoints, stepping, stacks, runtime values, expression evaluation, and control-flow observations.

Best practices for Java/Spring projects. Use when working with Spring Boot applications, Spring Framework code, or any Java project using Spring ecosystem. Enforces DDD principles, Testcontainers for integration testing, explicit code without Lombok, MapStruct for entity/DTO mapping with strict layer boundaries, Spring Data JPA with proper transaction management, and conservative dependency management. Triggers on Spring Boot, Spring Framework, Spring Data, Spring MVC, Spring WebFlux, or general Java backend development tasks.

Best practices for Java/Spring projects. Use when working with Spring Boot applications, Spring Framework code, or any Java project using Spring ecosystem. Enforces DDD principles, Testcontainers for integration testing, explicit code without Lombok, MapStruct for entity/DTO mapping with strict layer boundaries, Spring Data JPA with proper transaction management, and conservative dependency management. Triggers on Spring Boot, Spring Framework, Spring Data, Spring MVC, Spring WebFlux, or general Java backend development tasks.