Matt Pocock adds a software-factory Skill to the 301K-star Skills repository
Matt Pocock adds a "software-factory" design Skill to the 301K ⭐️ Skills repository; it is a glossary that requires users to invoke it explicitly (disable-model-invocation: true), used for designing remote, stateless agent software factories. Core terms include Task, Trigger, Run, Runner, and service slots such as Ticket tracker, Git host, and Orchestrator, along with four slot research documents and an example task chain. The design approach emphasizes Start slow: every trigger is an accelerator, and must be paired with three brakes—automated checks, automated review, and human review—plus a loop limit.
Body · AI translation
This Skill is not an executable pipeline; it is a glossary that users actively invoke: use a unified language to design a "remote, stateless" agent software factory—how tasks run, how service slots are filled, and how brakes are configured. The goal is to support the grilling in the course Software Factory Part Two, so that students can draw a factory on their own infrastructure rather than copying a particular product. https://t.co/AuZ2h1qrow
What the PR is adding · SKILL.md: core vocabulary + design method (disable-model-invocation: true, loaded only when the user names it) · EXAMPLE-TASKS.md: infer common task chains from problems · Four slot surveys: TICKET-TRACKERS / GIT-HOSTS / RUNNERS / OBSERVABILITY-PLATFORMS · changeset + a one-line note in in-progress/README
Core vocabulary (use only these, not the synonyms in Avoid) · Task: a class of work (review / explore / implement / ratchet), defined once and runnable many times · Trigger: the event that starts one execution (tracker / git / clock / another run) · Run: one execution of a task on a runner, treated as a black box; it never waits for a person—it just ends, and a person later changes the ticket/PR to trigger a new run · Runner: a disposable execution machine; the machine can persist, but the memory of a run stays only in the ticket tracker, git host, and orchestrator · Services slots: Ticket tracker, Ticket source, Git host, Orchestrator, Observability platform (optional)
How to design a factory 1. Start slow: every trigger is an accelerator; without brakes it becomes a "slop cannon". There are three kinds of brakes: automated checks, automated review, and human review. Add only one automatic trigger at a time, throttle first, and open up only after the brakes are trustworthy; set an upper limit on loop count. 2. Fill every slot: the table compares three starting options—all GitHub, Linear + GitHub, and self-hosted tracker. When choosing a product, read the corresponding survey. 3. Question every task: five questions—who triggers it, what it does and which services it reads and writes, what it triggers next, where a person re-enters, and how to prevent double runs; for each ticket source, also ask how to prevent duplicate ticket creation.
Example task chains (excerpt) Untriaged ticket → Explore; ready → Implementer (opens draft PR) → Automated review; failure → Rework (with an upper limit on count); large spec → Decompose; stricter checks → daily Ratchet; feedback button / monitoring → ticket source; the factory itself fails → Fix; drift → nightly Architecture; repeated mistakes → throttled Retro.
What the four survey documents do Summarize optional products by type (not a real-time catalog): six types of tracker, six types of git host, five types of runner, and four types of observability (including "add nothing"). Each statement may be outdated, and at the end there is a list of questions that "still need on-site verification".
Explicitly not doing / words deliberately dropped · Not doing: aligning the old Part Two scripts (which still use trigger / state / workflow / action) with this vocabulary; Matt has shelved this for now · Deliberately excluded from the vocabulary: state, workflow, action, job, sandbox, credential, run output; brake / accelerator are only suggestions under "Start slow", not formal terms