The Worked Example

Everything up to here has been the method as it ships. This is one project's answers.

9.1 The automation we are building

A pipeline that watches a set of source websites you choose, has an AI agent write a complete article from what it finds, and files that article on your WordPress site — with as little manual work as possible, and with one deliberate exception to "as little as possible."

FIGURE W1 — What gets built: source sites to a draft awaiting approval. Each box is a job the system does, not a component. How each one is built is decided at the design stage, and by the coding agent rather than by this document.

On the one deliberate exception. The brief for this pipeline asked for articles to publish "straight to WordPress." The design above files them as drafts instead, and a person approves each one before it is public. This is a change from the brief and it is the right one: it is what makes the whole thing defensible to an editor rather than something done to them. If you want fully autonomous publication, it is one decision to reverse — but it should be reversed knowingly, in the specification, rather than by omission.

Note — the companion section Spec-Driven Development with spec-kit walks the same specification through a different method, and AI-Native Content Automation Pipeline implements it on a visual workflow platform. Reading them alongside this one is the point rather than a distraction: the same three user stories and the same article contract produced three different builds, because the technology is chosen late and everything above that point is unaffected by the choice. This section covers the method that keeps the specification true afterwards; the others cover the design and the implementation in depth.

9.2 The four questions, settled before anything was written

The brief was a paragraph. Four things in it were genuinely ambiguous, and guessing at any of them would have produced a plausible system that was wrong.

You: /opsx:explore

AI:  What would you like to explore?

You: We want an automation that watches some industry sites, drafts an
     article from what it finds, and puts it on our WordPress site for
     an editor to review. I'm not sure how to scope it.

AI:  Four things are underspecified and they change the shape of the
     build. Let me take them one at a time.

     1. One article per run, or one per item found?
     2. What makes an item one we have already seen?
     3. Should anything ever publish automatically?
     4. How often does it run?

The answers, and the reasoning that went with each:

Notice what /opsx:explore produced: no files. It reads, it asks, it argues, and it stops. Four decisions were settled in a conversation that cost nothing to have and would have cost a rebuild to discover later.

Those four are decisions three, five, six and two in the register, recorded there so you can disagree with them on the record.

9.3 The proposal

You: /opsx:propose add-content-pipeline

FIGURE W2 — The same four boxes, now filled in for this project. Nothing about the sequence changes. Only the content of each box is specific to the publishing pipeline.

Comes back: openspec/changes/add-content-pipeline/proposal.md. Abridged:

## Why

Editorial staff miss items because nobody remembers to check six sites
every morning, and writing an article from scratch is slower than
correcting a draft. Both problems are mechanical rather than editorial,
and both are recoverable by a person if the machine gets one wrong.

## What Changes

- Watch a configured set of source sites on a fixed schedule
- Collect items published since the previous run, and only those
- Discard anything already seen in an earlier run
- Draft one synthesised article per run, with its sources attached
- File it to WordPress as a Draft — never published automatically
- Notify a person when a run fails

## Capabilities

### New Capabilities
- `source-collection`: find new items at each source; discard ones
  already seen in an earlier run
- `article-drafting`: produce one synthesised article that satisfies
  the article contract
- `draft-publishing`: create the article in WordPress, unpublished
- `run-notification`: tell a person when a run fails

### Modified Capabilities
(none — nothing exists yet to modify)

## Impact

- New service on the client's existing Linux host
- One new WordPress service account, Author role
- No change to any existing system

Read the ## Capabilities section again. It is not a summary — it is a contract. Each capability named there obliges exactly one delta specification file, and that binding is traced through in the next page.

And read ## Why for what is absent. No platform, no language, no model, no mention of RSS. Naming a technology in a proposal is the most common way to get a bad specification, because it settles the how before anyone has agreed the what. The technology arrives at the design stage, proposed and defended by the coding agent.

9.4 What landed on disk

FIGURE W3 — What /opsx:propose actually left on disk. One folder. Everything about this piece of work is inside it, and every file in it is plain Markdown or YAML.

Four artifacts, four capability specifications, and one small metadata file. openspec status reports all four artifacts done and the apply step ready — which is the state you want to be in before anybody writes code, and the state a reviewer is being asked to sign off.

At this point nothing has been built, nothing has been deployed, and no credential has been created. What exists is a plan in English that a person can disagree with cheaply.