prism-code-slicing

Slicing diffs with prism

The slicing CLI takes a repo + a diff and prints the code relevant to the changed lines under one of ~30 slicing algorithms. It's for reviewing a change — "given this patch, what should I actually look at?" The hard part isn't running it; it's picking the algorithm that answers the reviewer's question. This skill is that map.

The binary is slicing (historical name; the project is Prism). It is diff-driven — if you want to navigate a whole repo with no diff, use the MCP server / prism-code-navigation skill instead.

Workflow

cd /path/to/the/repo
git diff HEAD~1 > /tmp/change.patch          # or any unified diff / PR patch
slicing --repo . --diff /tmp/change.patch --algorithm <algo>
slicing --repo . --diff /tmp/change.patch --algorithm <algo> --format review   # for code-review output

• Default algorithm is leftflow. Run multiple at once: --algorithm "leftflow,fullflow,taint".
• Presets: --algorithm review (a curated review suite) · --algorithm all (everything).
• slicing --list-algorithms prints them all; see ALGORITHMS.md for the per-algorithm operator's guide.

Pick the algorithm by the reviewer's question (defaults first)

Start with leftflow (backward data-flow from the changed assignments — the default) for "what does this change depend on / affect." Reach for a specific one only when the question is specific:

The reviewer is asking…	Algorithm	Key flag
What does this change affect (backward data deps)?	leftflow (default)	—
…including where the new values flow forward?	fullflow	—
Just the data chain, no control-flow noise?	thin	—
Is there a path from user input to a dangerous sink?	chop	--chop-source / --chop-sink
Where do these tainted values end up?	taint	--taint-source (repeatable)
What does the code do when this value is null / condition holds?	conditioned	--condition
What data-flow paths changed vs the previous version?	delta	--old-repo
Which peer functions should match this changed one?	horizontal	--peer-pattern
The full request path, handler → database?	vertical	--layers
Trace a cross-cutting concern (auth, error handling)?	angle	--concern
Is a counterpart missing (open/close, lock/unlock, malloc/free)?	absence	—
Broken symmetry (serialize/deserialize, encode/decode)?	symmetry	—
Cross-module blast radius of a changed public API?	membrane	—
Ripple — callers that don't handle a new error?	echo	—
Async/goroutine state races around await/spawn?	quantum	--quantum-var
Trace callers/callees up to N levels, stop at framework internals?	barrier	--barrier-depth
Which functions are riskiest (coupling + churn)?	threed	--temporal-days
Recently deleted code resurfacing / co-change coupling?	phantom / resonance	(needs git history)

When unsure, run a small set (leftflow,fullflow,absence) and read the union — cheaper than guessing.

Output formats

--format text (default, human) · json (machine — pipe to jq or an LLM) · paper (arXiv-comparable) · review (grouped findings with severities — use this when producing a code review).

slicing --repo . --diff /tmp/change.patch --algorithm review --format json | jq '.findings[]'

Gotchas

• It needs a diff. No --diff ⇒ nothing to slice from. It is not a whole-repo navigator. For "who calls X" / "module deps" with no patch, use the MCP server (prism-code-navigation skill).
• Lines are 1-indexed throughout (tree-sitter's 0-indexed rows are converted internally).
• git-history algorithms need git history. phantom, resonance, threed (with --temporal-days) read the repo's commit history; they're empty/degraded on a shallow or history-less checkout.
• C/C++ field-sensitive analysis needs type info. Pass --compile-commands compile_commands.json to enrich struct fields, typedefs, and class hierarchy; without it, C/C++ slices are field-insensitive.
• review/all are aggregates — convenient, but the combined output is large and (for review) not byte-stable across runs. For a reproducible single answer, name one algorithm.
• A slice is high-recall, not a verdict. It's the code relevant to the change, surfaced for a human (or you) to review — not a proof of a bug. Read the surfaced sites; don't report a finding you haven't traced to a concrete failure.