Test Double

OI-3 spike harness — the INLINE (non-forked) readability-guidance variant. Surfaces the shared readability standard into the calling skill's own context. Use only when a spike consumer skill invokes it.

中文简介正在准备中。当前显示原文说明。

OI-3 spike harness — heavy consumer skill, INLINE arm. Builds an incident post-mortem and sources the readability standard mid-workflow via an inline (non-forked) guidance skill. Use only when explicitly invoked by the spike harness with a TRIAL_ID and data path.

中文简介正在准备中。当前显示原文说明。

OI-3 spike harness — ADVERSARIAL inline guidance variant. Worst-case anchor: ends with a final-sounding completion statement and gives NO instruction to return to the caller. Use only when a spike consumer skill invokes it.

中文简介正在准备中。当前显示原文说明。

OI-3 spike harness — the FORKED (context fork) readability-guidance variant. Same payload as the inline variant but declared to run in a forked context. Use only when a spike consumer skill invokes it.

中文简介正在准备中。当前显示原文说明。

Internal harness probe for the OI-3 readability-guidance spike. Use only when explicitly told to invoke spike-probe. Verifies that a freshly-created project skill renders into a subagent's context via the Skill tool.

中文简介正在准备中。当前显示原文说明。

Break a trusted implementation plan (or other provided context) into independently-grabbable, atomic work items, written to a single work-items.md file. Use when the user wants to convert a plan into work items, create implementation tickets or tasks, divide a plan into work units, or break the plan down into grabbable pieces. Do not use when there is no implementation plan yet or the plan is not yet trusted — use plan-implementation to produce the plan or iterative-plan-review to harden it first. Does not sequence work into demoable delivery phases — use plan-a-phased-build for that. Does not write code — use tdd to implement a work item.

中文简介正在准备中。当前显示原文说明。

Restructure existing code without changing its behavior, through a test-gated refactoring loop: a named target, a green suite over that target before any edit, a planned sequence of small named refactorings, and the full suite re-run after every step. Use when the user wants to refactor, restructure, clean up, simplify, or improve the design of existing code, or to apply refactoring recommendations from a code-review or architectural-analysis report. This skill changes code; it does not review code (use code-review), assess architecture (use architectural-analysis), plan a multi-module restructure before executing it (use plan-a-change), map domain boundaries before restructuring along them (use ddd-analysis), or build new behavior test-first (use tdd). Do not use it on code inside an active tdd loop; the refactor step of tdd owns that cleanup. Runs its planned sequence to completion without pausing for review; to review each named refactoring as it lands, use pairing.

中文简介正在准备中。当前显示原文说明。

Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does not evaluate architectural testability or structural coupling — use architectural-analysis for architectural assessment.

中文简介正在准备中。当前显示原文说明。

Write code through a disciplined, BDD-framed Test-Driven Development loop: build a behavior test list, then drive each behavior through red-green-refactor with an enforced observed-failure gate. Use when the user wants to implement, build, or write code test-first, "do TDD", follow "red-green-refactor", drive code from tests, choose the next test by the Transformation Priority Premise (TPP) or ZOMBIES ordering, or grow a feature behavior-by-behavior with tests leading. This skill writes and changes code; it does not produce a test plan document (use automated-test-planning, or manual-test-planning for a plan a person runs by hand), review or audit existing code (use code-review), restructure existing code outside a TDD loop (use refactor, or plan-a-change to plan a multi-module restructure), specify what a feature should do (use plan-a-feature), or find the root cause of a bug (use investigate). Runs its loop to completion without pausing for review; to review each behavior as it lands, use pairing.

中文简介正在准备中。当前显示原文说明。

Evidence-based investigation of issues, bugs, API calls, integrations, and other aspects of software development that need a deep dive to find the root cause and solutions. Use when you need to debug, troubleshoot, diagnose, or figure out why something is broken. Does not review code for quality or style — use code-review for auditing changes or post-code-review-to-pr for posting review feedback to GitHub. Does not assess architectural health or structural risk — use architectural-analysis for architectural concerns. Does not research open-ended options, prior art, or how something works when nothing is broken — use research for that. Does not plan the structural change a root cause calls for — use plan-a-change. Does not map bounded contexts or domain boundaries — use ddd-analysis. Does not capture feedback on Han's own skills — use han-feedback for that.

中文简介正在准备中。当前显示原文说明。

Cut a Han release: update CHANGELOG.md with the changes since the last release, bump and tag every plugin that changed as {plugin-name}--v{version} so a version-constrained dependency can resolve, and publish a GitHub release crediting every merged pull request and closed issue to the people behind it. Use when releasing, cutting a release, shipping a new Han version, publishing release notes, or tagging a version. Always stops for approval before creating any tag, because a pushed tag is never moved. Requires the gh CLI, jq, the claude CLI, and a clean git checkout. This is a repository-maintenance skill for the Han repo itself, not a general review or PR skill — use code-review for local review, post-code-review-to-pr to post a PR review, and update-pr-description for PR bodies.

中文简介正在准备中。当前显示原文说明。

Produces a progressive-disclosure overview of unfamiliar code or a pull request's changes with code-overview and publishes the resulting overview to a user-specified Confluence location. Use when the user wants code or a PR explained, oriented, or made sense of AND the overview posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not produce the overview to a local file only — use code-overview. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not root-cause a bug to Confluence — use investigate-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

中文简介正在准备中。当前显示原文说明。

Runs an evidence-based investigation of a bug, failure, or unexpected behavior with investigate and publishes the resulting investigation report to a user-specified Confluence location. Use when the user wants something debugged, diagnosed, or root-caused AND the findings posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not investigate to a local file only — use investigate. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

中文简介正在准备中。当前显示原文说明。

Builds a feature specification from scratch with plan-a-feature and publishes it to a user-specified Confluence location, posting the spec as a parent page and each companion artifact (decision log, team findings, technical notes) as a child page beneath it. Use when the user wants a new feature planned, designed, scoped, or specified AND posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not plan to local files only — use plan-a-feature. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not refine or stress-test an existing plan — use iterative-plan-review. Does not document already-built features to Confluence — use project-documentation-to-confluence.

中文简介正在准备中。当前显示原文说明。

Designs the contract for an API change inside one codebase — a component's props, a function surface, URL or query parameters, an event payload, or a module boundary — through a discovery pass, an options document with one recommendation, a question round, and an adversarial validation round, with every element of the contract justified from one stated goal. Use when you want to design, shape, decide, or nail down an interface, contract, signature, or API change for a capability you can already describe, sized for roughly one pull request. Produces a design document and changes no code. Does not specify what a feature should do — use plan-a-feature. Does not plan delivery or sequencing — use plan-implementation. Does not assess the architecture of existing code — use architectural-analysis. Does not write the code — use tdd. Does not restructure existing code — use refactor. Runs its rounds without pausing for review; to review each round as it lands, use pairing.

中文简介正在准备中。当前显示原文说明。

Walks a person through code changes one step at a time in conversation, starting at the entry point and following the flow that changes, showing a small chunk per step and explaining it in plain language. Defaults to the current branch's changes, and walks the code from the perspective of any context provided instead — a file, directory, symbol, pull request, plan, or ticket. Use when someone wants to be walked through, taught, paced through, or shown around code or a branch step by step, or to learn how a change works before reviewing or extending it. Stops after every step and waits, so the learner sets the pace. Paces through code that already exists and builds nothing — to build new work while being paced through it, use pairing. Does not produce a written overview to read alone — use code-overview. Does not review code quality — use code-review. Does not diagnose bugs — use investigate.

中文简介正在准备中。当前显示原文说明。

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for planning the change its findings imply — use plan-a-change. Not for discovering bounded contexts, ubiquitous language, or where code boundaries diverge from domain boundaries — use ddd-analysis. Not for writing documentation or architectural decision records.

中文简介正在准备中。当前显示原文说明。

Break a work-items.md file (produced by /plan-work-items) into independently-grabbable Jira tickets, one per slice, in a single Jira project. Use when you want to turn a work-items file into Jira tickets, publish work items as Jira issues, or create implementation tickets that can be worked on and tracked in Jira. Requires a configured Atlassian MCP server. Does not produce the work-items file itself — use plan-work-items to break a plan into work items first. Does not post to GitHub — use work-items-to-issues for GitHub issues.

中文简介正在准备中。当前显示原文说明。

Creates or updates project documentation for a feature, system, or component and publishes it to a user-specified Confluence location. Use when the user wants feature or system documentation written to Confluence, posted to a Confluence space or page, or synced to a Confluence location. Requires a configured Atlassian MCP server. Does not document to local files only — use project-documentation for that. Does not publish an arbitrary existing markdown file — use markdown-to-confluence for that. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence for that. Does not create architectural decision records — use architectural-decision-record. Does not create coding standards — use coding-standard. Does not produce runbooks — use runbook.

中文简介正在准备中。当前显示原文说明。

Produce a plain-language manual test plan from the context supplied to it — an executive summary, a high-level list of named tests, and a detail section per test with the steps a person follows by hand and the outcomes they should expect. Use when you want to create, draft, generate, or outline a manual test plan, manual QA steps, hands-on verification steps, or an acceptance walkthrough for a feature, change, branch, plan, or PR. When the plan holds more than five tests and at least two natural categories emerge, both the test list and the detail sections are organized under plain-language categories. When nothing in the supplied context can be manually tested, it says so and asks for more context instead of producing a document. Does not analyze code for automated test coverage gaps — use automated-test-planning. Does not write test code — use tdd. Does not review code quality — use code-review. Does not stress-test an existing plan — use iterative-plan-review.

中文简介正在准备中。当前显示原文说明。

OI-3 spike harness — heavy consumer skill, BASELINE arm. Builds an incident post-mortem and sources the readability standard mid-workflow by reading a file directly, with NO Skill-tool call. Use only when explicitly invoked by the spike harness with a TRIAL_ID and data path.

中文简介正在准备中。当前显示原文说明。

Applies Han's shared Human-Readable Output Standard to a target you already have — a file on disk, text pasted into the prompt, or a draft already produced in the conversation — by dispatching the readability-editor to rewrite its prose so the main point comes first, headings are descriptive, each paragraph carries one idea, and sentences stay short and active, while preserving every fact. Use when you want to make a document or draft readable, edit or polish prose for readability, clean up writing, tighten wording, or re-apply the readability standard to something already written. Rewrites prose only, leaving code, diagrams, and citation identifiers unchanged. Does not write new feature or system documentation — use project-documentation. Does not restructure code or review it — use refactor to restructure code and code-review to audit it. Does not judge the underlying work or raise findings; it only rewrites the writing.

中文简介正在准备中。当前显示原文说明。

Surfaces Han's shared standard for explaining technical work to a reader who will not implement it into the calling skill's own context, so the caller writes its escalations, confirmation turns, and stops as a concrete outcome the reader could observe rather than as a mechanism. Use when a skill is about to ask a person a question, stop for an input, or explain a technical consequence to someone who will not open the code. Governs what a run says to a person in a turn, where readability-guidance governs the shape of a written deliverable. Runs in the caller's context and hands control straight back; it does not produce a deliverable of its own, rewrite anything, or judge the caller's work. Carries guidance only and adds no self-check step.

中文简介正在准备中。当前显示原文说明。

Produces a human-readable, progressive-disclosure overview of unfamiliar code or a pull request's changes — why it exists (the real problem it solves or goal it serves for the business or a user), and from there what it does, how it flows, and where to start — so you can get up to speed before working on or reviewing it. Use when you want to understand, get oriented in, make sense of, explain, or get up to speed on a chunk of code, a file, a directory, a symbol, or a PR's changes. Writes the overview to a scratch file and changes no code. Does not review code quality or raise findings — use code-review for auditing changes or post-code-review-to-pr for posting them. Does not produce durable feature or system documentation — use project-documentation. Does not assess architecture or structural risk — use architectural-analysis. Does not diagnose bugs or root-cause failures — use investigate. Does not pace a person through the code one step at a time in conversation — use code-walkthrough.

中文简介正在准备中。当前显示原文说明。