harnie

Runs the verification a design fixed, in a session that did not write the implementation, and attributes each run to the requirements' completion criteria so every criterion lands on 검증됨, 미검증, or 실패. Confirms a reproducing test failed before the fix, and audits the test files the change edited. Use after implementation review clears a change and before the change is called done. Produces a Korean result file beside the design document. Do NOT use to review code or a design, to hunt defects, to decide whether a failure belongs to the implementation or to the design, to fix anything, or in the session that wrote the implementation.

Verify whether an author's response to a review finding (a reply or a code change without a reply) actually resolves a thread I started, then recommend whether to resolve it and whether to revote. Follow pr-review for resolution criteria and unblocking conditions. The caller performs scanning, retrieval, resolution, voting, and platform API calls.

Structure development documents such as designs, definitions, and proposals into readable Confluence pages, render Mermaid natively through a caller-injected diagram macro when one is available (otherwise degrade it to tables/ASCII/Expand), and publish through the Atlassian MCP. Load each document type's section skeleton from the matching file under skeletons/ on demand while using one type-independent engine for input collection, rendering, diagram handling, and publication. The caller injects publication targets (cloudId, space, parent, naming, accounts, status labels, and the optional Mermaid macro identity). Do not generate document content or judge its quality; upstream owns both.

Review the changes targeted by a deployment approval request, decide whether to approve or hold based on deployment-blocking problems, and recommend advancing workflow state when the approval quorum is met. Use pr-review criteria (blocking means issue-level). The caller records approval signals, counts the quorum, and performs state transitions.

Runs the harnie development chain end to end on one instruction for a small, clearly bounded change — designs it, has the design reviewed, implements it, has the implementation reviewed, and verifies it, with the reviews and the verification in one separate session of the other provider opened through orca. Refuses before starting when the request carries signs of a large or risky change, and hands the work back after the design when the design turns out larger than one session should own. Use for a routine change the requester wants done without directing each stage. Do NOT use for work that needs a requirements stage, spans repositories, changes a schema or an external contract, touches security, authentication, or payment paths, or is meant to run as parallel sessions.

Implements a contract as written — a software design document when one exists, otherwise the requester's request — records the baseline commit it started from, runs the verification that reaches the change, and stops on whatever the contract left open instead of deciding it. Takes the design file path, or the request when there is no design, and optionally a scope limit naming which files this session owns so several sessions can run one design side by side. Use when implementation is what is being asked for. Do NOT use to write or revise a design or requirements, to settle an open item, to review code, or to split work into units and dispatch them.

Reviews the code an implementation produced against its contract — the design document when one exists, otherwise the requester's request — and drives rounds of review and revision, three on its own and more only when the user releases them. Finds open items the code answered anyway, files changed outside the contract, decisions with no code behind them, contract errors patched around locally, mechanisms nothing needed, missing failure behavior, and correctness defects in the change and its blast radius. Use once code exists and before the verification stage starts. Do NOT use to review a design, to write code beyond the findings the coordinator accepted, for visual or UI review, or for PR review at merge time.

Write profile-driven delivery content for completed changes: a PR title and selected body sections plus review-request content and review type. Use a caller-injected Delivery Profile for title convention, body sections, and review-request policy while leaving platform execution, branch, and merge strategy to the caller.

Review submitted code changes in a PR at a senior-engineer standard, classify findings as `issue:`/`discuss:`/`nit:`, and recommend approval status. Judge only what is wrong, why it matters, and its severity; the caller determines execution details such as voting, mentions, comment placement, disclaimers, and platform operations. Use for human PR reviews and automated PR-review routines. Reviewing an implementation against its design document is separate and belongs to the implementation-review skill.

Collect accumulated review findings, cluster recurring quality problems, and propose candidates for promotion into enforced rules such as lint, CI, or review criteria. Operate semi-automatically—propose only and let the user choose what to adopt. Never change standard configuration automatically.

Turn a short or vague development request into a requirements document that admits only one reading, by scanning it for ambiguity, resolving the ambiguities that would change the resulting software, and recording the rest as explicit assumptions. Use before design or implementation starts, whenever scope, failure behavior, or completion criteria are still open — including requests that look small. Produces a Korean requirements file at the path the user names, and produces neither the design nor the implementation. Do NOT use to review existing code.

Turns a settled requirements document, or a short direct request, into a Korean software design document that an implementation agent with a small reasoning budget can execute without making core decisions of its own. Reads the requirements file when one is named, grounds every environment claim in the actual repository, and fixes file paths, interfaces, failure behavior, and a runnable verification step. Use after requirements are settled and before implementation starts. Do NOT use to write requirements, to review an existing design, to write code, or for visual, UI, or graphic design of any kind.

Reviews a software design document against the requirements it was written from, before implementation starts, and drives rounds of review and revision — three on its own, more only when the user releases them. Finds decisions left for the implementer, environment claims not grounded in the repository, verification that never reaches the change, uncovered requirements, dropped open items, and mechanisms no requirement needs. Use once a design document exists and before code is written. Do NOT use for visual, UI, or graphic design, for code or PR review, or to author a design document.