Menu
House rules for code comments: explain why a line exists, cite external constraints, delete narration. Use when writing or reviewing inline comments.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | inline-comments |
| description | House rules for code comments: explain why a line exists, cite external constraints, delete narration. Use when writing or reviewing inline comments. |
Comments explain why a line exists, which failure it prevents, or which external constraint pins the choice. They should add information the syntax cannot recover. Delete comments that narrate the code.
Leave a comment when something looks redundant but a build, eval, or test proves it is load-bearing. Put the observed symptom next to the line that survives the obvious cleanup.
Non-obvious technical decisions need a public reference when one exists: RFC, JEP, upstream issue, vendor doc, benchmark, errata, or design note. Put the URL in the comment near the choice. If no public reference exists, say where the decision came from.
Public helpers exposed through the flake lib output or specialArgs.ix use
per-binding /** ... */ doc-comments. Document the argument shape, return
shape, and observable behavior. Keep implementation-only comments for the "why"
notes above.
Rust house style for repo-owned crates: edition 2024, naming, module layout, unsafe validation (Miri/loom/shuttle), mutation testing, fuzzing. Use when writing or reviewing Rust.
Use this skill to interactively debug Antithesis test runs using the multiverse debugger. Open a debugging-session URL, inspect container filesystems and runtime state, run shell commands, and extract evidence from inside the Antithesis environment. Supports both the simplified debugger (default) and the advanced notebook mode.
Search across all timelines in an Antithesis test run to find events, correlate property failures, and answer temporal questions about ordering and causation (e.g., did event A always precede failure B? do failures occur even without a preceding fault?).
Cross-cutting facts and gotchas for any Antithesis work on the ix repo — credentials, harness structure, `setup_complete` protocol, assertion idioms, randomness rules, workload design, triage via `agent-browser`, signed report URLs, and Test Composer script placement. Loads whenever an Antithesis run, report, property/assertion, `snouty` invocation, or `antithesis_sdk::` call is in play. Complements the task-scoped `antithesis-{setup,workload, launch,triage,debug,query-logs,research,documentation}` skills.
Triage Antithesis test reports to understand what happened in a run: look up runs, check status, investigate failed properties (assertions), view metadata, download logs, inspect findings, and examine environmental details. Load after a run completes or when investigating a failure.
Autonomously drive a pull request to merged by spawning a background subagent (the fork) that watches CI fail-fast, fixes each failure on the PR branch, re-pushes, and merges when green, all without blocking the main session. Use when the user wants to watch and merge a PR, babysit it, fix CI and merge, get a PR in, or otherwise hand off a PR's CI-to-merge loop so they can keep working. The skill never blocks the main thread; it launches the watcher and returns immediately.
