This page is the map of which Han skills chain together. Most real work runs several skills in sequence, where one skill's output becomes the next one's input. This page shows the common chains, with a flow diagram wherever a chain branches enough that a picture beats the prose.
It is one of four navigation surfaces, and each has a distinct job:
- This page (Workflows) is the map of which skills chain together.
- Quickstart gives you do-this-now paths for five common situations.
- How-to guides walk a single task end to end, step by step.
- Concepts explains the skill-and-agent model the whole suite is built on.
If you know the task but not the sequence, you are in the right place. If you want the model behind the skills, read Concepts first.
The planning skills feed the coding and delivery skills. This is the longest chain in the suite, and it branches at several points depending on what you already know and where the work is tracked.
flowchart TD
triage["/issue-triage"] --> research["/research"]
triage --> investigate["/investigate"]
research --> feature["/plan-a-feature"]
feature --> impl["/plan-implementation"]
impl --> review["/iterative-plan-review"]
review --> items["/plan-work-items"]
impl --> items
items --> gh["/work-items-to-issues (GitHub)"]
items --> jira["/work-items-to-jira (Jira)"]
items --> linear["/work-items-to-linear (Linear)"]
gh --> build["/tdd"]
jira --> build
linear --> build
pairing["/pairing"] -.drives.-> impl
pairing -.drives.-> review
pairing -.drives.-> build
/issue-triage→/investigate. When a report is vague, triage it first, then investigate the root cause./issue-triage→/research→/plan-a-feature. When triage finds a problem-space unknown, research the options first, then specify the chosen one./plan-a-feature→/plan-implementation→/iterative-plan-review→/plan-work-items. Specify, plan the build, stress-test the plan, then break it into work. Skip the review pass when the plan is already trusted./plan-work-items→ publish. Turn the work items into tickets where your team tracks them:/work-items-to-issuesfor GitHub,/work-items-to-jirafor Jira (opt-inhan-atlassian), or/work-items-to-linearfor Linear (opt-inhan-linear)./pairingdrives/plan-implementationand/iterative-plan-review. Both run their rounds without pausing today, so this is where the wrapper changes the most: you see each round as it closes rather than only the finished plan.
When you have two artifacts to compare (a spec against an implementation, a PRD against a shipped feature), start from the gap report and route its findings into planning.
flowchart TD
gap["/gap-analysis"] --> impl["/plan-implementation"]
gap --> phased["/plan-a-phased-build"]
phased --> impl
/gap-analysis→/plan-implementation. The gap report'sG-NNNIDs become work in the implementation plan./gap-analysis→/plan-a-phased-build→/plan-implementation. Order theG-NNNIDs into vertical slices first, then give each greenlit phase its own implementation plan.
The review, refactor, and build skills chain in both directions: a review can feed a refactor, and a refactor can prepare the ground for a test-first build.
flowchart TD
review["/code-review"] --> refactor["/refactor"]
arch["/architectural-analysis"] --> refactor
arch --> design["/design-an-api"]
design --> tdd["/tdd"]
review --> pr["/post-code-review-to-pr"]
refactor --> tdd
tdd --> prdesc["/update-pr-description"]
investigate["/investigate"] --> iterate["/iterative-plan-review"]
pairing["/pairing"] -.drives.-> refactor
pairing -.drives.-> tdd
pairing -.drives.-> design
/code-review→/post-code-review-to-pr. Review locally, then post the review to the PR./code-reviewor/architectural-analysis→/refactor. The review's structural findings become the refactoring plan's work orders./refactor→/tdd. Preparatory refactoring makes the change easy, then/tddmakes the easy change./architectural-analysis→/design-an-api→/tdd. Judge the structure you are designing into, shape the contract against one stated goal, then implement it test-first. The analysis step is optional;/design-an-apiruns its own discovery wave when you start there./investigate→/iterative-plan-review. Root-cause the bug, then stress-test the proposed fix./tdd→/update-pr-description. Once the branch carries the change, turn its commits into the PR body. This is the description half of the PR;/post-code-review-to-pris the review half, and the two are independent./pairingdrives/refactor,/tdd, and/design-an-api. This is not a chain but a wrapper:/pairingruns one of them and takes control back at each unit boundary, so you review as the work lands rather than at the end. Invoking any of the three directly runs it straight through, unchanged.
Two skills plan tests, and they split on who runs them. Both take the same kinds of input (a branch, a feature, a plan, a PR), so pick by the audience rather than by the stage.
flowchart TD
auto["/automated-test-planning"] --> tdd["/tdd"]
manual["/manual-test-planning"]
/automated-test-planning→/tdd. Find the coverage gaps and edge cases first, then implement the tests test-first. The plan names what to write;/tddwrites it./manual-test-planning. The sibling for steps a person runs by hand, as an acceptance walkthrough or a QA pass. It ends at the document, because nothing downstream automates it.
These chains are linear, so they need no diagram.
/project-discovery→/project-documentation→/coding-standard. Discover the project, document it, then capture its conventions as standards./code-overview→/code-review. Get oriented in unfamiliar code or a PR first, then judge whether it is any good./code-walkthrough→/code-review. The same chain when you want to be taught rather than handed a document: walk the change one step at a time, asking questions as you go, then review it. Reach for/code-overviewinstead when you want one artifact you can keep, share, or paste into a PR description./project-documentation→ the specialized documents. Feature and system docs live in/project-documentation, but three kinds of writing route elsewhere: a decision and its rejected alternatives go to/architectural-decision-record, an operational scenario someone gets paged for goes to/runbook, and an enforceable convention goes to/coding-standard.
A specification is written for the people who will build the thing. These two skills turn it into something for the people who are funding or approving it.
flowchart TD
feature["/plan-a-feature"] --> summary["/stakeholder-summary"]
summary --> html["/html-summary"]
/plan-a-feature→/stakeholder-summary→/html-summary. Specify the feature, restate it in plain language for stakeholders, then render that summary as a single self-contained HTML file you can send to someone./edit-for-readability. The polish pass for any of it. Point it at a document any other skill produced, or at a draft in the conversation, and it rewrites the prose against the shared readability standard without changing a fact.
- Repo root. The Han suite landing page.
- Skills index. Every skill, with a scent line and a link to its long-form doc.
- Agents index. Every agent the skills dispatch.
- Plugin index. Every plugin and which one to install.
- Quickstart, How-to guides, Concepts. The other three navigation surfaces.