# What Is A Skill Chain? **Status:** First draft - full harness protocol **Foundation sequence:** Article 6 **Next:** What Is `AGENTS.md` / `CLAUDE.md`? --- ## One Skill Fixed One Thing. Then What? The audit skill worked. I covered that in the last chapter. It caught the trip-card drift before I did. It flagged two extra fields. It cited the design memory file instead of guessing. That was real progress, and I was happy with it for about a week. Then I actually used the finding. The audit skill told me what was wrong. It did not tell the next agent, the one that would touch the code and remove those fields, why they were wrong. So I re-explained it. Again. In a new prompt, in a new conversation, with no memory of the audit that had just run five minutes earlier. The skill was reusable. The reasoning behind it was not. That is the gap a single skill cannot close. A skill handles one job well. It does not know what happens before it or after it. If nothing connects the audit to the fix, and the fix to the check that confirms the fix matched the original intent, you are back to re-explaining yourself between every step. Just with better-written prompts. ## Skill vs Skill Chain vs Harness A skill is one playbook for one repeated job. The audit skill is a skill. So is a screener builder, an interview guide, a design critique pass. A skill chain is what connects several skills so the reasoning survives the handoff, along with the output. The audit skill chain does not stop at "remove two fields." It carries why those two fields broke the calm-discovery rule, so the next step checks its own work against that same rule instead of a stripped-down instruction. The Harness is the layer above both. It is the full system: the chains, the context files, the source-trust rules, the checklists, the routing rules that decide which chain runs for which task. A chain is one path through the Harness. The Harness is every path, plus the rules for choosing between them. Here is the short version: a prompt happens once, a skill happens repeatedly, a chain preserves intent across several skills, and the Harness is the system that holds all of that together. ## The Basic Chain: Research, Brief, Prototype, Review, Validation, Handoff The last chapter ended with this line: research skill produces findings, brief skill turns findings into requirements, prototype skill builds from requirements, review skill validates against the brief. That is the shape of most design chains, extended by two steps that matter just as much: 1. **Research.** Something gets audited, interviewed, or investigated. Output: findings. 2. **Brief.** Findings get turned into a scoped requirement. Output: a brief. 3. **Prototype.** The brief gets built into something concrete. Output: a screen, a flow, a draft. 4. **Review.** The prototype gets checked against the brief and against `DESIGN.md`. Output: a list of gaps or an approval. 5. **Validation.** The approved work gets checked against real sources. The brief already had its turn. Output: confirmed or flagged. 6. **Handoff.** The validated work becomes a saved artifact someone else can reuse. Output: a file, a component, a documented decision. Six steps, one thread running through all of them. If step 3 does not know what step 1 actually found, the chain is broken even if every individual skill still works. ## How Context Moves Between Steps The mechanism is simple once you see it: each skill's output becomes the next skill's required input. It is a file, not a memory of a conversation. Look back at the skill template from the last chapter. It has an "Inputs Required" section for a reason. In a chain, that section is not a wish list, it is the contract. The brief skill's inputs should include the audit skill's actual findings file, not a summary I typed from memory. The review skill's inputs should include the brief itself, not my recollection of what the brief said. This is also where a chain earns its name over a workflow diagram. A diagram shows the order. A chain shows what has to be carried, physically, from one box to the next, or the next box is working from nothing. ## Where Human Judgment Enters None of this runs on its own, and it should not. A chain tells you the order and what has to travel between steps. It does not tell you whether a finding is worth acting on, whether a brief is scoped correctly, or whether a review's objection is a real problem or a style preference. Those calls stay with the designer. The clearest place I see this is at the boundary between review and validation. Review checks a prototype against a brief someone wrote. Validation checks it against reality, real data, real sources, the actual product. A chain can force both checks to happen. It cannot decide what to do when they disagree. That decision is the Escalate verb from the Harness: when the system cannot resolve something, it surfaces the conflict to a person instead of guessing past it. ## The Harness Example: Building A Chain, Live I got a chance to build one of these end to end this week, on the Harness itself, not on a design task. Someone sent over a commercial bundle of Claude skills built for a completely different domain, UX research. The interesting part was not the research content. It was the mechanism: every skill file had a description field packed with trigger phrases, and the bundle documented seven named "workflow" chains showing which skills were meant to fire in sequence for a full research project. That is a research skill, but the shape of it is a skill chain, so it became a real research step in this project's own chain: **Research.** Read the bundle, compared its trigger-matching mechanism against this project's `routing-table.md`, found the real difference: theirs auto-activates and can be skipped, ours gates hard with "Stop If Missing." **Brief.** Decided what was worth taking and what was not: richer trigger phrases, yes. Vendor-specific auto-activation, no. Claude-specific frontmatter on our own skills, not yet, that is a Phase 3 problem and we are still in Phase 1. **Prototype.** Edited `routing-table.md` with denser trigger phrases, and wrote `docs/harness/skill-chains.md`, a new file that names and orders the chains already implied by this project's own skills. **Review.** Checked the new file against `BRAIN.md`'s five verbs and the open question already sitting in `HARNESS-ROADMAP.md` about how much of that pattern belonged here. **Validation.** Cross-referenced the new file from `docs/harness/README.md` and `docs/skills/README.md`, so it would not become an orphaned doc nobody finds. **Handoff.** Logged the decision at `docs/logs/2026-08-08-uxr-skills-bundle-review.md`, so the reasoning is saved alongside the output. Named as a chain, using the format this chapter is about to hand you, it reads like this: ```text chain:harness-improvement trigger: "improve harness", "update routing table", "update agents.md" steps: BRAIN.md -> docs/harness/README.md -> docs/harness/routing-table.md -> docs/harness/skill-chains.md -> docs/harness/failure-log.md why this order: no harness change should contradict the north star rule (BRAIN.md first). Most improvements land in routing-table.md, so it comes before the newer skill-chains.md. failure-log.md comes last because not every improvement is a caught mistake. ``` That chain now lives in the repo, in `docs/harness/skill-chains.md`, alongside two others. Nobody has to re-explain the reasoning to the next agent who touches the routing table. It is written down. ## A Reusable Skill-Chain Skeleton Start with this shape for any chain you build: ```text chain: trigger: steps: skill-1 -> skill-2 -> skill-3 why this order: ``` Fill in the trigger first. If you cannot name the phrase that should kick off this chain, the chain is not scoped yet. Then list the steps as real file names, not abstract labels. "Research skill" is a placeholder. `research-brief.md` is a chain. The "why this order" line is the part most people skip, and it is the part that matters most. If you cannot say why step two has to come after step one, they might not actually depend on each other, which means you have a list, not a chain. ## This Leads To Project Memory A chain still needs somewhere to live. Somewhere an agent reads it before starting work, not somewhere a designer has to remember to mention. That somewhere is project memory: `AGENTS.md` for Codex-style agents, `CLAUDE.md` for Claude Code. The routing table that decides which chain applies to which task lives inside that memory. Without it, the best-designed chain in the world is just a file nobody opens. That is the next chapter. --- ## What You Learned A skill handles one job. A skill chain connects several skills so the reasoning survives the handoff between them, along with the output. The basic shape is research, brief, prototype, review, validation, handoff, and what moves between each step is a real input, not a memory of what happened last time. Human judgment still decides what to do when a review and a validation disagree. This project's own harness-improvement chain, built and logged the same week this chapter was written, is proof the pattern works outside of Planark too. **Next:** What Is `AGENTS.md` / `CLAUDE.md`?