Software Development

Who this is for

A live product session where the people using the software and the people changing it are in the same room, and changes are made during the session rather than written down for later.

The failure this profile addresses is specific. Someone drives the product, spots a problem, and describes it. A developer is mid-prompt on the previous item and hears half of it. Nobody says who is taking it. Two people start on the same thing, or nobody does, and the room finds out twenty minutes later.

Call types

UX is separated from Bug deliberately. Filing a design problem as a defect leads to it being scoped as a repair and closed once the code matches the original intent — which was the problem.

Approval

This profile requires none. The developer who owns a task closes it themselves. Software development has no licensing board designating who may accept a change, and inventing one here would be a rule this Standard has no standing to make.

What protects against a developer waving through their own work is not a second approver — it is the verify state below. The Caller has to exercise the change and say it works before it can be closed Accepted.

Code review and merge sit outside this loop entirely. They are a separate quality gate governed by the team's own process. A change can be closed Accepted in the session and still fail review afterwards; that produces a new CALL, not a reopening of the closed task.

Additional required state: Verify

This profile adds one REQUIRED state after RETURN:

verify — The Owner asks the Caller to exercise the changed behaviour live. The Caller states whether it now works.

A change the Caller has not exercised MUST NOT be closed Accepted. "It should work now" is not a disposition.

Worked examples

Worked examples for this profile are published as data in examples/transcripts/, so the dialogue exists in exactly one place and the repository validator checks that every spoken cue still matches the vocabulary this profile declares.

• The page jumps when you switch tabs — a live triage session. The clarify is not a claim, the claim carries a restatement, and the change is not closed Accepted until the caller has exercised it himself.

They render at co-prompting.com/examples.

Vocabulary

The shared vocabulary — Heard, Hold, Clarify, Mine, Prompting, Add, In, Preliminary, Parked, Pass, and the rest — lives in the core specification, Section 7. It is the same in every domain, and several of those cues are MUST-level because they carry an invariant rather than a convention.

This profile uses the default phrasing for every cue. It declares no dialect: software teams already say "Heard", "Mine", and "Prompting", so there is nothing to substitute.

Read the registry once at spec/core.md §7.1. This page covers only what is specific to software work.

Notes on vocabulary

Do not use Issue as a call type. It collides with issue trackers and is ambiguous between Bug and Feature.

Do not use Ticket. It names an artefact rather than a kind of problem, and it presumes the work will be deferred — which is the habit this Standard exists to break.

A participant continuing their own agent on unrelated work is not making a Call and does not enter the loop. The loop begins only when a call type is uttered.

Retention

The record should point at the resulting change request, commit, or ticket where one exists, so the session can be reconciled against the repository afterwards.