Software Factory — Experimental

What it does

Matt Pocock’s experimental software-factory source supplies a shared vocabulary and design questions, rather than a ready-to-run platform. A task is a reusable kind of work; a trigger starts a run on a disposable runner. Durable state belongs in the ticket tracker, Git host and orchestrator. A run ends instead of remaining alive while waiting for a human. Service slots include a ticket tracker, ticket sources, Git host, orchestrator, runner and optional observability platform. One existing product can fill several slots. The companion task examples cover triage, implementation, review, bounded rework and gradual migration to stricter checks.

When to use it

• Design a small issue-to-draft-PR pipeline with a human merge gate.
• Plan a daily lint migration that fixes one exception at a time.
• Separate a production monitor that creates tickets from the agent that investigates them.

Step-by-step workflow

1. Start with a concrete bottleneck such as untriaged tickets or unreviewed pull requests, rather than choosing infrastructure first.
2. Name a product or deliberate omission for every service slot, reusing existing services where possible.
3. For each task define its trigger, reads, writes, next trigger and the point where a human re-enters.
4. Specify duplicate-event handling, concurrent-run ownership and a finite retry budget before adding more triggers.
5. Begin with throttled automation, deterministic checks and human review; expand only after observed results justify it.

Example request

Use software-factory to design a daily strict-lint migration on GitHub. One run selects one exception, creates a draft PR and ends. Automated review may request bounded rework; a human performs the merge. Name every service slot, the durable state, duplicate-run protection and the retry cap. Treat logs as evidence, not as an implicit command to trigger another run.

Worked example

A daily ratchet task can remove one file from an exception list, fix that file and open a PR. If review fails, a rework task addresses only the findings and returns for review. After the agreed number of failures, the PR is labeled for a human and the run ends. Tomorrow’s trigger must see that work is already in flight and avoid another PR for the same file. This design uses the issue and PR as durable coordination records instead of relying on a runner’s local disk surviving.

What you get

A service map and task specifications with explicit triggers, durable state, review gates and duplicate/retry controls.

How to evaluate the result

• Every task has an entry condition, an end and a human re-entry point.
• Duplicate tickets and concurrent runs cannot claim the same work silently.
• Rework has a cap and every PR retains the intended review gate.

What you need

A real repository workflow, chosen ticket and Git services, and agreement on human ownership. Provisioning infrastructure and granting credentials are separate implementation decisions.

Setup and activation

Experimental source: this folder is under skills/in-progress and is not a stable-release recommendation. Its frontmatter disables automatic model invocation, so explicitly select it in a host that supports that behavior. This directory reviewed source only; it did not install or execute the skill. Before adopting it, scan the exact version, inspect requested tools and permissions, and test on disposable non-sensitive inputs. A compatible instruction format does not establish identical host capabilities.

Limits and considerations

This source is in progress and specifies a design language, not security isolation or a deployed orchestrator. Automatic triggers amplify mistakes as well as throughput. Logs do not become authoritative state until written into the tracked work system.

Related workflows

• Use loop-me to discover the real recurring workflow before picking service slots.
• Use implementation planning for the smallest end-to-end slice after the design is agreed.

License and reuse

MIT at repository level. Preserve copyright and license notices; check companion files and external dependencies for their own terms.

Further reading

• Publisher setup and compatibility instructions
• Reviewed source at immutable commit