saga-walkthrough

Narrates large code changes reactively to produce a decision protocol for architects.

Updated Nov 21, 2025
One-click install
npx skills add https://github.com/alatyshau/duet --skill saga-walkthrough-alatyshau
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: saga-walkthrough
Source: https://github.com/alatyshau/duet/tree/main/packages/skills/modes/saga-walkthrough
Command: npx skills add https://github.com/alatyshau/duet --skill saga-walkthrough-alatyshau

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a saga implements substantial changes across files and components, an architect who doesn't read the underlying code needs to verify what happened without diffing everything. This Skill walks the architect through the changes via incremental narration, ending with a protocol of concrete decisions to act on. ## Core Features & Use Cases - Reactive Narration: No fixed agenda — after every architect signal, the narrator updates a model of what the architect knows and cares about, then picks the next most valuable topic. - Verify-First Discipline: Before stating that something was done a certain way, the narrator reads the actual code or commit history instead of quoting executor summaries. - Decision Protocol Output: Produces output/decision-protocol.md containing only actionable decisions with explicit user citations, while unresolved discussion traces stay in work/. - Use Case: After an automated saga lands changes across a dozen files, run a walkthrough session where the architect listens, asks questions, and pushes back — ending with a concrete list of what to change in specs, code, or tests. ## Quick Start Walk me through the changes this saga just landed, one idea at a time, and produce a decision protocol of what I need to act on.

Frequently Asked Questions about saga-walkthrough

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review large code changes without reading the code?

Use a narrated walkthrough where a reviewer who has read everything discloses changes incrementally — one idea per step with one explicit question. You react, ask, and push back while the narrator adapts the sequence to your signals.

How to verify executor summaries against actual code?

Never quote an executor's summary as fact. Open the relevant code path or commit, spot-check one concrete detail, and surface any discrepancy between the summary and reality as part of the current discussion topic.

What goes into a decision protocol after a code walkthrough?

Only decisions to act: what to change in spec, code, tests, or naming, concrete enough that an implementer needs no clarification, each with an explicit citation of the architect's own words. Open questions and unresolved doubts never appear in the protocol.

When should a walkthrough not ask the architect for a decision?

Skip executor-level choices like library functions, internal naming, or micro-refactors that never surface to users. Reserve questions for architect-level concerns: UX, scope, trade-offs, and deviations from prior design intent.

Why avoid a fixed agenda when presenting code changes?

A pre-written numbered agenda creates an anchor the presenter defends instead of adapting to the listener's signals. Start with a one-paragraph narrative hypothesis flagged as reshapable, then re-rank topics after every signal.