smithering is an archived example, not installed by init: copy it from examples/init-pack/ with its dependency closure, or ask create-workflow to build an equivalent.
smithering is the “replace the human operator” meta-workflow: describe what
you want and it decides how much process the request deserves, then runs it end to
end. You never type CLI commands: your operating agent runs smithers for you,
answers the workflow’s HumanTasks, and clears approval gates after checking with you.
prompt is omitted, the workflow opens with a setup interview (a HumanTask)
that collects the request first.
Tiers
After setup, the request is classified (or forced withroute) into one of
three tiers; only the matching path spends real work:
- trivial: a fast agent just does it, then verifies, evidences, and reports.
- complex: an autonomous coder drives it to completion.
- full-build: the entire pipeline below, for work that needs a spec, a design, tickets, and a generated implementation workflow.
route to trivial, complex, or full-build to skip the classifier, or
leave it auto to let the workflow decide.
Stages (full-build)
- setup / route: collect the request (HumanTask if no
prompt) and pick the tier. - preflight + intake: check the repo and frame the problem.
- brainstorm: widen the solution space before committing.
- research + questions: study the domain and prior art, then ask blocking product questions (HumanTask; auto-adopts recommendations when autonomous).
- PRD: write the product spec and pause at
gate:prd. - design: draft and review a design doc in a loop, then finalize it.
- eng doc: draft and review the engineering plan, then pause at
gate:eng. - backpressure: map every success criterion to a verification gate.
- probes: run third-party assumption probes and stop at
gate:probes. - tickets: break the work into ordered tickets.
- orchestration: design and scaffold a real implementation workflow (plus an optional POC when
pocis set). - validate: verify, review, fix blocking issues, and smoke-test the generated workflow before launch.
- launch + monitor: clear
gate:launch, run the implementation workflow, and monitor it in a loop that polls, reports, and triages. - review: independent reviews from multiple agents, synthesized into one verdict.
- polish: a scan, fix, and verify pass over the result.
- deliver: gather an evidence report and hand off at
gate:delivery.
Full-build merge policy
The generated implementation workflow lands ticket branches only onto the integration branch. The independent verifier is the authoritative pre-merge signal:verify.json.pass
must be true after rebasing the ticket onto the current integration tip. Cross-family
review.json findings are advisory, not a landing veto; safety/security
tickets also require an approved adversarial challenge.json.
Landing is continuous and per-ticket, not a per-wave barrier. Topological waves can still
order tickets, but a ticket enters the serialized merge queue as soon as its
verifier/challenge is green and its dependsOn tickets have landed. A blocked
ticket only blocks its transitive dependents; unrelated siblings keep building and landing.
If a conflict, typecheck, or test failure appears only on the merged integration tip, it
feeds back to that ticket’s implementer loop and retries up to its iteration budget
instead of permanently blocking dependents. Fresh runs are idempotent: tickets whose land
commits already appear in git log <base>..integration are treated as done and skipped.
Inputs
With
review: false the workflow runs without stopping: every approval gate
auto-passes and every product question auto-adopts its recommended answer.
Monitor it
smithering to hand off a whole piece of work end to end, from a
one-line ask to a full build, pausing for approval only where it matters.