software-factory

Use it when:: You're designing a software factory: a system of agents that turns tickets, PRs and schedules into merged code.
It does:: Fixes one vocabulary for the design, such as task, run, runner and orchestrator, and names the canonical term when you use another word.
You get:: A design, in the conversation: a product picked for each service, and each task's answers to five questions, from what triggers it to what stops duplicate work.
Unlike domain-modeling:: That one builds your project's own glossary as you go; this one brings a fixed vocabulary for one kind of system.
Runs:: Only when you invoke it; its author marks it in progress, so expect changes.

TL;DR

A software factory is a system of agents that turns tickets, PRs and schedules into merged code, on infrastructure you choose. This skill gives you and the agent one set of terms for designing one. A task is a kind of work defined once, such as review or implement; a run is one execution of it, started by a trigger such as a ticket change or a clock, on a runner, a disposable machine. Around them sit the services: the ticket tracker, which is also how humans talk to the factory, the git host, the orchestrator that starts and tracks runs, and an optional observability platform. It advises starting slow: one throttled trigger at a time, braked by automated checks, automated review and human review. A design is done when you've picked a product for every service and every task says what triggers it, what it does, what it triggers next, where a human steps back in, and what stops two runs doing the same work. To help you choose, it comes with example tasks, grouped by the problem they solve, such as untriaged tickets, and a survey of the products for each service.

Summarizes the skill at 4ae2317.

npx skills add https://github.com/mattpocock/skills --skill software-factory

skills.sh page Source on GitHub All skills from mattpocock/skills

Total Downloads: 1 on skills.sh, Nov 9, 2026
Repo stars: 318,714 mattpocock/skills
First seen: Nov 1, 2026 on skills.sh

Weekly Downloads

Week to Nov 9

Weekly values

Week to	Installs
Sep 21	0
Sep 28	0
Oct 5	0
Oct 12	0
Oct 19	0
Oct 26	0
Nov 2	1
Nov 9	0

Category	category:agents category:software-engineering Build agents, orchestrate workers and give agents memory. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:guidelines Knowledge and rules the agent applies while it works: best practices, design principles, API references.
Effect	effect:none Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code.
Needs	needs:none Instructions only. Works in any agent that supports skills.
Publisher	by:community Everyone else. Unverified vendor claims default to community.
Topics	agent-workflows multi-agent architecture issue-tracking

SKILL.md

From mattpocock/skills at 4ae2317. Checked daily, last changed Nov 9, 2026.

Frontmatter

name: software-factory
description: Shared language for designing a software factory: the tasks it runs and the services it plugs into.
disable-model-invocation: true

A software factory is a system of agents that turns tickets, PRs and schedules into merged code, deployed on remote infrastructure the user chooses. This skill is the language for designing one. Use these terms, and only these, when discussing or whiteboarding a factory; when the user reaches for a word under Avoid, name the canonical term.

Tasks and runs

Task: A kind of work the factory performs, defined once and run many times: review, explore, implement, ratchet. A task may work on a ticket, a PR, or the codebase as a whole. Avoid: job, workflow, action

Trigger: The event that starts a run: a change in the ticket tracker or git host, a clock in the orchestrator, or another run.

Run: One execution of a task on one runner, from its trigger to its finish, treated as a black box. A run triggers further runs either directly, through logic in the orchestrator, or by changing the ticket tracker or git host. A run never waits for a human: it ends, and the human's later change to the ticket tracker or git host triggers a new run. Avoid: session

Runner: The disposable machine a run executes on. Nothing on it survives the run, even when the machine itself is long-lived: a run's only memory of earlier runs is the ticket tracker, the git host and the orchestrator. Avoid: server, host, box, compute, sandbox

Services

Ticket tracker: Where tickets live, and the factory's human interface: humans schedule work by filing tickets, talk to agents in their comments, and their changes to tickets trigger runs. Avoid: issue tracker, ticket manager, project board

Ticket source: Anything outside the factory that creates tickets in the ticket tracker: a feedback button, a monitor, an error tracker, an inbox. Avoid: data source, trigger source, intake

Git host: Where branches, PRs and reviews live. Avoid: code host, forge, repo

Orchestrator: The component that receives triggers, starts runs on runners, and records which runs are queued, in flight or finished. Avoid: dispatcher, scheduler, control plane

Observability platform: Where runners send logs, traces and status, so a human can see what happened inside each run. Optional: the product filling the runner or orchestrator slot often shows enough on its own. A run never decides on it until something writes it into the ticket tracker or git host. Avoid: observability, logs, monitoring, dashboard

Designing a factory

A design has two halves: the services, each a slot filled with a product, and the tasks whose runs move work through them.

Start from the user's problem, not the factory: untriaged tickets, PRs waiting for automated review, a stricter automated check to migrate to, bugs nobody reads. When the user names a problem or doesn't know what to build, read EXAMPLE-TASKS.md for the tasks that solve common ones.

Start slow

Every trigger is an accelerator. Accelerators without brakes make a slop cannon. There are three brakes:

Automated checks: deterministic gates (types, lint, tests) that every run must pass.
Automated review: a separate run that reads the diff cold against the codebase's standards and the ticket, when there is one.
Human review: a human reads the PR before it merges; what it catches becomes new automated checks and sharper automated review.

Add one automated trigger at a time, throttled at first (one bug report in ten, a clock once a day), with human review on every PR. Open the throttle as the brakes earn trust, and cap every loop of runs at a few tries before a human.

Fill every slot

Each service is a slot. One product can fill several slots, and one server can host several services. Three designs, side by side:

Service	All on GitHub	Linear tickets	Own tracker
Ticket tracker	GitHub Issues	Linear	own app
Ticket source	feedback button	feedback button, monitor	feedback button, monitor
Git host	GitHub	GitHub	GitHub
Orchestrator	GitHub Actions	own server + database	own app
Runner	Actions runner	Actions, E2B, Daytona or a VPS	own app, or sandboxes
Observability platform	none: Actions run pages suffice	an LLM tracing platform	own app

When the user is choosing a product for a slot, read that slot's survey to get oriented, then research the current options yourself; each survey groups the options by type and lists the questions that decide the slot:

Buy the services and build the tasks: the tasks carry the user's design, the services are generic. Favour an off-the-shelf ticket tracker: it is robust, people already know it, and outside users are easy to let in.

Question every task

For each task, answer:

What triggers it?
What does it do, and which services does it read and write?
What does it trigger next?
Where does a human re-enter?
What stops two runs doing the same work?

For each ticket source, answer: what stops it filing the same ticket twice?

A design is finished when every slot names a product (or, for the observability platform, a deliberate none) and every task and ticket source has an answer to every question.