How skills hand work to each other

Every skill can be used on its own. This page explains the real connections between skills: what one skill produces that another can use, and who decides when the next skill starts. It does not describe a required lifecycle; use one skill when that is enough.

You start the next skill

A skill that finishes ends with at most one suggested next step, written as a ready-to-run prompt. Only your yes starts it. You run a step for charter, diagnose, or ticket yourself, because those skills start only when you invoke them. A handoff makes the next step possible; it never starts it.

Handoffs live in ignored folders

A skill that hands work to another seals it in its own folder under .first-four-hours/ at the repository root. The skill adds a rule for that folder to the worktree-local .git/info/exclude, so Git ignores it without a committed .gitignore entry. A skill stops instead of writing when its folder is already tracked by Git, or when that folder or .first-four-hours/ is a link or not a directory.

Scribe keeps its audit report the same way, in .first-four-hours/scribes/<slug>/scribe-audit.md. Its support bundle is a temporary file outside the repository.

Charter's charter.md is not sealed: it is a living definition revised in place, and the project's authority until Charter publishes it as a GitHub issue. After a verified publication the issue owns the definition and the file points to it.

Deliverables you asked for are not handoffs and stay committable: Scribe's documents, Ticket's local work-item store, and the Learning skills' files under .learning/<subject>/. Construct and Reason write no artifact, and PR writes its draft outside the repository.

Project definition

Charter settles what a whole project is for before any tickets exist. Ticket persist can split a ready charter into tickets: from a published charter it reuses the umbrella issue as the epic, and from a local-only charter it takes the file as its authority. Charter never splits the work itself, and you decide whether to start Ticket.

Planning and execution

Blueprint owns every planning decision; Construct owns carrying them out. Construct may fix its own coding mistakes inside a valid plan, but when the plan is stale, wrong, or incomplete against the actual code it stops with plan-contradiction instead of redesigning. The fix is a new Blueprint run in a fresh task folder, followed by a fresh Construct run. Review findings from Assess go the same way, so the planner keeps every decision.

Inputs to planning

Four skills produce work that Blueprint can plan from, and you decide whether to start it:

• Diagnose finds causes. Name one finding when you ask Blueprint to plan a fix, or ask Architect first when that fix needs a structural decision. Diagnose's advisory directions are leads, not a chosen design.
• Architect decides structure. Blueprint plans around that decision instead of reopening it.
• Ticket select narrows one ready ticket into a plan-ready scope.
• Assess reviews a change. When its result is findings, Blueprint plans the repair from the sealed assessment.md: every finding, or only the ones you name.

Inside a Blueprint run

Blueprint brings in other help within its own run, not as separate stages:

• It asks Ideate for options only when no viable solution is apparent or the evidence cannot rank the directions. You make the final selection unless you already chose or delegated it.
• Blueprint attacks its own draft before sealing. A risky plan also gets one separate fresh-context challenger, and without one Blueprint does not seal that plan.

Reason checkpoints

Architect, Assess, Blueprint, Charter, Diagnose, Ticket, Ideate, Scribe, Tutor, and Examiner consult Reason at their own judgment points, such as before committing to an approach, after a failure, and before presenting a result. These consultations happen inside the owning skill and leave no file; they are not steps you run. You can also start Reason yourself.

Routing

Router writes a route of concrete skills, never domains, as far as the next steps are known, and stops where a step depends on a result that does not exist yet. It runs none of them. When the route runs out, the target may still need a fresh route.

Review and pull requests

Assess is read-only and grants no approval or merge authority; it posts its findings to a pull request only after you confirm the exact comment. PR opens a pull request, or updates its description, only after you confirm its exact text, and never merges. Every commit and merge stays yours.

Learning

Tutor and Examiner each work alone; moving between them is optional. When both are used for a subject they share one study plan, .learning/<subject>/study-plan.html: Tutor owns the learning sequence, and Examiner owns the examination section. Tutor records the gaps Examiner's marking diagnoses, and Examiner reads the open Unresolved items in Tutor's lessons when recommending topics. For an examination goal, each Tutor topic's name starts with its syllabus area. Each section says what it shows: Tutor's progress shows understanding, and Examiner's coverage shows examination performance. Where they disagree on an area, each notes it in its own section and the next step follows the coverage. When either changes its schedule and the sessions no longer fit, it says so and offers choices instead of changing the other's section.