Stdio

Stdio — Canonical Command Patterns

Purpose. Tool output is the largest source of wasted context in a coding loop. ls -la on a 500-file directory, git log with full bodies, pytest with verbose traces on a passing run — all emit kilobytes the model will re-read and never use. This skill is the godmode-native convention for reading input terse-by-default. It is pure behavior: no binary to install, no hook to register, just 13 patterns every skill should reach for before the verbose alternative.

Scope. Governs the input side of every skill — what you pipe into context when you ask bash a question. Sibling to terse (output side) and principles (authoring side). On conflict with the Universal Protocol in SKILL.md, Protocol wins.

Activate When

• Any skill about to invoke bash to inspect repo state, tool output, container status, or test results
• The verbose form would emit > ~40 lines and you only need a slice
• You are in an autonomous loop where every emitted line is re-read by the next round's REVIEW step

Do NOT activate for: explicit debugging sessions where the user asked to see full output, unfamiliar-codebase exploration (see Hard Rules), or error investigation (always read the full trace).

The Four Layers

Godmode has four context-discipline skills, one per phase of the loop:

stdio is the first gate. Verbose input pollutes every downstream phase. Cut it at the source.

Canonical Patterns

Prefer the terse form unless the Hard Rules section says otherwise.

13 patterns. If a 14th is worth adding, it is probably worth adding as an rtk handler upstream instead — this list is intentionally small enough to memorize.

Hard Rules — When NOT to Compress

1. Errors need full stack traces. A failing test, a panicking binary, a non-zero exit — always capture the complete output. pytest --tb=line is fine on a passing run; on a failing run, re-run with --tb=long before you diagnose.
2. Writing a commit context needs git log with full bodies. --oneline loses message body and is the wrong input for anything that will quote prior commits.
3. Unfamiliar codebases need one full ls -la + one tree -L 3 up front. Terse patterns assume you already know the shape. First-contact exploration pays full freight once, then switches.
4. Security / audit skills need everything. docker ps -a with full fields, kubectl get -o yaml, ps auxf with args — these skills read fields other skills ignore.
5. Reproducibility artifacts stay verbose. Bench results, CI logs, anything that gets committed as evidence must be full-fidelity.

If Hard Rules apply, use the verbose form — it is not complexity_tax, it is required context.

Integration Contract

Every skill that invokes bash for diagnostic reads SHOULD include one line in its Hard Rules section:

N. Prefer stdio patterns per skills/stdio/SKILL.md — terse input by
   default, verbose only when Hard Rules apply.

That is the entire contract. No code change, no dispatch, no env var. A skill is compliant iff its example commands in its own SKILL.md use the terse column of the table above.

Interaction With rtk

rtk is a separate Rust binary that compresses 100+ tool outputs at the shell-hook level before they enter model context. If installed, rtk handles input compression automatically for every bash call — stdio patterns become belt-and-braces redundancy. Both are designed to coexist:

• rtk installed → shell hook compresses everything, stdio is a written convention reinforcing what rtk already does
• rtk not installed → stdio is the only compression on the input side; skills must actively choose terse forms

Neither replaces the other. rtk covers 100+ tools; stdio caps at 13 patterns every author can memorize. rtk is opt-in infrastructure; stdio is always-on discipline.

Keep / Discard Discipline

Stdio compliance feeds the Universal Protocol's discard table:

KEEP    if  skill-example uses terse form from the table
KEEP    if  skill-example uses verbose form AND a Hard Rule applies
DISCARD if  skill-example uses verbose form AND no Hard Rule applies
        → classify: unnecessary_verbosity

unnecessary_verbosity is a new failure class narrower than complexity_tax. It applies to input-side waste (verbose bash calls), not code-authoring waste. Log to .godmode/<skill>-failures.tsv with the same schema.

Success Criterion

A skill is stdio-compliant when:

1. Its SKILL.md Hard Rules reference stdio.
2. Every example bash command in its SKILL.md uses the terse form from the table, OR invokes a Hard Rule and annotates why.
3. grep -n "git log$\|cat .*\.\(py\|ts\|go\|rs\)$\|ls -la$\|pytest$\|find \.$" skills/<name>/SKILL.md returns zero lines.

Check #3 is the mechanical verifier — a one-liner a reviewer can run.

Stop Conditions

• fully_compliant — all three success criteria met
• hard_rule_documented — verbose form used, exception annotated in a comment on the same line
• unnecessary_verbosity — verbose form used with no exception; discard per Keep/Discard rules above