Campaign delivery

How work gets from a request to a release, in a product that is changed continuously by people who keep asking for things.

This is one process, not the process. It suits a specific situation and fails outside it. Before applying any of it to a project that has not already adopted it, read Does this fit — and if the project has adopted it, its own meta/ note records the choices it made, which this file does not know.

Load alongside

This skill owns the process and nothing else. Where it needs a note written, wiki-docs says how.

Does this fit

All five, or do not adopt it:

1. A long-lived product, changed over years — not a fixed-scope build with an end date.
2. Requests arrive continuously from identifiable people who expect an answer. A backlog the team wrote for itself is not this.
3. A wiki somebody actually writes in.
4. A tracker that is not authoritative for intent. It may hold stories and releases; if it also holds the roadmap and the plan of record, this process fights it and loses.
5. Someone with the authority to close a campaign on judgment — and to say out loud that a direction failed.

Any one of these disqualifies it:

• Work against a signed specification with fixed scope. Scope moving until close is the core mechanic here, and a contract that forbids it forbids the process.
• A library or internal tool with no stakeholder stream. There is nobody to refine for, and the feature inventory degenerates into a table of contents.
• Dates committed above the release. This deliberately produces no dates and no sizes on the intent axis; a project that must forecast a year out will fill the gap with fiction.

The parts are load-bearing on each other, so half-adopting is worse than not adopting. Campaigns without the write disciplines give you a frozen record nobody can read. Refinement without the enlist gate gives you a tracker full of empty containers. If only part of it fits, take the vocabulary and none of the rules.

Who owns what

The eight choices a project makes are listed in adoption.md. That list is closed. A project that needs to change something outside it has either found a gap in the model — say so, and it changes here for every project — or it is forking, and it stops claiming to run this process.

A meta/ note restating the model is not a second authority, it is a stale copy. It was written against some earlier version of this file, nothing updates it, and the next agent reads it as local law. Delete it and leave a pointer. Changing a choice is the opposite: that is the project's, and yours to ask about rather than edit.

Refer, never quote. Point at this skill by name and section heading, so the reference survives an edit inside that section.

The model

Feature and campaign are different kinds of noun

Neither contains the other, and the proof is that the relation runs many-to-many in both directions: a campaign spans several features, a feature is changed by many campaigns over its life.

The consequence that gets broken most often: a feature is never planned, scheduled, sized or completed. Campaigns are. A feature is the place work lands.

The four axes

The empty cell is deliberate. Intent is the only axis where being wrong is free, because it never claimed to record anything. Everything else records something that happened, which is why nothing load-bearing may hang off the roadmap.

None of the four is a level of another. The recurring planning failure is forcing them into one hierarchy — a chain from theme down to story that nothing in reality obeys.

The three coordinates

Every unit of change — a story, a ticket, a commit — carries three:

Why is the optional one, and its absence carries meaning. Work below the size of a campaign — a routine fix, a data correction — carries none, and no campaign means routine. That makes the run-the-business share of throughput a query rather than an annual guess. See tracker.md.

The three write disciplines

Three kinds of note, differing by what you are allowed to do to the file — which is what an agent most needs to know before touching one. Default directory names shown; this project's names are in its meta/ note.

Nothing in the scratch area may be cited. Everything there might not be true. That line is what stops unshaped material being quoted as fact, and it is stronger than permanent-versus-transient.

Unversioned throughout: no -v2.md, no archive copies. Git owns history.

The tense test

A campaign note and a feature note describe the same work in two tenses, and the tense decides which file a sentence goes in:

The same fact living on both sides is correct: the campaign's copy is dated and says why, the living copy is current and says what. A campaign note written in the present tense about the product is misfiled, and the misfiling matters because the campaign will freeze and take the description with it.

Where to go next

The five that get broken

Load-bearing, and each one fails silently:

1. Nothing enters the tracker before it is enlisted into a campaign — tracker.md.
2. Nothing outside the scratch area may cite a campaign before its first enlistment, because until then there is no stable name — campaigns.md.
3. A captured request is never edited. Changes go beside it, dated — intake.md.
4. Durable statements are written out to the living notes in the same change that makes them true, never in a lump at the end, never promoted — features.md.
5. A campaign closes on judgment, not on completed scope, and not until its write-out list checks out — campaigns.md.