PStack Deep Dive (Part 2): Two Agents, Five Special Designs, and How It Actually Lands
PStack Deep Dive series | Part 1 (PStack Deep Dive (Part 1): How a Cursor Plugin Turns Engineering Discipline into Executable Files) covered the methodological skeleton: the three layers, the 24 principles, the 23 playbooks, and poteto-mode. This part covers the executors and the landing: the two agents, the benny automation, the five genuinely special design choices, and what implementing this in OpenClaw and DeepSeek Harness looks like — plus the limits.
Recap, and the Question This Part Answers
Part 1 (PStack Deep Dive (Part 1): How a Cursor Plugin Turns Engineering Discipline into Executable Files) concluded that pstack's value is not a stronger model, but writing "how a senior engineer judges" into 24 citable, triggerable principles, then fixing common engineering tasks into flows with 23 playbooks.
This part answers: how do those principles and flows become two agents, one automation, and a way of operating you can carry into any harness? And — of the places where it is genuinely special, what exactly is special about them?
7 The Two Agents: poteto-agent and comment-sicko
poteto-agent (agents/poteto-agent.md) is the delegation wrapper. Its rules boil down to one requirement: before any work, read the poteto-mode SKILL.md in full, including the inline Principles index — "Read the poteto-mode skill's SKILL.md in full before doing any work, including its inline Principles index." The README explains why it is mandatory: "substituting generalPurpose skips that read and drifts" — substituting a general-purpose subagent skips that read, and then drifts. The README also warns: "do not spawn poteto-agent to run the playbook itself" — it is the executor of steps, not the owner of the flow; the flow belongs to the chat that received poteto-mode.
comment-sicko (agents/comment-sicko.md) is the most unusual presence in the whole stack: a personified, radical comment reviewer. Its description introduces itself as "A deranged comment-hater that savors deletion and condemns workaround code" — a comment-hater obsessed with deletion that condemns workaround code; the first line it prints after being spawned is hard-coded: "Yes... Ha ha ha... Yes!"
The radical rule: every comment is presumed dead, and only five exception classes may live — legal/licensing headers, behavior notes forced by an external dependency that cannot be reshaped, // prettier-ignore, doc comments defining a public API contract, and issue/RFC links explaining a constraint the code cannot express. The verdict rule is merciless: "When I am not sure a keep clause applies, the comment dies." — unsure means dead. Smells like IMPORTANT, do not remove, or too risky do not count as evidence; it reads the surrounding code first, runs how/why to verify when needed, and if doubt remains after verification, the comment still dies. Workaround code sentenced to death gets flagged MUST KILL, with a demand to make the behavior self-evident through renaming, extraction, a type change, or refactoring.
The key is the permission design: it only files reports — "I touch comments and identify refactor targets. I never write application code." Execution and review of the deletions belong to the no-comments skill above it (skills/no-comments/SKILL.md): accept the findings, fix root causes, and for "constraint" comments provide the cheapest replacement — encode the constraint as a lint, a runtime check, or a CI rule, and only then may the comment go. One mad reviewer plus one calm executor: this is the design in the whole system that most resembles a real human team's division of labor.
8 benny: Turning a Slack Issue into a Reproducible Fix
benny (automations/benny/) is a dormant automation pack. Its README says it does two things: triage issue reports arriving on Slack, and reproduce confirmed bugs and prepare small fixes (reproduce-and-fix). It is the only part of pstack not registered as a slash skill, and "benny runs on cursor automations, so it is cursor-only" (README.md) — a clear capability boundary (readers new to Cursor can start with What Is Cursor: The AI Coding Tool That Lives in Your Editor).
triage-issue-reports (automations/benny/skills/triage-issue-reports/SKILL.md) is built around a marker contract: triage results are published as public markers such as [benny:bug] and [benny:performance] tracker=<url>; downstream consumers trust a marker only when the identity-setting author posts it in the original thread. It reads the full report and attachments first, does bounded source tracing, and only then classifies, checks for duplicates, and decides whether to open a ticket, with the iron rule "Prefer no ticket over a guessed or duplicate ticket."
reproduce-and-fix-issues (automations/benny/skills/reproduce-and-fix-issues/SKILL.md) is the gem. The first hard safety rule freezes the source coordinates: the source channel and root-thread coordinates are immutable values, pre-checked before every post; the coordinator is the only entity allowed to post to Slack, and all sub-workers are strictly read-only and barred from holding Slack credentials. The reproduction standard is unusually concrete: "The exact discriminating symptom must appear twice through real UI interaction." — the exact discriminating symptom must appear twice through real UI interaction, and state checks may only confirm observations, never inject symptoms. The fix gate is equally strict: seven conditions must all pass before attempting a "bounded fix" — a confirmed reproduction, media review, no existing fix artifact, no claimant, runtime evidence locating the root cause, changes within budget, and an adapter that can run both baseline and patch. The proof requirement cites the principle directly: "A compile, unit test, code review, or plausible diff is not after evidence." — a passing compile, unit test, code review, or plausible diff is not evidence of a fix. It only opens draft PRs, never merges.
Worth noting: nearly every step of this file explicitly cites pstack principles — principle-guard-the-context-window, principle-sequence-verifiable-units, principle-fix-root-causes, principle-prove-it-works. benny is a complete specimen of mechanizing prove-it-works from personal discipline into an unattended pipeline — and a demonstration of the right posture for delegating to automation: design the guardrails first, then hand over the wheel.
9 Hands-On: Checking benny's Marker Contract with Python
Following the approach of Part 1's section 6, the marker contract can also become a re-runnable script. The trust conditions are exactly two: the marker is posted by the identity-setting author, and it appears in the original thread. The script below uses only the standard library and prints deterministic output:
#!/usr/bin/env python3
"""benny marker-contract checker: trust only markers from the
identity-setting author, in the original thread.
Models the contract in automations/benny/skills/triage-issue-reports/SKILL.md:
triage results ship as public markers such as [benny:bug] or
[benny:performance] tracker=<url>, and downstream consumers trust a marker
only when the identity-setting author posted it in the original thread.
"""
import re
import sys
MARKER = re.compile(r"\[(benny:[a-z-]+)\](?:\s+tracker=(\S+))?")
RAW = re.compile(r"\[benny:")
# original thread -> the author who set its identity (triage coordinator)
IDENTITY = {
"T100": "coordinator",
"T200": "coordinator",
}
# simulated message stream; threads/split/T100 is a forked copy
MESSAGES = [
("T100", "coordinator", "[benny:bug] tracker=https://example.test/1"),
("T100", "helpful_user", "[benny:bug] saw the same crash twice"),
("T100", "coordinator", "[benny:performance] tracker=https://example.test/2"),
("T100", "coordinator", "[benny:wontfix] no repro after two UI runs"),
("threads/split/T100", "coordinator", "[benny:bug] tracker=https://example.test/1"),
("T200", "coordinator", "[benny: BUG] cannot reproduce"),
]
def check(messages):
problems = 0
for i, (thread, author, text) in enumerate(messages, 1):
found = MARKER.findall(text)
if RAW.search(text) and not found:
print(f"FAIL #{i} {thread} {author}: marker does not match the contract -> {text.strip()}")
problems += 1
continue
for kind, _tracker in found:
if thread not in IDENTITY:
print(f"FAIL #{i} {thread}: [{kind}] posted outside the original thread")
problems += 1
elif IDENTITY[thread] != author:
print(f"FAIL #{i} {thread} {author}: [{kind}] posted by an author who did not set the thread identity")
problems += 1
else:
print(f"PASS #{i} {thread} {author}: [{kind}]")
return problems
if __name__ == "__main__":
n = check(MESSAGES)
print(f"\n{len(MESSAGES)} messages checked, {n} problem(s)")
sys.exit(1 if n else 0)
Actual run (macOS, Python 3) prints the following — message #2 carries a marker from an author who never set the thread identity, #5 sits in a forked thread, and #6 does not match the contract format ([benny: BUG] has one space too many); all three get caught, and the script exits with code 1:
PASS #1 T100 coordinator: [benny:bug]
FAIL #2 T100 helpful_user: [benny:bug] posted by an author who did not set the thread identity
PASS #3 T100 coordinator: [benny:performance]
PASS #4 T100 coordinator: [benny:wontfix]
FAIL #5 threads/split/T100: [benny:bug] posted outside the original thread
FAIL #6 T200 coordinator: marker does not match the contract -> [benny: BUG] cannot reproduce
6 messages checked, 3 problem(s)
Encode the marker contract as a checker, and any downstream consumer — human or agent — no longer has to "trust" a triage verdict; it re-runs the script. This is encode-lessons-in-structure, applied literally to automation: the second time a rule needs writing down, it should become code.
10 Five Genuinely Special Things
One: principles must be cited by name. In most methodologies the principles are for humans to read; in pstack they are a dispatch interface for agents to cite. poteto-mode requires replies to name the principles and the choices they changed; docs/guide/08-principles.md is literally titled "Steer with principle names" — the 24 names can correct an agent mid-conversation: see it about to add a layer, and saying attack-the-premise is enough. Principle names become the minimal instruction set between human and machine. There is a hidden benefit, too: the names are a stable public interface — swap the model, swap the harness (readers new to the concept can start with What an Agent Harness Is: The Ordinary Program Wrapped Around the Model), the names stay, and so does the communication cost.
Two: premise attack. Writing "after consecutive failures, check the premise" as a formal procedure with stop rules is a direct counter to the agent wall-banging loop. The original argument is clean: "Each failed fix is evidence against the belief it assumed. A third fix on the same premise spends effort where the evidence already says the cause is not." (skills/principle-attack-the-premise/SKILL.md) — every failed fix is counter-evidence against the belief it assumed.
Three: prove-it-works runs through the whole chain. This principle is not a slogan; it is proceduralized into every link: bug-fix requires every line to trace to runtime evidence; shipping rules "Only a verdict from an agent that did not write the code counts"; benny requires the symptom to appear twice in the real UI. What the documents claim and what the enforcement machinery does are fully consistent — rare among open-source methodologies.
Four: never-block-on-the-human. It treats asynchronous supervision as a first-class citizen: reversible work is done without asking; at a fork where an experiment can answer, no question is asked (the prototype playbook); only irreversible actions stop. poteto-mode even defines behavior under full autonomous authorization: for decisions the authorization covers, "act on it, and report it, with no reply word and no offer" — do it and report, with no "shall I continue?" filler.
Five: harness portability. poteto-mode ships a whole Harness-mapping section: Task is called Agent in Claude Code (subagent_type: general-purpose), task in OpenCode, and spawn_agent in Codex; transcript locations, skill folders, and model-config locations are listed one by one; where subagents cannot be registered, use a general agent and require the prompt to open with "read poteto-mode in full." The mirror README states it plainly: "Works in Claude Code, Codex, Pi, and other agents, not only Cursor." The methodology does not hold the platform hostage — the precondition for landing it across harnesses.
11 Landing It in OpenClaw and DeepSeek Harness
pstack itself is a stack of plain files, and the README spells out the landing paths: in Cursor, /add-plugin pstack; elsewhere, the skills CLI (npx skills add backnotprop/pstack) installs it into Claude Code, Codex, Pi, OpenCode, and friends. Installing really means dropping skills/<name>/SKILL.md into the target harness's skill directory, plus two steps: run setup-pstack to pick models, and enter through poteto-mode day to day.
The local environment has two entry points ready for this. First, the OpenClaw side already has an agent named pstack configured (the agents section of openclaw.json carries the entry, with its own workspace), usable as a dedicated executor carrying this methodology. Second, this session's toolchain mounts two AOCI port groups, one of which is the DeepSeek Harness (DSH; for an intro see What Is DeepSeek Harness: The Open-Source Agent Runtime Where 'Everything Is a Plugin') build — to bring pstack's skills into DSH, the path is the same: drop them into its skill directory and follow poteto-mode's Harness section for the mapping (delegation actions, for example, map to DSH's subagent mechanism). An honest label is required here: this article only verified that the configuration entry points exist; whether the playbooks run end to end after installation is unverified and outside what this article claims.
In practice, the three things most worth porting need no full installation at all: the 24 principle files (drop them into a skill directory and they become citable), the "scripted verification" habit of prove-it-works, and comment-sicko's comment-review flow (reproducible on any harness with a subagent mechanism). The portability design makes partial adoption a legitimate option.
12 Limits and Criticisms
The token cost is not low. poteto-mode requires the main chat to read the full text and the principles index; every poteto-agent reads it again before starting; support skills stack on triggers. The official docs admit the cost themselves: "a pstack run spends real tokens, so you send the prompt when you're ready" (docs/guide/README.md). For small tasks, this overhead may exceed the task itself.
The process has weight. The Non-negotiables trigger net is dense; even a small change drags along a string of skills; the multi-model split (grok plus Opus by default) requires quotas across providers; model names are hard-coded in defaults (such as grok-4.7-xhigh-fast) and need reconfiguration as versions age. For a one- or two-person team, adopting the whole thing may not pay off.
It leans hard on judgment. Principles trigger on "when to apply," and triggering itself depends on agent judgment; when judgment fails, the whole system is just form. This is why the named-citation rule matters — it at least makes "was it applied correctly" visible. And the author's personal philosophy is not universal truth: "i don't believe in planning. the best spec is code." (README.md) — planning-heavy teams need to adjust.
The capability boundaries are explicit. benny is cursor-only; deslop, control-cli, control-ui and friends depend on the cursor-team-kit plugin and do not ship with pstack; the reply style (no em dashes, no mid-sentence colons) is strong personal preference and may not fit every team's voice. pstack is not a quality silver bullet either: it documents discipline, but the quality of executing that discipline still depends on the model and the reviewers. Worth mentioning: it governs itself too — changing any SKILL.md must pass the eval playbook blind test, guarding against "I tweaked the prompt, so it must be better" — an empirical attitude toward the methodology itself that makes it more mature than most prompt collections.
13 Closing
pstack's value is not the specific steps of the 23 playbooks — those will age — but the feasibility it demonstrates: how far engineering judgment can be documented. The 24 principles each carry trigger conditions and stop rules, the 23 flows each carry verification gates, replies and comments each carry format constraints, and every claim is required to carry its own evidence label. It turns "a senior engineer's taste" from oral tradition into files that are version-controllable, auditable, and parallelizable.
For a tech lead, the thing most worth stealing is not the full installation but three design decisions: principles must be named, verification must target the real artifact, and only irreversible actions need a human. Write those three into your own agent configuration, and you already have half of pstack's essence.
If You Take Away Only Three Things
- Name the principle: for every significant decision, state which principle it used and which choice it changed. Unnamed, it is just a verbal tic.
- Verify against the real thing: do not trust proxy metrics, self-reports, or "should be fine"; the strongest evidence is a script you can re-run.
- Reversible means do it; only the irreversible needs asking: reserve "waiting for a human" for truly irreversible actions; do the rest, and report afterwards.
Appendix A: All 24 Principles (Matching File Names)
Core (10): laziness-protocol · foundational-thinking · redesign-from-first-principles · attack-the-premise · subtract-before-you-add · minimize-reader-load · outcome-oriented-execution · experience-first · exhaust-the-design-space · build-the-lever
Architecture (6): model-the-domain · boundary-discipline · type-system-discipline · make-operations-idempotent · migrate-callers-then-delete-legacy-apis · separate-before-serializing-shared-state
Verification (5): prove-it-works · fix-root-causes · sequence-verifiable-units · test-behavior-not-implementation · explain-the-number
Delegation (2): guard-the-context-window · never-block-on-the-human
Meta (1): encode-lessons-in-structure
Appendix B: All 23 Playbooks (Matching File Names)
authoring-a-skill · autonomous-run · autopilot-full · autopilot-stack · babysit · bug-fix · eval · feature · hillclimb · investigation · multi-phase-plan · opening-a-pr · orchestrate · pause-safely · perf-issue · prototype · refactoring · runtime-forensics · session-pickup · shipping · trace-forensics · visual-parity · worktree-cleanup
Sources and Version
- Upstream: the pstack directory of the cursor/plugins repo (github.com/cursor/plugins/tree/main/pstack), MIT license, by Lauren Tan (poteto).
- Independent mirror: backnotprop/pstack (github.com/backnotprop/pstack); MIRROR.md documents the sync mechanism — the upstream branch holds the Cursor originals, and main is upstream plus the mirror's own changes.
- Local mirror snapshot this article is based on: git HEAD
e44668c2aad92eacf4e84df47984121fefb11b82(2026-10-20, "Use ~/.claude/rules/pstack-models.md for settings in Claude Code"); plugin.json version 0.15.28. - On commit 0c3333f: neither README.md nor MIRROR.md mentions it, so this article defers to the local mirror's actual HEAD.
- Files cited: README.md, MIRROR.md, plugin.json, skills/poteto-mode/SKILL.md, skills/poteto-mode/playbooks/ (bug-fix, shipping, investigation, hillclimb, and others), skills/principle-attack-the-premise/SKILL.md, skills/principle-prove-it-works/SKILL.md, skills/principle-never-block-on-the-human/SKILL.md, skills/no-comments/SKILL.md, agents/poteto-agent.md, agents/comment-sicko.md, automations/benny/ (README.md, skills/triage-issue-reports/SKILL.md, skills/reproduce-and-fix-issues/SKILL.md), docs/guide/README.md, docs/guide/08-principles.md.
- The script in section 9 is an original demo for this article, and its output is from an actual run; quoted English is verbatim from the source files.