Get Plain-Language Session Reports With the Open Steps Skill Pack

The author of Open Steps — Pavlo Kharmanskyi, a product-side builder with twenty years of shipping and 50+ developers at his company — built this pack after a specific wall: the agent does excellent work, then reports it in commit hashes and jargon, and a non-engineer genuinely cannot tell whether the work is done. Open Steps is his fix: eight skills that change what the agent tells you at the moments that matter, and demand evidence where "done" used to be taken on faith.

Why This Skill Matters

The eight skills work as a loop. os-whats-next picks the next task, os-step-by-step walks a non-technical person through their part, os-done-or-not reports the result, os-check-work refuses to trust another session's report and re-verifies every claim, os-ask-simple turns questions into plain words with a cost and one marked recommendation, os-what-could-go-wrong premortems anything hard to undo in a fresh agent that had no hand in the decision, os-say-simple rewrites any jargon text, and os-big-picture maintains a standing BIG-PICTURE.md of every feature and its status.

Two design decisions make the reports trustworthy. Measured and assumed stay apart — a "yes" has to name its proof, and anything unchecked says "not checked". And the plain-language rules borrow from ASD-STE100, the simplified English written for aerospace manuals — the README is careful to say borrow, nothing here is certified against the standard.

Installation

Clone the repo first; the pack needs git, and gh (optional) unlocks pull-request checks:

git clone https://github.com/kharmanskyi/open-steps.git

On Claude Code, one command installs the plugin and wires both hooks:

claude plugin marketplace add ./open-steps && claude plugin install open-steps@open-steps

Then add the routing block — a short table naming the moments each skill must fire — to your standing instructions:

grep -q 'os-done-or-not' ~/.claude/CLAUDE.md 2>/dev/null || cat open-steps/docs/routing-block.md >> ~/.claude/CLAUDE.md

On Codex CLI, Cursor CLI, and Gemini CLI, one copy command installs the skills for all three, plus a few lines of hook settings per tool as the README documents:

mkdir -p ~/.agents/skills && cp -R open-steps/skills/os-* ~/.agents/skills/

Verify with claude plugin details open-steps or bash open-steps/doctor.sh — the doctor reports "not checked" for anything it cannot see rather than guessing. Updating on Claude Code takes two steps (git pull in the clone, then claude plugin update open-steps@open-steps); the plugin updates from your clone, not from GitHub.

Real Workflow: "Are We Done?"

1. Work with your agent as usual. When the session wraps — or you ask — os-done-or-not fires and produces a one-screen report: done or not, anything needed from you, any new debt, safe to close. The README's own before/after example turns a paragraph of JWT-and-p95 jargon into "People can sign in again" plus a table where the bad news gets its own row.
2. When another session claims it finished something, run os-check-work instead of accepting the handoff — it checks every claim against what actually happened.
3. Before agreeing to anything hard to undo — a migration, a launch, a purchase — let os-what-could-go-wrong assume the decision failed and work backwards in a fresh agent.
4. Reports land in ~/.claude/open-steps/reports/<project>/, outside your repositories, so they never enter commits and survive uninstalling. Two hooks do the bookkeeping: session-start shows the routing table and your last report; stop-report asks for a report when real work landed.

One behavior to know before you install: when a pull request has green checks and an approved review, the pack verifies it once more and merges it — on Claude Code without a permission prompt. Two things stop a merge: a claim that fails verification, or a note saying merges happen on command only (put that note in your standing instructions file if you want manual control).

Tips

• The pack publishes its own activation eval: 25 everyday phrases, three runs each, on Haiku 4.5, Sonnet 5.5, and Opus 5.5, measured 2026-10-05 — 89% activation on Haiku, 100% on Sonnet and Opus, with os-step-by-step the weakest at 3/9 on Haiku. The README calls three runs a smoke test, not a benchmark.
• Hook behavior is tunable: OPEN_STEPS_DISABLE switches the stop hook off, OPEN_STEPS_MAX_REPORT_LINES caps the report the start hook injects (default 80), and OPEN_STEPS_COOLDOWN spaces report requests (default 900 seconds).
• Skill descriptions are commands, not summaries — they open with "ALWAYS invoke this skill" — and the evals do not compare that wording with alternatives, per the README.
• Pre-approved tools are scoped per skill on Claude Code (report writes, gh pr reads, the merge command); Codex CLI, Cursor CLI, and Gemini CLI ignore that field per their docs — a part the README marks as not tested.
• An optional "Answer first" output style exists for Claude Code; it is off by default because it would replace a style you already chose.

When Not to Use This

The README's limits section is explicit: answer quality and the premortem's fresh agent are measured on Claude Code only — the same activation phrases were also run on Codex, Cursor, and Gemini CLI by contributors, with results in the repo's evals/README.md. If you read diffs for a living, one-screen plain-language reports may be a layer you do not need; the pack targets the person who cannot verify the agent's work directly. And the auto-merge behavior, however guarded, is a real delegation of merge authority — if your project requires human-merged PRs, set the merges-on-command note before your first session, not after.

See the leaderboard for more skills.