Workflows

July 30, 2026 · View on GitHub

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.

From a problem to a shipped change

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

From a gap to a 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

Working in code

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
    review --> pr["/post-code-review-to-pr"]
    refactor --> tdd["/tdd"]
    tdd --> prdesc["/update-pr-description"]
    investigate["/investigate"] --> iterate["/iterative-plan-review"]

Planning the tests

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; /tdd writes 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.

Understanding and documenting a codebase

These chains are linear, so they need no diagram.

Sharing the work with a non-technical reader

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.