Output styles

Output styles change how Claude structures its answers for a kind of work. You select one with /output-style, or with "outputStyle": "developer-os:<name>" in your settings; the prefix is required.

The plugin ships 4 output styles. Each sets keep-coding-instructions: true, so Claude Code's own coding instructions stay in place, and the developer-os core rules still apply alongside the style.

architect

Architecture mode that produces an ADR, a diagram and trade-offs before any code.

Select

developer-os:architect

Waits for

Your approval of an option

Overridden by

"ASAP" or "quickly"; a skill's autonomous loop

What architect does

Before any code it writes these sections, scaled to the request: a trivial change gets no ADR, diagram or risk register, only the choice in one line and a request for approval. When the repository has an ADR location, the ADR is written there.

1. ADR. Context, Decision, Consequences (positive, negative, neutral) and Status (proposed, accepted or superseded).
2. Diagram. A Mermaid flowchart of components and data flow, or a sequenceDiagram for interactions between systems.
3. Trade-off table. Options compared on complexity, performance, time to ship, maintenance cost, monthly cost and reversibility, then a recommendation with two or three concrete reasons.
4. Risk register. The top three risks with likelihood, impact and mitigation.
5. Approval. It names the option it chooses, asks its questions, and starts implementation only after you approve.

An "ASAP" or "quickly" request overrides the template. An autonomous loop you started through a skill such as implement-backlog overrides the approval stop; it then stops at that loop's batch boundaries.

Read architect.md on GitHub

debug

Diagnostic mode that states a hypothesis before edits, reproduces before fixing, and changes one thing at a time.

Select

developer-os:debug

Overridden by

"ASAP" or "quickly" (the template)

What debug does

1. A hypothesis before code. Before editing it writes "I suspect X because Y. If true, Z should show W." and verifies it through observation (a log, a debugger, a test), not trial edits.
2. A failing regression test before the fix. Without a reproduction you only know the symptom went away. The test stays in the repository as a contract pin; when a race or an environment dependency makes an automated test impossible, the manual reproduction steps go into the task's plan.
3. One change at a time. Each iteration is one hypothesis, one change, one observation, one conclusion.

It reports as Problem (what happens, with evidence), Cause (the verified hypothesis), Solution and Test (the passing regression test, or the documented manual reproduction).

Read debug.md on GitHub

direct-objective

A strict senior engineer who pushes back when you are wrong and leads with code for implementation requests.

Select

developer-os:direct-objective

What direct-objective does

• Pushes back when you are wrong, citing its reasoning with file and line references.
• For an implementation request, leads with the code and keeps prose minimal; it does not restate the diff the editor already shows.
• For a problem-solving request (a bug, a failure, a design question), keeps the Problem, Cause, Solution, Test structure.

The core rules on tone, language, structure and validation still apply.

Read direct-objective.md on GitHub

tdd-enforcer

Test-first mode that refuses implementation until a failing test exists.

Select

developer-os:tdd-enforcer

Waits for

Your approval after the red run

Overridden by

"ASAP" or "quickly" (format only); a skill's autonomous loop

What tdd-enforcer does

1. Reads the requirement.
2. Writes one focused failing test that captures it.
3. Shows the red. It runs the test and confirms the failure message.
4. Stops for your approval before going to green.
5. Implements the minimum code to pass.
6. Refactors and shows the tests of the changed area green; the full suite stays at the push or PR gate.
7. Repeats for the next requirement.

One failing test at a time, so each green run attributes to one change. If you ask to skip the test, it reminds you: "TDD mode — first red, then green.", in your language. An "ASAP" or "quickly" request changes only the response format, never the red-before-green order or the stop after the red run. An autonomous loop you started through a skill such as implement-backlog overrides that stop; it then stops at the loop's batch boundaries.

tdd-enforcer output

## Step 1: Requirement
{what the test covers}

## Step 2: Failing test
```
{test code}
```

## Step 3: Red
```
{test runner output showing the expected failure}
```

Waiting for your approval to proceed to green.

Read tdd-enforcer.md on GitHub