git:20261101.1d88c1c to git:20261101.aa6be0d

---

name: session-passive

description: >

The credo behavior for a session running in PASSIVE mode - you carry most of the work

alongside and the user is available only for clarifications, with no keep-alive. Load

this when the session-mode inject line says "Load skill session-passive", right after

the /credo:session-passive command, or whenever you are working mostly on your own but

the user is still reachable for questions. Shares the canonical common core defined in

the credo session-active skill, then adds the passive-mode specifics: drive items toward

a full GO, "less is more" (only ambiguous items via Ask), gently prefer older items

first. One mode is active at a time.

---

# session-passive - work alongside, user available for clarifications

A credo session runs in exactly one mode - `active`, `passive`, or `autonomous` - set by

the `/credo:session-*` commands and surfaced on every prompt by the session-mode inject

line. This skill is the umbrella for **passive** mode: you handle most of the work

yourself while the user stays reachable for clarifications, and there is no keep-alive.

## Common core (shared - read the session-active skill)

Passive mode uses the same **canonical common core** as every credo session skill. It is

defined once in the credo `session-active` skill and applies here in full - read it there.

It covers, all unchanged for passive mode:

- CLARIFY-FIRST and the go-gate (only `1_todo/2_go` is buildable) - credo `items`.

- Clarify via the Ask tool (G1); a bug report is not an immediate fix (G2).

- No pause suggestions and drive your recommendation forward - the two attended-only rules

(active and passive, NOT autonomous): never proactively suggest a pause / break, and after

giving your recommendation drive it forward (planning -> next clarify round, task -> next

GO item) instead of asking meta-permission; Ask is only for real clarify / decision / GO.

- Read-back scaled to complexity (A4); autonomous read-back on an active <-> passive

transition.

- The soft old-item reminder (gentle, on start / resume and occasionally).

- No silent rename / restructure and the consistency sweep (G6); evaluate foreign handoffs

independently (G7).

- Authority order (E5) and its scoping.

- The ntfy hybrid model (section D): immediate `high` only for come-to-PC events, progress

`personal.ntfy_topic` is empty. Send via the helper

`${CLAUDE_PLUGIN_ROOT}/scripts/credo-ntfy-send.sh "message"` (add `-t "Title"`,

`CREDO_NTFY_PRIORITY=high` as needed) - it resolves the topic/server through the cascade

internally (`credo-config.sh get personal.ntfy_topic`) and is a silent no-op when ntfy is

not configured.

- Git-push policy (G5): commit and push immediately; the commit-identity gate lives in the

credo `budget` skill; forbidden commit/push -> WARN, work not securable.

- The credo `safety` skill applies always.

- The building blocks a session ties together (`items`, `verify`, `requirements-verbatim`,

`audit`, `diag`, `orchestration`, `cross-cutting-checklist-generator`, `skill-capture`,

`budget`, `compact-plus`, `wsl-env`).

The section below only states where passive mode DIFFERS from that core.

## Output convention - item references in inline code

Item references are always written in inline-code style: `#37`, `#90`, `#91` (backticks) -

never bold or plain. This improves scannability of item numbers.

## Passive-mode specifics (A2)

Passive mode is "you drive, the user reviews". The user is present for clarifications but

is not collaborating turn-by-turn.

### Handle most of the work alongside

Carry the bulk of the work yourself. Pick up buildable items (`1_todo/2_go`) and move them

through the full Definition-of-Done gate - dedicated-subagent audit before `2_done/`,

visual verify for `ui: true` - never self-approving (credo `items` and `verify`). Delegate

substantive work to subagents per the credo `orchestration` skill so the main context

stays lean. As soon as there is idle capacity, start builders for buildable GO items (the

idle capacity rule and the limits `builders.min_per_area` / `builders.max_per_area` live in

credo `orchestration`).

### Proactively drive items toward a full GO

Push open items proactively toward being 100 percent GO: resolve what can be resolved,

research the vague, and prepare clarify-stage items (`1_todo/1_clarify`) so that a single

Ask turns them into `2_go`. Agent-owned clarify items (`clarify_owner: agent`) go to the user

through Ask like human-owned ones: passive mode decides no clarify question (common core, "Who

decides"). Only build-time details of a GO item are yours to decide, logged and named in your next

reply. Human-owned clarify items still get their GO only from the user. The aim is that when the user does engage, items are ready to

build rather than still half-specified.

### Less is more - only ambiguous items via Ask

This is the defining passive-mode rule. "Less is more" limits noise, not questions. Ask

generously, unless the answer is completely clear. Bring the clarify items to the user

through the Ask tool, one item per round, once research has settled the facts. Every clarify

decision is the user's, also on agent-owned items (common core, "Who decides"), even when it

looks obvious; the escalated questions (taste, infeasible or really not good, deletion of user

data, installs beyond the item's `## Freigaben`, money beyond an approved budget, safety, a

change to the verbatim requirement) are the user's in every case. Anything you can resolve

without deciding for the user (facts, research, build-time details of a GO item) you

resolve; you do not narrate every step or ask for confirmation on what is completely clear.

Batch and minimize interruptions - the user's attention is the scarce resource. Each item

you do bring still gets its own Ask round - see "One item per Ask round" in the common core

(session-active skill).

With the opt-in setting `dont_ask_twice` (default false) set to true, search the requirement

logs, the items, the handoff and earlier Ask answers before any question; an earlier

approval counts as the user's answer and is not asked again.

Text before an Ask call stays visible: when explanation text comes right before an Ask-tool call in

the same turn, first write that text, then make one trivial tool call (a buffer, e.g. a read of a

known file), then call the Ask tool. Without the buffer the TUI hides the text behind the Ask dialog.

### Gently prefer older items first

When choosing what to advance, gently prefer older open items over newer ones, so old

numbers get closed out. This is a soft preference, not a hard "oldest first" rule and not

a block on new work - the same gentle spirit as the common core's old-item reminder.

### Capture recurring workflows (Ask allowed)

Passive mode has the user reachable for clarifications, so the credo `skill-capture` skill

applies in its presence-mode form: when a multi-step workflow recurs about three times, and

when open candidates sit in `.credo/skill-candidates.md` at session start, propose capturing

them as a reusable skill via the Ask tool - build only on an explicit GO, never unasked.

Keep it within the "less is more" rule: bring only genuinely reusable patterns.

### No keep-alive

Passive mode does NOT keep the session awake. The `/credo:session-passive` command clears

this session's autonomy flag (`credo/autonomy/<session_id>/active`) and sets its `paused`

opt-out; other sessions are never affected. Keep-alive exists

only in autonomous mode (`/credo:session-autonomous`).

### Commit and push immediately

Per the common-core git-push policy, commit and push work as it lands.