factory-skills

Generate a project-local verification skill that drives the real app and captures evidence for factory lifecycle gates. Use during setup-factory or when a factory has no scripted way to prove UI, CLI, or service behavior.

Research and plan one ticket, producing a local plan, dependency-ordered task files, and only the durable context or ADR updates the ticket earns. Use before implementation when a feature, bug, refactor, performance task, or investigation needs to become executable work.

Mine completed ticket evidence for reusable factory improvements, propose narrowly routed skill or tooling changes, and compare candidates against a budget-aware evaluation set before human approval. Use after meaningful factory experience, not after every routine ticket.

Adversarially review one ready-for-review ticket task in a read-only Pi subagent using a model different from the worker, then return a structured markdown findings list and a verdict. Use only for the review stage; it never edits code or applies its own findings.

Coordinate one or more tickets inside a Herdr-managed Pi sandbox using specialist subagents, isolated worktrees, atomic factory state, usage accounting, and at most three work-review rounds. Use when starting factory orchestration in this session, not for planning, implementation, or review itself. Do not apply when the user is continuing an already-supervised ticket; those prompts resume this session by ticket id.

Implement one dependency-ready ticket task in an isolated worktree using a small design sketch, behavior-first tests, the appropriate task playbook, and bounded verification. Use for the work stage after ticket planning.

Prepare an approved ticket for human submission by updating durable knowledge, summarizing scope and verification, teaching material flows with progressive visuals, and providing the merge handoff. Use only after review approval. When github.pullRequests is true, push the committed branch and create or update the pull request. It never commits or merges.

Prove a task against the real artifact before calling it done. Use during factory-work, before ready_for_review, and whenever a check only shows that code compiles or a file changed.

Scaffold a new factory once. Asks for role models, thinking levels, a ticket id pattern, pull-request permission, and triage labels, then runs fstate init to write FACTORY.json and the empty SQLite store. Use for /setup-factory, "setup factory", "initialize factory", before the first ticket, or to update those choices. Do not use during plan, work, review, or wrap-up.