dsh-pstack 0.2.0-beta.1 → 0.2.0

package/assets/skills/interrogate/references/code-quality-review.md

@@ -1,47 +0,0 @@
-# Code Quality Review
-
-Each reviewer applies this code-quality lens in addition to the rubric. It is a strict standard focused on implementation quality, maintainability, abstraction quality, and codebase health.
-
-Above all, be ambitious about code structure. Do not merely identify local cleanup. Actively search for "code judo" moves, restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant.
-
-## Core Prompt
-
-Start from this baseline:
-
-> Perform a deep code quality audit of the current branch's changes.
-> Rethink how to structure / implement the changes to meaningfully improve code quality without impacting behavior.
-> Work to improve abstractions, modularity, reduce Spaghetti code, improve succinctness and legibility.
-> Be ambitious, if there is a clear path to improving the implementation that involves restructuring some of the codebase, go for it.
-> Be extremely thorough and rigorous. Measure twice, cut once.
-
-## Dimensions
-
-Each dimension is stated once. Apply the ones that are relevant.
-
-0. **Be ambitious about structural simplification.** Do not stop at "this could be a bit cleaner." Look for reframings that make whole branches, helpers, modes, conditionals, or layers disappear. Assume a "code judo" move is often available. It uses the existing architecture more effectively and makes the change dramatically simpler. If you can delete complexity rather than rearrange it, push hard for that.
-
-1. **Do not let a PR push a file from under 1k lines to over 1k lines without a very strong reason.** Treat this as a strong smell. Prefer extracting helpers, subcomponents, or modules. If the diff crosses that threshold, ask whether the code should be decomposed first. Waive only for a compelling structural reason where the resulting file stays clearly organized.
-
-2. **Do not allow spaghetti growth in existing code.** Be suspicious of new ad-hoc conditionals, scattered special cases, or one-off branches inserted into unrelated flows. Treat "weird if statements in random places" as a design problem, not a style nit. Prefer pushing the logic into a dedicated helper, state machine, or module instead of tangling an existing path.
-
-3. **Bias toward cleaning the design, not just accepting working code.** If behavior can stay the same while the structure becomes meaningfully cleaner, push for the cleaner version. Prefer simplifications that remove moving pieces over refactors that spread the same complexity around.
-
-4. **Prefer direct, boring, maintainable code over hacky or magical code.** Treat brittle, ad-hoc, or "magic" behavior as a problem. Be skeptical of generic mechanisms that hide simple data-shape assumptions. Flag thin abstractions, identity wrappers, or pass-through helpers that add indirection without buying clarity.
-
-5. **Push on type and boundary cleanliness when it affects maintainability.** Question unnecessary optionality, `unknown`, `any`, or cast-heavy code when a clearer type boundary could exist. Prefer explicit typed models over loosely-shaped ad-hoc objects. If a branch leans on a silent fallback to paper over an unclear invariant, ask whether the boundary should be made explicit.
-
-6. **Keep logic in the canonical layer and reuse existing helpers.** Call out feature logic leaking into shared paths or implementation details leaking through APIs. Prefer existing canonical utilities over bespoke one-offs. Push code toward the right package, service, or module instead of normalizing drift.
-
-7. **Treat unnecessary sequential orchestration and non-atomic updates as design smells when the cleaner structure is obvious.** If independent work is serialized for no reason, ask whether it should run in parallel. If related updates can leave state half-applied, push for a more atomic structure. Do not over-index on micro-optimizations, but do flag avoidable orchestration complexity that makes the code more brittle.
-
-## Output Expectations
-
-Prioritize structural code-quality regressions and missed simplifications first, then spaghetti and branching complexity, then boundary, type, and file-size concerns, then smaller modularity and legibility issues.
-
-## Approval Bar
-
-Do not approve merely because behavior seems correct. Treat these as presumptive blockers unless the author can justify them: the PR keeps a lot of incidental complexity when a code-judo move would delete it. Pushes a file from below 1000 lines to above 1000 lines. Adds ad-hoc branching that tangles an existing flow. Scatters feature checks across shared code. Adds an unnecessary abstraction, wrapper, or cast-heavy contract, or duplicates an existing helper or puts logic in the wrong layer when there is a clear canonical home. If those conditions are not met, leave explicit, actionable feedback and push for a cleaner decomposition.
-
-## Review Tone
-
-Be direct, serious, and demanding about quality. Do not be rude, but do not soften major maintainability issues into mild suggestions. If the code is making the codebase messier, say so. If the implementation missed an obvious dramatic simplification, say that too. Do not be satisfied with "maybe rename this" when the real issue is structural.

package/assets/skills/interrogate/references/lead-judgment.md

@@ -1,39 +0,0 @@
-# Lead Judgment Framework
-
-## Filtering Principles
-
-### Nitpick Gravity
-
-Reviewers, especially adversarial ones, tend to fill their review. If they don't find critical issues, they'll inflate nits to fill the space. If a reviewer's findings are all nits and style preferences, the code is probably fine. Say so.
-
-### Hypothetical vs. Actual
-
-"What if someone passes null here?" is only a finding if the caller can actually pass null. Trace the call site. If the input is validated upstream or the type system prevents it, dismiss the finding. Reviewers working from a diff can't always see the full call chain. You can.
-
-### Premature Abstraction Warnings
-
-Reviewers often suggest extracting functions, adding interfaces, or creating abstractions. Does this code need to change in a second way? If not, the abstraction is premature. Simple inline code that works beats a clean abstraction that's overkill for the current scope.
-
-### "I Would Have Done It Differently"
-
-This is the most common false positive in code review. A finding that amounts to "I prefer a different approach" is not a bug, not a design flaw, and not actionable unless the reviewer shows a concrete problem with the current approach. Dismiss these, and say why.
-
-### Missing Context Signals
-
-Watch for findings that reveal the reviewer didn't understand the context:
-- Suggesting changes to code the author didn't write or modify
-- Flagging patterns that are consistent with the rest of the codebase (the reviewer just doesn't know that)
-- Recommending approaches that conflict with constraints you know about
-
-These are honest mistakes from reviewers working with limited information. Dismiss them gracefully.
-
-## When Reviewers Are Right
-
-Don't dismiss findings just because they're uncomfortable. The whole point of adversarial review is to catch things you'd miss. Signs a finding deserves attention:
-
-- Multiple models flag the same issue independently (consensus signal)
-- The finding identifies a concrete execution path, not a hypothetical
-- The finding reveals a gap in your mental model of the code
-- You read the finding and think "...yeah, actually"
-
-Be especially careful about dismissing security findings and correctness bugs. These deserve more scrutiny even when they come from a single model.

package/assets/skills/interrogate/references/reviewer-prompt.md

@@ -1,62 +0,0 @@
-# Reviewer Prompt Template
-
-Build each reviewer subagent's prompt from this template, filling in the placeholders.
-
----
-
-You are an adversarial code reviewer. Find real problems in the code below: bugs, design flaws, security issues, and maintainability concerns. You are not here to be helpful or encouraging. You are here to stress-test.
-
-## Intent
-
-The author's stated intent for this change:
-
-> {INTENT}
-
-Review whether the code achieves this intent well. Do NOT question the intent itself. Assume the goal is correct and challenge the execution.
-
-## Code Under Review
-
-{DIFF_OR_FILES}
-
-## Review Rubric
-
-{RUBRIC_CONTENTS}
-
-## Code Quality Lens
-
-{CODE_QUALITY_CONTENTS}
-
-## Instructions
-
-Review the code through every lens in the rubric and the code-quality lens above that you find relevant. Do not force lenses that don't apply. A simple bug fix does not need paragraphs about architectural integrity.
-
-For each finding, provide:
-
-1. **Severity**: `critical` | `warning` | `nit`
-   - `critical`: Would cause bugs, data loss, security issues, or fundamentally broken behavior
-   - `warning`: Design concern, maintainability risk, or correctness issue that isn't immediately broken but will cause pain
-   - `nit`: Style, naming, minor improvement.
-2. **Finding**: What the problem is, in concrete terms. Reference specific lines/functions.
-3. **Evidence**: Why you believe this is a problem. Show your reasoning. Don't just assert.
-4. **Suggestion** (optional): What you'd do instead, only if you have a concrete alternative.
-
-A good finding references specific code, not vague concerns ("this could be better"). It distinguishes between "this is broken" and "I would have done this differently". It considers the stated intent. A finding that ignores the context of what's being built is a bad finding.
-
-Do not restate what the code does without identifying a problem. Do not praise the code. If you find nothing wrong, say "no findings" and stop. An empty review is a valid outcome.
-
-## Output
-
-Return your findings as a structured list:
-
-```
-## Findings
-
-### 1. [Severity] Short title
-**Location**: file:line or function name
-**Finding**: What's wrong
-**Evidence**: Why this matters
-**Suggestion**: (optional) What to do instead
-
-### 2. [Severity] Short title
-...
-```

package/assets/skills/interrogate/references/rubric.md

@@ -1,77 +0,0 @@
-# Review Rubric
-
-Review through whichever lenses are relevant. Not every lens applies to every change.
-
-## Correctness
-
-Does the code actually do what the intent says it should?
-
-- Edge cases: empty inputs, nil/undefined, boundary values, concurrent access
-- Error handling: are errors caught, propagated, or silently swallowed?
-- Off-by-one, type coercion, integer overflow, string encoding
-- State management: race conditions, stale closures, dangling references
-- Do both the happy path and the sad path work?
-- Idempotency: what happens if this operation runs twice, or if a previous run crashed halfway? If the answer is "it depends on what state was left behind," a reconciliation step is missing.
-- Concurrency: if multiple actors can touch the same mutable state (files, branches, shared data), is access serialized structurally (locks, sequential phases, exclusive ownership), or by conventions that won't hold?
-
-When you find a potential bug, trace the execution path. Don't just flag "this could be nil". Show the call chain that makes it nil.
-
-## Root Causes vs. Symptoms
-
-Is the code fixing the actual problem or papering over a symptom?
-
-Answering this often requires looking beyond the changed files. Read the surrounding code (callers, callees, type definitions, sibling modules) and understand the architecture the change lives in. Use the tools available to you (Read, Grep, Glob) to follow the call chain, read the types, and understand why the code exists before judging whether the change addresses the right layer.
-
-- Guard clauses that mask a deeper invariant violation
-- Retry logic that hides a broken contract
-- Type casts that silence a modeling error
-- A workaround: why is it needed? What would a proper fix look like?
-- A fix in module A that should really be a fix in module B's contract
-- Instructions where structure would be better: if the fix is a comment saying "don't do X" or a convention someone has to remember, ask whether it could instead be a type constraint, a lint rule, or a runtime check that makes the wrong thing impossible
-
-## Structural Integrity
-
-Does the code fit well into the system it's part of?
-
-- Boundary discipline: is validation at system boundaries, or scattered through business logic? Validate data once where it enters the system, then trust it internally.
-- Abstraction level: is the code mixing high-level orchestration with low-level detail?
-- Coupling: does this change introduce dependencies that will make future changes harder?
-- Data model fit: do the data structures match the actual access patterns?
-- Bolted-on vs. integrated: if the new requirement had been known from the start, would the code look like this, or does the change feel patched onto the existing design?
-- Legacy dual-paths: does the change introduce a new API while keeping the old one alive? If there are no external consumers, migrate callers and delete the old path in the same wave. Don't leave compatibility layers that will become permanent.
-
-Don't penalize simple code for lacking abstraction. Premature abstraction is worse than duplication.
-
-## Verification
-
-Can you tell that this code works from reading it?
-
-- Are there tests? Do they test behavior or implementation details?
-- Are there assertions/invariants that would catch regressions?
-- If this is a bug fix: is there a test for the bug?
-- If this touches an integration boundary: is the full path tested?
-- Check the real thing, not a proxy. If the code checks liveness via file mtime or cached state instead of reading the actual value, that's a verification gap.
-- For delegated or async work: does the code verify actual output artifacts, or does it trust self-reports and summaries?
-
-## Complexity Budget
-
-Is the complexity justified by what the code accomplishes?
-
-- Code that could be simpler without losing correctness or clarity
-- Abstractions that serve only one call site
-- Configuration or parameterization for cases that don't exist yet
-- Dead code, unused imports, vestigial parameters
-- Over-engineering: "just in case" code paths with no current callers
-- Obsolete compatibility paths kept alive for transitional stability that's no longer needed. If the migration is done, delete the scaffolding
-- Does the user experience justify the complexity? Every feature, control, and option should earn its place. Half-finished features are worse than missing ones.
-
-Simpler is better unless simpler is wrong.
-
-## Security
-
-For each security finding, trace the input path through the code and show it.
-
-- User input flowing to dangerous sinks (SQL, shell, eval, innerHTML) without sanitization
-- Authentication/authorization gaps in new endpoints
-- Secrets in code, logs, or error messages
-- TOCTOU (time-of-check-time-of-use) in security-critical paths

package/assets/skills/no-comments/SKILL.md

@@ -1,26 +0,0 @@
----
-name: no-comments
-description: Spawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints.
-disable-model-invocation: true
----
-
-# No comments
-
-> DSH port of pstack. `pstack_subagent` replaces Cursor's Task tool, and `role` replaces Cursor model slugs. Full mapping: `../../docs/harness/dsh.md`.
-
-Spawn Comment Sicko. Act on accepted findings.
-
-Defer to Comment Sicko's fresh perspective.
-
-## Scope
-
-Use the caller's files or diff. Otherwise use the current diff against the base branch, default `main`, including the working tree.
-
-## Steps
-
-1. Call `pstack_subagent` with `agent: "comment-sicko"` and the scope in the brief. That agent type is the only way to get Comment Sicko's persona, because the Host injects its preamble; a `general` child would lose it, and a missing preamble stops the call instead of degrading. Read the Subagents section of the `poteto-mode` skill at its absolute resource path first. Do not restate its rules. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-2. Inspect its report and diff. Reject application-code edits, scope escapes, exception-protected deletions, misstated `MUST KILL` reasons, and flags that treat kept intentional code as guilty. Reshape flags on our-code surprises stay actionable. Do not restore those comments. A keep survives only with proof it is about something we cannot change. Audit missed scoped lint and TypeScript suppressions. Correctness or safety suppressions stay actionable `MUST KILL`s. Restore deletions only with exact exceptions and scoped proof. Before accepting thin `IMPORTANT` or `do not remove` kills or keeps, read the `how` or `why` skill's `SKILL.md` at its absolute resource path and run it on their symbol. If a kill is ambiguous, do not restore. If a keep is refuted or still ambiguous, delete it. Revert and rerun one rejected report with the failure named. Reject a second, report it open, and fail this skill with the reason.
-3. Fix trivial accepted flags directly by deleting a dead path, dropping a parameter, or using the real API. If any fix needs a shape, read the `architect` skill's `SKILL.md` at its absolute resource path and run it once for the accepted set and surrounding code. Stop at the sketch. Architect shapes. Step 4 implements.
-4. Implement the smallest root-cause fix in scope. Remove every named workaround. If the root cause is out of scope, land the smallest in-scope fix and report the rest open. `principle-fix-root-causes` and `principle-redesign-from-first-principles` guide intent only; read either `SKILL.md` at its absolute resource path. Neither authorizes widening the fence nor fixing instances outside it. Never bolt on symptom guards.
-5. Constraint comments say `do not remove`, `do not change wording`, or `talk to X before changing`. Leave keeps about things we cannot change. Offer the cheapest in-scope type, runtime, test, or CI lint. Ask through `ask_user_question` and wait for the answer. An unattended run and the eval playbook need the caller's approval up front, because nobody can answer. If approved, encode then delete. Otherwise delete, report the constraint open, and sketch out-of-scope work.
-6. Report the deletion count, restored comments, reruns, architect sketch, fixes, encoding offers, encodings, unenforced constraints, and other open work.

package/assets/skills/poteto-mode/playbooks/authoring-a-skill.md

@@ -1,12 +0,0 @@
-### Authoring or modifying a skill
-
-**You own the skill's voice.**
-
-1. There is no built-in authoring tool here: Cursor's `create-skill`, its drafts, and its evaluation tooling are not part of this port. Write the `SKILL.md` yourself and validate it with this package's own checks.
-2. Validate the skill: the frontmatter parser accepts `name` and `description` and rejects an unknown field, every referenced file exists, and every internal link resolves. `scripts/check-assets.ts` is the checker, so a broken link or an unparsable frontmatter fails the asset audit instead of shipping.
-3. Test cases if structural. Skip if subjective.
-4. Run **Opening a PR**.
-
-When in doubt, delete. Keep only prose that changes a decision. Tell it to do the thing and skip the reason. Explain only when the rule is confusing without one. Match tone to scope. Point at structural sources (types, READMEs, config), as `principle-encode-lessons-in-structure` requires; read its `SKILL.md` at its absolute resource path. Delegate to other skills by their absolute resource paths. Don't restate. A workflow you keep hitting but isn't captured → propose a new skill.
-
-**Reply:** summary of the skill, key design decisions, validation notes.

package/assets/skills/poteto-mode/playbooks/autonomous-run.md

@@ -1,15 +0,0 @@
-### Autonomous run
-
-**You own the exit condition. Define done, then drive to it without stopping.**
-
-1. State the exit condition as a checkable predicate before the first iteration (tests green, repro fixed, all N PRs merged, pixel-diff zero). A predicate a stranger cannot run is not a predicate, and a duration is not one either.
-2. Register that predicate as the goal before the first iteration. This host has no loop command to type, so `create_goal` is what carries a run: the goal is durable in this Session, it holds the round cap, and automatic continuation rounds proceed from it. Continuation needs the goal round driver mounted in the profile, so read `get_goal`, check whether continuation is armed and whether rounds are actually starting, and report which of the two you have instead of implying a loop. `create_goal`, `edit`, `pause`, and `resume` each need a direct request from the operator in this top-level turn, so a child cannot register or steer a run on your behalf.
-
-   Pick the wake mechanism by what this host actually has. A timed input is `schedule_create`, which delivers a reminder into this Session at a wall-clock time: use it as a heartbeat sized to when re-checking is worth a turn, never as an event subscription, because a reminder cannot watch anything, and a child cannot arm one at all. A real event needs a real watcher: a script that blocks until the condition changes and then exits, started as a background job so its settlement arrives as a notice, or a poll loop you run and read. If neither fits the event you care about, say the run is supervised and check it yourself. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-3. Each iteration makes the smallest change the evidence justifies, verifies it against the predicate, commits if it advanced, discards changes that didn't help. Belt-and-suspenders that "might help" gets reverted, not left to ride.
-   Sequence the work via the **sequence-verifiable-units** principle skill, verifying each unit before the next instead of batching checks at the end.
-4. Mid-run discoveries are yours. Address broken skills, related bugs, flaky verifiers, review noise, tooling failures, orphaned follow-ups, and fixable drift yourself via poteto-mode. Put out-of-band fixes in their own PR. Do not park reversible work for the operator or ask a question instead of acting. Surface only irreversible actions, genuine product or preference calls no experiment can settle, or a real dead end. Keep the predicate as the main drive, and return to it after each side fix.
-5. Checkpoint every iteration via the **show-me-your-work** skill, a row for what changed and whether the predicate moved.
-6. Stop when the predicate is met, and record it with `update_goal` action `complete`, which also disarms continuation. Report a block only when the same concrete condition survived the deployment's consecutive-round threshold, three by default, and state it in `blocked_reason`; the host rejects a block before that count, and a plateau is not a block, so keep going and pivot your approach to push past it. Surface a genuine dead end rather than spinning, and never relax the predicate to declare victory. Pause and resume belong to the operator's direct request, and a host restart leaves an active goal disarmed, so a resumed Session has to be rearmed on purpose. A repeated-prompt driver such as Ralph is used only when the operator names it, and it never replaces the predicate.
-
-**Reply:** the exit condition, iterations run, what landed, what was discarded, final predicate state.

package/assets/skills/poteto-mode/playbooks/autopilot-full.md

@@ -1,25 +0,0 @@
-### Autopilot-full
-
-**You own the verdicts, never the PRs. One owner carries each PR from build to merge, and nothing merges until your swarm, which never wrote the code, has proven the code that lands.**
-
-A verdict covers one patch and green CI covers one head. Step 4 runs a full swarm once, and again only for a major change. The patch-id rule in `playbooks/shipping.md` can carry a lane's result, and every new head needs its own green CI.
-
-1. **The operator's gates come first.** The grant covers only the queue's items, so items the operator names as theirs and PRs outside the queue stop at merge-ready. A request to state the plan is not a go.
-2. **Spawn one owner per PR, and keep its work where a replacement can find it.** Resolve the forge once for the program. GitHub CLI (`gh`) is the default. If `command -v origin` succeeds and Origin can resolve the repository, use `origin pr` for every PR operation. Otherwise stay on `gh` and record the fallback. Never require Graphite (`gt`). Each owner is a `pstack_subagent` child with `role: "feature, refactoring"` and its own `create_worktree` checkout, whose absolute path you pass as that child's `cwd`. It builds, opens its PR per `playbooks/opening-a-pr.md`, proves the change on the real artifact, babysits to green per `playbooks/babysit.md`, and merges once steps 4 and 5 clear it. There is no VM here: a worktree separates the working directory and the branch and nothing else, so an owner that needs a port, a cache, or a service says so before it starts.
-
-   Open the PR early so CI and bots run alongside the work. The code is ready only after the diff read-through, which replaces the slop-strip this port does not ship, and the `/no-comments` pass, so the full swarm runs on finished code. Then rebase onto current trunk and report the code-ready head before self-proof, so verification runs on the base the patch lands on. Report every later head, and merge-ready once self-proof, CI, and babysit are done. Fix rounds stay on that base unless trunk conflicts or breaks CI, because each rebase restarts CI. Run the repo's checks for the touched paths on the committed head before the code-ready push and before a later push that needs a verifier.
-
-   Assume this machine and this Session die. Soon after starting, push and start a decision trail at a directory the operator named, or under `.audit/<task-slug>/` in the repository when they name none, per the **show-me-your-work** skill, then push after every unit worth keeping. Nothing here outlives the host process: every child ends with it, so the pushed branch and the trail are the only state a replacement can read. Whoever spawns a subagent records its id, state, and a stuck-after runtime from past runs of its kind in that store, so the root can probe it if the parent dies. Force-push only your own branch, with `--force-with-lease` pinned to the SHA you last pushed or took over, and on any push you did not make, stop and report to the root.
-3. **Run owners in parallel off trunk, never stacked,** so each PR lands on its own.
-4. **Swarm-verify once.** A full swarm runs once, at the code-ready head. Another full swarm runs only for new behavior, a redesign, or a large new diff. A rebase, a merge-conflict resolution, or a minor fix gets a single verifier at the new head. Fan out independent verifiers at the code-ready SHA per the **swarm** skill. They re-run the gates, prove the load-bearing behavior live on the real surface through a named driver the project ships or a verification skill it already has, and audit the diff. The verdict is not clean without the live lane, or before you audit the merge-ready report's receipts, because no lane trusts a claim it has not checked.
-
-   Send every proven finding, whatever a lane labeled it, to the owner in one fix-forward, with a red test across every site with the same defect. A defect trunk shows without the PR is recorded against trunk and does not gate the PR, but one the PR copies or newly reaches is the PR's own. Never push a fix yourself, because each branch has one writer. Replace a stuck owner instead.
-5. **The owner merges only what you verified, tested on the trunk it lands on.** Green CI alone never authorizes a merge. Once the swarm's lanes have started, merge prep rebases onto current trunk, reports the new head, and waits for green CI.
-
-   Right before merging, fetch trunk and ask whether its changes can affect the patch, because rebasing for every trunk move never ends. Rebase and wait for CI when the code that would land was never tested, as with a conflict, a file both sides changed, or a change to which checks run for the PR. A lockfile both sides changed needs no rebase when a frozen install passes on the merge result and the packages the PR changes resolve there as on the head, because that install tests the lockfile that would land, and a failing install means the rebase must repair it. When trunk changed a caller of the patch or something the patch depends on, such as code it calls or a dependency version, run the patch's checks on the merge result and merge on a pass. Otherwise merge. If trunk would force a third rebase past merge prep, hold and report to the root, which sequences the colliding work.
-6. **Run the root layer.** Anything that loosens a gate, such as a raised budget or an allowlist entry, needs a verifier's proof and then your fresh countersign, because the owner is the one who wants green. Under a grant that covers approvals, that countersign is the approval, and the owner's record of it points at your countersign for a lane to check. A disabled or soft-failed check always comes out, because it stops guarding every case. Never give or bypass an approval the forge enforces, because no countersign covers it.
-
-   On the operator's go, arm an hourly audit with `schedule_create` and `every_seconds: 3600`, re-arming it after each tick, because long runs drift and agents stall silently. That reminder is a heartbeat delivered into this Session and cannot see a PR, so anything event-shaped needs the background-job watcher from `playbooks/babysit.md` beside it. Each tick re-reads this playbook from the installed package and fixes drift, such as an unreported head or an unrecorded agent, by having its owner record it, because drift is a gap in the record, not a stall. It probes every child through `list_agents` and each child's own artifacts, judging by side effects only, because status text and summaries can hide a stuck child. An agent is stuck when it errors, cannot start turns, or shows nothing new past its stuck-after runtime, and so is an owner that has neither pushed nor written a trail row by the first tick. One waiting on you or the operator is not stuck, so answer it. Replace a stuck child at once: call `interrupt_agent` on it and start a fresh replacement with consolidated scope in the same move, without waiting for the stop to land. A tick that changed something for the operator ends by catching them up per the **ketchup** skill, and one that changed nothing stays quiet.
-7. **Stand down at once on the operator's stop.** A hold reaches every owner as a zero-writes order sent with `send_message`, which confirms delivery and not compliance, so the hold is in force only once each owner has answered it. Each reports where it stands and keeps its brief until the operator releases it; an owner that does not answer gets `interrupt_agent`.
-
-**Reply:** catch the operator up per the **ketchup** skill, covering each PR's state and verdict, what merged, countersigns and why, and open operator gates, with links to each PR and the trails.

package/assets/skills/poteto-mode/playbooks/autopilot-stack.md

@@ -1,12 +0,0 @@
-### Autopilot-stack
-
-**You own the stack, never the landing. Hand the operator one linear stack of base-chained PRs to review and land.** **Autopilot-full** holds except for how verified work leaves. Each tick re-reads both playbooks from the installed package, and this one wins where they differ.
-
-1. **Run Autopilot-full's owners, minus the landing.** Owners report STACK-READY in place of merge-ready. They never rebase onto another branch, trunk included, and never retarget, merge, close a PR, or arm auto-merge, because the root owns the chain's topology and the operator owns the landing. When an item depends on another, its owner branches from that item's branch, not from trunk.
-2. **Give the topology one writer.** Owners push only their own branches and report each tip and its intended parent. Only you rebase or retarget a link, because two writers on one chain undo each other. An owner's own `create_worktree` checkout is not stack management: it gives that owner a working directory and a branch, it knows nothing about PR bases, and no worktree operation orders, retargets, or merges a link. Append each clean PR in dependency order, with its base set to its parent's branch (`origin pr edit <pr> --base <parent-branch>` or `gh pr edit <pr> --base <parent-branch>`). Never require `gt`. An owner takes your push as its new base and lease, and on a conflict resolves its own slice for you to push.
-3. **Absorb drift at the root.** Until landing starts, apply Autopilot-full step 5's test to each link and rebase the chain bottom-up where it calls for one. Then apply the patch-id rule link by link, since a link's base is its parent.
-4. **Deliver the chain, then keep your hands off it.** Each link carries its verdict in its PR. Once landing starts, nobody writes to the chain except the post-merge retarget that `playbooks/shipping.md` sanctions, because a second writer breaks a landing in flight. A mid-landing problem goes through you to the operator, and any fix waits for the operator's go.
-
-**Choosing between the autopilots.** Autopilot-full when the PRs are independent and landing authority is granted. Autopilot-stack when the operator wants review before landing, the work is sequenced or coupled, or merge authority is withheld.
-
-**Reply:** catch the operator up per the **ketchup** skill, with links to the stack root and tip, a one-line verdict per link, and anything parked or excluded with the reason.

package/assets/skills/poteto-mode/playbooks/bug-fix.md

@@ -1,15 +0,0 @@
-### Bug fix
-
-**You own this task. Plan, review, verify.** Delegate investigation and the fix to `pstack_subagent` children, stay in the lead. Read the Subagents section of the `poteto-mode` skill at its absolute resource path before the first spawn. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-
-Be scientific. Every shipped line traces to runtime evidence. Belt-and-suspenders that "might help" is a hypothesis, not a fix. It does not ship. When evidence refutes a hypothesis, revert what it motivated. The smallest change the evidence justifies ships, nothing more.
-
-1. Reproduce it yourself on the matching surface, through the control path the `poteto-mode` Non-negotiables section names, even when a debug or instrumentation protocol says to ask the user to reproduce. That path is a real project driver or verification skill; when the project has none, report the surface as unreachable instead of treating a unit test as reproduction. Ask the user only with a stated, specific reason the control surface cannot reach the target, and only after driving it as far as it goes. If it won't reproduce directly, synthesize the trigger, tighten conditions, or instrument until it fires.
-2. Binary-search the cause. Form the candidate hypotheses, then rule them out until one survives. Seed them by reading the `how` skill over the affected subsystem and the `why` skill for regression history, each at its absolute resource path. Each pass, take the split that cuts the most remaining problem space, get runtime evidence, eliminate. When program state is unclear, add instrumentation or logging and read it as the code runs. Don't guess. Keep a long or stubborn hunt in this Session: keep the hypothesis list current and re-read your own instrumentation output. Automatic continuation requires the goal round driver and the Autonomous run playbook's exit predicate; neither replaces this runtime evidence loop. Confirm the surviving *mechanism* with runtime evidence before the step-3 architect/interrogate fan-out.
-3. Plan the fix. If it crosses a function boundary, read the `architect` skill's `SKILL.md` at its absolute resource path and run it first. Delegate implementation to a `pstack_subagent` child with `agent: "poteto-agent"` and `role: "bug-fix"`, naming a specific scope; a role the file does not name inherits the parent route, and a route that does not resolve fails the call with the role file named.
-4. Verify on the same surface. The original repro now passes. "Inconclusive" or wrong-surface is not a pass. Flag it. Unit tests show branch behavior, not bug absence.
-5. Stage the commits so the failing repro lands before the fix in git history. Read the `tdd` skill's `SKILL.md` at its absolute resource path for the failing-test-first cadence when the bug has a cheap local test path. Skip it when the test would be expensive, integration-heavy, or unclear.
-   This is the canonical `principle-sequence-verifiable-units` move, the failing test first and the fix on top; read that skill's `SKILL.md` at its absolute resource path.
-6. Read `playbooks/opening-a-pr.md` next to this file and run it.
-
-**Reply:** what was broken, root cause, fix, how you verified. Paste failing-then-passing repro output verbatim.

package/assets/skills/poteto-mode/playbooks/feature.md

@@ -1,21 +0,0 @@
-### Feature
-
-**You own the design. Plan, review, verify.** Delegate implementation. Stay in the lead.
-
-1. Read the `how` skill's `SKILL.md` at its absolute resource path and run it over the affected subsystem.
-2. Read the `architect` skill's `SKILL.md` at its absolute resource path and run it for parallel design exploration.
-3. Write the throughput checkpoint as four `todo_write` items. A dimension that genuinely does not apply (single file, no fan-out) keeps its item with `n/a: <reason>` rather than being dropped:
-   - **Blocking first steps.** Gates run before fan-out.
-   - **Independent workstreams.** Disjoint files, services, or layers parallelize. Shared writes serialize.
-   - **Shared mutable state.** Default to splitting the target, as `principle-separate-before-serializing-shared-state` requires; read its `SKILL.md` at its absolute resource path. Serialize only for real invariants.
-   - **Smallest safe decomposition.** If one worker is best, name why.
-4. Delegate code-writing to a `pstack_subagent` child with `agent: "poteto-agent"` and `role: "feature, refactoring"`, and a specific scope: file paths, the named data shape and its organizing structure as `principle-model-the-domain` requires (read that `SKILL.md` at its absolute resource path), a state machine over scattered booleans, a table or registry over branching, a typed model over repeated shape assumptions, chosen before the delegate writes logic, plus success criteria. Read the Subagents section of the `poteto-mode` skill at its absolute resource path before the spawn. When the implementation admits multiple valid shapes (error handling, abstraction layer, test structure), read the `arena` skill's `SKILL.md` at its absolute resource path and delegate through it, so the runners surface the alternatives and the cross-judge guards the pick. Mandatory: no skip-with-reason escape, and `principle-laziness-protocol` does not override it (the gain is review separation, not lines saved). A child that cannot spawn satisfies this by owning the diff directly with the same review separation. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it. No "standing by" reply that waits on a nested agent. Comments per **Comments**. Surgical edits, re-ground against the source for upstream-derived files. Port shared-primitive improvements to all consumers and verify each. Commit liberally.
-5. Verify on the matching surface. "Inconclusive" or wrong-surface is not a pass. Flag it.
-6. Rebase into small, ordered commits. Stack follow-ups.
-   Apply `principle-sequence-verifiable-units`, read at its absolute resource path, building, verifying, and committing each small unit before the next.
-7. If the design is contested, read the `interrogate` skill's `SKILL.md` at its absolute resource path and run it before shipping.
-8. Read `playbooks/opening-a-pr.md` next to this file and run it.
-
-Code-coupled work (one feature, one migration) goes to a single owner with the checkpoint inline. That owner fans out internally after the blocking phase. Parent-level fan-out is for slices that produce independent artifacts (audits, cross-subsystem investigations, competing experiments). Rewrite the checkpoint at phase boundaries. Spawn a fresh owner rather than chaining interrupts.
-
-**Reply:** what you built, what you chose and why, the throughput checkpoint, open decisions. Tables for design alternatives.

package/assets/skills/poteto-mode/playbooks/orchestrate.md

@@ -1,112 +0,0 @@
-### Orchestrate
-
-**You own the program, never the code. Author briefs, drain the queue, keep the frontier green, decide.** For a whole project handed to one standing coordinator chat: multi-day, many stacked PRs, dozens to hundreds of subagents, the human checking in twice a day instead of every five minutes. One task driven to a predicate is Autonomous run. One ambitious run needing a bespoke workflow is figure-it-out. Route here when the work outlives any single agent. Work one agent could finish inside the session's budget is not a program.
-
-Ceremony must scale with the program. On cheap near-identical units, collapse it as each section directs.
-
-Three rules carry the rest.
-
-- Completions are queue events, not interrupts.
-- Every spawn and every resume carries the standing orders verbatim.
-- The brief is the product. A vague brief fails quietly, because a worker cannot ask you a question.
-
-#### Roles and placement
-
-- **Coordinator (this chat).** Local. Frames, authors briefs, drains the inbox, owns the human report, makes judgment calls. It never authors or edits code. Conflicted merges, chain rebases, and code changes are always tasks. Mechanically landing a verified unit (fast-forward or clean cherry-pick of a worker's commit, then push) is bookkeeping the coordinator may do itself on repos where local git is cheap. Queueing finished work behind an idle stacker is how a deadline harvests nothing. The loop is agentic end to end. Children are started and briefed only through `pstack_subagent`, steered only through `send_message`, stopped only through `interrupt_agent`, and read only through `list_agents` and their own artifacts. Pick each child's role per the Subagents section of the `poteto-mode` skill, because the role is what selects its route. State reads and writes go through `pstack_script` with `id: "orch"` at drain points, one command in and one line out; the tool runs the bundled script on the Host's own runtime. The CLI never spawns, waits, or wakes anything. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-- **Sub-coordinator.** Always local, durable, one per track, and only when the program exceeds what one coordinator's drains can manage. A track the coordinator can drain itself needs no middle layer. Each nested layer re-pays a full orientation preamble, and a blocking sub-coordinator hides its children while the parent idles. Owns its track's units and boards, authors its workers' briefs, (spawns its own workers and verifiers, and nesting works to the depth this bundle's row allows, two, which a child can only lower further). Rolls up aggregates at wave boundaries. Never forwards raw child reports. Cap in-flight children at what one drain can process, roughly ten, as a rolling window. Never as blocking batches, which cost the slowest child of every batch.
-- **Worker / verifier.** Always a local `pstack_subagent` child in its own `create_worktree` checkout. There is no cloud environment in this port, so every child runs on this machine, shares its ports, caches, and credentials, and dies with the host process. A child cannot read another child's Session, so its brief inlines what it needs or points at repository paths and the store. Prefer fewer, broader workers. One writer per worktree or branch (principle-separate-before-serializing-shared-state). Run a unit's verifier through a different role from its worker, and confirm the routes the tool reports actually differ, because two children that resolved to one route are not cross-model review.
-
-Depth stays at coordinator, track, worker. Author the track decomposition per project (build, landing, and verification are common cuts, not a required shape). Hard-coded swarm trees were tried and parked as too rigid.
-
-#### Store layout
-
-Create `orchestrate/<project-slug>/` in a directory the operator names, or under `.audit/` in the repository when they name none, because this host hands no store path to the model. Every file has exactly one writer. Owners publish facts, readers aggregate at read time. Use `pstack_script` with `id: "orch"` for bookkeeping, written below as `orch`, while its canonical plain TSV and JSON stay readable without the CLI. The tool runs the bundled script on the Host's own runtime, so no `bun`, `bash`, or `node` on the PATH is involved; if the tool is unavailable, read and write the TSV and JSON by hand and say which commands you could not run.
-
-- `preferences.md` is the standing-orders register: numbered lines, one constraint each (model policy, stack shape and count, verification bar, forbidden paths, escalation policy). Paste it verbatim into every spawn and every resume. Directives decay across resumes, and each dropped one costs a human turn. When you catch yourself restating an instruction, append the line before you act (principle-encode-lessons-in-structure).
-- `overview.md` is the durable PR and issue DB. Append. Never rewrite wholesale per event.
-- `units.tsv` has one row per unit: id, track, state, branch, PR, head SHA, brief path. Update rows in place.
-- `frontier.json` is the computed merge frontier, per Stack safety.
-- `ledger.tsv` is the verification ledger, per Verification.
-- `inbox/` holds completion pointers. `gates.md` parks human gates (question, options, default on no answer).
-- `decisions.tsv` is the trail via the show-me-your-work skill.
-- `status.md` is derived from `units.tsv` and `ledger.tsv` at each drain, never hand-maintained. Regenerate it from the tables instead of narrating events into it.
-
-#### The brief
-
-Your prompts to agents are your only product, and a sloppy brief compounds into slop across the whole tree. Every spawn carries all of it. A field you cannot fill is a unit you have not scoped yet.
-
-```
-GOAL         one sentence, the outcome, executable by a stranger with no chat access
-SCOPE        paths this unit may write; paths it may not; its exclusive worktree or branch
-CONTEXT      pointers to files and PRs; upstream reports pasted in full when this unit
-             depends on them, because workers cannot see siblings
-ACCEPTANCE   checkable criteria, one per line
-VERIFY       exact commands or the driver path, plus known gotchas
-TIMEBOX      rough cap on runtime; on expiry, return partial findings and stop rather than run on
-FORBIDDEN    no PR retargets or merges, no rebase, no force-push, no fixes outside scope,
-             plus unit-specific bans
-REPORT       status, branch, head SHA, PRs, verdict, what you actually ran, deviations,
-             suggested follow-ups
-STANDING     <preferences.md pasted verbatim>
-```
-
-Size the brief to the unit. A one-command unit gets the template collapsed to a paragraph that still names goal, scope, the verify command, and the report shape. A 4KB scaffold around a two-line edit costs more to write and obey than the edit. A spawn may reference the standing-orders file by its store path, because every child here is local and can read it. A resume is the exception: that child lost its brief, so paste the standing orders again instead of pointing at them.
-
-A sub-coordinator brief adds its track boundary and unit list, its spawn budget and the rule that each worker gets its own worktree, the drain protocol, and the rollup format (per child: name, status, PR, head SHA, verdict, one line, plus track status and frontier delta).
-
-A dependency is a context relay, not just ordering. Undeclared upstream context makes the worker guess. Missing fields are a refuse-to-spawn condition. Audit one sampled worker brief per sub-coordinator per wave, concurrently with the wave it samples, never as a gate in front of it. A failing brief stops that track and fixes the sub-coordinator's instructions, not just the worker, because brief quality decays late in a run. Never resume-chain a brief. Respawn fresh with consolidated scope.
-
-#### Steps
-
-1. **Frame.** State the done predicate as something countable ("all 126 units merged, each ledger-verified `unit-test-verified` or better"). Quantify scope: units, rough effort, expected stacks, and the wall-clock budget. If one agent could finish inside that budget, stop here and run Autonomous run instead. Collapsing must not depend on another document being present. It means do the work directly in this session, plain workers where they help, verification inline, landing as you go, and none of the store, register, or pilot machinery below. Schedule landing against the budget. By roughly 70% of it, stop spawning and land what is verified. Name the tracks per project. A contested decomposition or one-way door goes through the arena skill before the pilot. Present the framing once. Reversible prep proceeds without waiting.
-2. **Install the runtime.** Run `orch init`. Open the trail via the show-me-your-work skill, write the standing orders before any spawn, and seed `frontier.json` from existing PRs with `orch frontier set --repo <repo-dir>`, adding `--forge origin` when the forge is Origin.
-3. **Pilot.** Push one unit through the whole path: brief, worker, verification, stack entry, ledger row, merge. The pilot exists to falsify the brief template, the verify recipe, and the unit size while that costs one agent instead of fifty. Fix the contract from pilot evidence before any fan-out. Scale the pilot to the unit. On programs of near-identical cheap units, the first unit is the pilot, run as a normal unit with its verify command inline, and fan-out starts the moment it lands. The dedicated pilot pipeline (separate verifier agent, audit gate) is for expensive or novel unit shapes, not for clone-units where a serialized pilot has nothing to falsify.
-4. **Scale.** Spawn a rolling window of workers up to the in-flight cap, refilling as children finish. Blocking batches pay the slowest child of every batch. Spawn track sub-coordinators only past the one-drain threshold in Roles. Recompute ready work after each drain. Relay upstream reports into downstream briefs. Keep sibling communication upward only. The sampled brief audit runs alongside the wave it samples and stops the next refill on failure, not the current one.
-5. **Drain.** Run the queue discipline below at every drain point.
-6. **Land.** Landing is continuous, never a terminal phase. Integration starts with the first verified unit and runs alongside the remaining waves. On heavy repos the stacker is a standing role from wave one, integrating as units verify. On repos where local git is cheap, the coordinator lands verified units itself per Roles. Keep the frontier green before upper-stack work. Stack safety governs. Advance `frontier.json` only on merge or reported new head SHAs.
-7. **Close.** Drain the final inbox, reconcile every spawned agent to a terminal row (done, abandoned, zombie-reconciled), confirm the predicate on the real artifact, confirm every landed PR has a verdict for its current head SHA, audit the trail per show-me-your-work, recording the route its reviewer lane resolved so a lane that landed on the author's own route is visible as one, encode recurring corrections into `preferences.md` or the brief template. Leave the store intact. It is the postmortem.
-
-#### Queue and drain
-
-- On a completion notification, run `orch inbox push <agent> <unit> <status> [--report PATH]` and return to what you were doing. Never deep-review inline. A completion that needs review becomes a verifier unit. Never review a diff inside a drain.
-- Drain in batches at four points: the end of a critical section, a track rollup, and a frontier watcher wake (the queued watcher from `playbooks/babysit.md` started as a background job, with a `schedule_create` heartbeat as the fallback), and before a human report. Begin each batch with `orch inbox drain`. Arrivals during a drain wait for the next one.
-- Critical sections you finish first: authoring a brief, a stack operation, a conflict decision, writing a gate, updating ledger or frontier.
-- Each drain classifies every pointer (landed, needs-verify, failed, zombie, noise), writes the resulting rows through `orch unit add`, `orch unit set`, and `orch ledger record`, runs `orch status`, then spawns the next wave in one message.
-- Account for every spawned child at its track's rollup: arrived, respawned, or its scope explicitly absorbed. Silently redoing a missing child's work hides both the wasted spend and the coverage gap its result existed to close.
-- A drain turn ends with the three lines from `orch status`: counts against the states, what changed, gates open. Detail lives in `status.md`. The full reply contract applies at checkpoints and close.
-
-#### Stack safety
-
-- The frontier is a computed object, never narrative. Recompute `frontier.json` after every merge and stack mutation: ordered PR list, branch names, head SHAs, a generation number, the lowest unmerged PR. The command walks the PR base chain through the checkout's current branch, so chain order and PR states come from the forge. It uses `gh` by default. Pass `--forge origin` when the program resolved the forge to Origin. Head SHAs come from local branch refs, so resolve it from the stacker's clone. A branch with no PR errors rather than guessing.
-- Exactly one stacker per stack may mutate topology (chain rebases, force-pushes, base retargets, merges), serialized within its stack. Record the holder in the standing orders. Chain rebases run on this machine, because there is no cloud environment to move them to. Keep the checkout lean and the working tree clean between rebases, and treat a rebase that takes minutes as a reason to land sooner rather than to wait.
-- Workers never rebase and never retarget or merge PRs. Babysitters follow `playbooks/babysit.md`, one per stack, scoped to one immutable frontier generation. They report conflicts to the stacker rather than rebasing.
-- PR closes and retargets go through the stacker only. Closing a base PR orphans every chain above it. Merges and stack surgery are units with briefs like any other.
-- One retro watcher follows merged PRs for reverts, post-merge CI breaks, and orphaned follow-ups.
-
-#### Verification
-
-Scale verification to the unit. When VERIFY is a single cheap command, the worker runs it and reports the output, and the coordinator spot-checks receipts. A dedicated verifier agent (on a different model family than the worker) is for units whose verification is expensive, judgment-laden, or high-blast-radius. A verifier agent whose entire product would be rerunning one command is ceremony, not verification.
-
-Write ledger rows with `orch ledger record`. Check the current PR and head SHA with `orch ledger check`. `ledger.tsv`, one row per verdict, keyed by PR number plus head SHA: `live-ui-verified | unit-test-verified | type-check-only | verifier-blocked | verifier-failed`. CI green is an input to a verdict, not a verdict. Behavioral work needs better than `type-check-only`. `verifier-blocked` is not a pass. Respawn when the environment heals. `verifier-failed` gets a fix unit, not a re-verify. A worker may self-report. A verifier overrides it on the same key. A new head SHA voids the row, so re-verify after restack. The ledger answers "was this verified", not memory and not the transcript.
-
-A unit is not done until its output is externalized the moment it lands, never batched to the end of the run. A worker pushes its branch, a verifier writes its ledger row, receipts land in the store. Work that exists only on this machine's disk and was never pushed was never done.
-
-#### Liveness and failure
-
-- Never resume an agent to check on it. A resume restarts an idle agent. Probe read-only: the ledger, `units.tsv`, `gh`, pushed branches, and `list_agents` for whether a child is running or inactive. A child's own summary is not liveness, and neither is the age of a file it wrote.
-- A silent death gets a synthetic postmortem row in the inbox (unit, failure mode, last evidence, options). Replan on evidence as it arrives. Never wait for full quiescence.
-- Retry by mode: cap-hit or oom, respawn with smaller scope. Network-drop, retry as-is. Tool-error, retry on a different model. Unknown, retry once. Two retries, then abandon the unit and replan around it.
-- A zombie that returns hours late reconciles against the current frontier and ledger before anything is accepted. Salvage unique findings through a fresh unit, never a blind merge.
-- When continued spawning would produce garbage tree-wide (bad upstream output, broken acceptance, dead infra), write a stop line at the top of the standing orders, let in-flight work finish, fix the cause, clear it.
-- Bound your own infra retries the same way you bound a child's. After a few consecutive tool aborts, stop retrying. Write a terminal handoff to durable state (what is done, where it lives, the exact command to resume) and end the run.
-- After a host restart: every child is dead, because nothing here runs outside this process and no work survives it. Re-read the standing orders and `units.tsv`, recompute the frontier, reattach units by PR and branch rather than by child id, respawn one sub-coordinator per track from its stored brief plus current state, drain, resume. The dead session's store lock clears itself on the next write. `orch` replaces a lock whose holder pid is gone.
-
-#### Escalation
-
-Reaches the human, batched into the status page rather than per item: irreversible actions (force-push to shared branches, deploys, deletions, closing someone else's PR), genuine product or preference calls no experiment settles, a standing order that contradicts observed reality, a program-level dead end that survived a replan. Park each as a `gates.md` entry before asking, and route work around it.
-
-Never reaches the human: frontier nudges, rebase mechanics, retries, CI flake triage, review-thread triage, format fixes, scope the brief already forbids (refuse and continue), and "should I keep going". When in doubt, act and log.
-
-Mid-run discoveries fix only what blocks the frontier. Everything else parks in follow-ups. At this fan-out a small scope leak multiplies into PRs nobody asked for.
-
-**Reply:** at checkpoints and close: the predicate and the count against it from `units.tsv` and `ledger.tsv`, tracks and what each landed, the frontier (PR list plus SHAs), verdicts summary, what was abandoned and why, gates awaiting the human (the only asks), the store path, and the trail path. Numbers from the tables, not narrative. Include PR links.

package/assets/skills/poteto-mode/playbooks/perf-issue.md

@@ -1,25 +0,0 @@
-### Perf issue
-
-**You own the measurement story. Plan, review, verify the numbers.** Tie every fix to a measurement, don't read source instead of measuring.
-
-1. Capture a baseline trace through the matching project control path. With no real profiler or trace tool in the project, report the measurement as missing instead of substituting a unit test. Vet the baseline, and each later number, with the `benchmark-checklist` skill, read at its absolute resource path.
-2. Read the `how` skill's `SKILL.md` at its absolute resource path and use it to ground hypotheses. Don't claim a perf ceiling without running it first.
-   Try the performance mantras in order, cheapest first:
-   1. Don't do it. Stop work whose result nothing uses rather than cheapening it.
-   2. Do it, but don't do it again.
-   3. Do it less.
-   4. Do it later.
-   5. Do it when they're not looking.
-   6. Do it concurrently.
-   7. Do it cheaper.
-
-   When an earlier mantra meets the target, stop.
-3. Plan the fix from the trace. If it crosses a function boundary, read the `architect` skill's `SKILL.md` at its absolute resource path and run it first. Delegate implementation to a `pstack_subagent` child with `agent: "poteto-agent"` and `role: "perf-issue"`. Read the Subagents section of the `poteto-mode` skill at its absolute resource path first. Review the diff. Capture a post-fix trace. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-   Apply `principle-sequence-verifiable-units`, read at its absolute resource path, verifying each attempt before trying the next.
-4. Parse and compare the artifacts (JSON to sqlite, diff). "Inconclusive" or wrong-surface is not a pass. Flag it.
-5. Cite the measurement in the PR.
-6. Read `playbooks/opening-a-pr.md` next to this file and run it.
-
-For sustained improvement against a metric rather than a one-off fix, use the Hillclimb playbook (`playbooks/hillclimb.md`), which keeps one hypothesis per iteration and needs a frozen measurement harness before the first change.
-
-**Reply:** baseline number, post-fix number, delta, artifact path.

package/assets/skills/poteto-mode/playbooks/refactoring.md

@@ -1,16 +0,0 @@
-### Refactoring
-
-**You own the contract. The structure changes. The behavior does not.** Distinct from Feature, which adds behavior, and Bug fix, which corrects it.
-
-If the cleanup reveals a missing feature or a real bug, split it out and ship the structural change first against the pinned contract. A redesign is allowed, but name it and route to Feature. Large or cross-cutting structural work belongs to the `figure-it-out` skill, read at its absolute resource path. This playbook is the focused-to-medium change.
-
-1. Pin the behavior contract first. Read the `how` skill's `SKILL.md` at its absolute resource path and run it over the affected subsystem to learn the contract, then write a characterization test, snapshot, or equivalence harness that captures current behavior before any structure moves. If the area has no coverage, write the pin before touching structure. Type check and lint are not a pin, and neither is a green build.
-2. Name the structure the code is missing, as `principle-model-the-domain` requires; read its `SKILL.md` at its absolute resource path. Boring code stays when the shape is already clear and local. The reshape must delete branches or invalid states, not add indirection.
-3. Name the target shape. State what the module layout, types, and call graph should be if built today, per `principle-foundational-thinking` and `principle-redesign-from-first-principles`, each read at its absolute resource path. If the target crosses a function boundary, read the `architect` skill's `SKILL.md` at its absolute resource path and run it for parallel design exploration of the shape before the move.
-4. Subtract before you add. Delete dead code, collapse one-caller wrappers, drop redundant validators, and remove orphan references before introducing the new shape, as `principle-subtract-before-you-add` requires. The smallest change that reaches the target shape ships, per `principle-laziness-protocol`, read at its absolute resource path. A speculative cleanup that "might help" gets reverted.
-5. Move in small behavior-preserving steps, each keeping the pin green. For API reshapes, migrate every caller and delete the old API in the same wave, as `principle-migrate-callers-then-delete-legacy-apis` requires; read its `SKILL.md` at its absolute resource path. No compatibility shims, no parallel old-and-new paths. Spot-check every rename against the actual files. Renames silently miss usages in strings, prose, and back-references. Delegate the mechanical edits to a `pstack_subagent` child with `agent: "poteto-agent"` and `role: "feature, refactoring"`, with a specific scope (file paths, the names being moved, the behavior to hold). Read the Subagents section of the `poteto-mode` skill at its absolute resource path first. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-6. Prove behavior is unchanged on the real artifact, not "it compiles", as `principle-prove-it-works` requires; read its `SKILL.md` at its absolute resource path. For larger reshapes, run an equivalence check: a script that diffs old-vs-new outputs, a recorded baseline replayed against the new code, or a smoke run on the matching surface through the project's real driver. With no driver, report the surface check as unproven.
-7. Confirm the change is worth keeping. The success measure is reduced reader load, per `principle-minimize-reader-load`, read at its absolute resource path. If the diff does not lower reader load somewhere, revert it.
-8. Rebase into small ordered commits. A subtraction commit, then the reshape, then any follow-on cleanup. Shape them with `principle-sequence-verifiable-units`, so each behavior-preserving slice stays green before the next. Read `playbooks/opening-a-pr.md` next to this file and run it.
-
-**Reply:** the structure that changed, the pin you held it against, the equivalence proof, the reader-load delta, what shipped and what got reverted. No new behavior.

package/assets/skills/poteto-mode/playbooks/runtime-forensics.md

@@ -1,11 +0,0 @@
-### Runtime forensics
-
-**You own the diagnosis. Instrument the live process, don't theorize from source.** The deliverable is a cited diagnosis, not a fix.
-
-1. Capture the live signal on the matching surface: a CPU profile for a spinning process, a heap snapshot for a leak, a CDP trace for a visual glitch. A real artifact, not a guess, and only through an interface this Session actually has; when no live CPU, heap, or CDP interface is reachable, report that gap instead of reasoning from source and calling it forensics.
-2. Reduce the artifact to the smoking gun: the function on the hot path, the retainer chain from the leaked object to a GC root, the loop firing without input. Parse large artifacts in a `pstack_subagent` child with `agent: "general"` and a brief that forbids writes, as `principle-guard-the-context-window` requires; read that skill's `SKILL.md` at its absolute resource path. Keep the reduced finding in the main thread. Read the Subagents section of the `poteto-mode` skill at its absolute resource path first. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-3. Prove the mechanism before believing it. Inject instrumentation through a live interface the process actually exposes, such as CDP eval on a running browser target, or hotfix the live code without reloading, to confirm the hypothesis cheaply. With no such interface, mark the mechanism as unproven rather than confirmed.
-4. Map the finding back to source: file, symbol, the line that allocates or schedules.
-5. Throughput checkpoint stays one line: `throughput checkpoint: n/a, read-only forensics`.
-
-**Reply:** the signal captured, the reduced finding, how you proved the mechanism, the source location, artifact paths. No fix unless asked. Hand back to Bug fix or Perf once the cause is known.

package/assets/skills/poteto-mode/playbooks/session-pickup.md

@@ -1,11 +0,0 @@
-### Session pickup
-
-**You own the resume point. Read the prior trail, don't redo it.**
-
-1. Locate the prior trail: a session id the user provides, a pushed branch, or a trail file. A session id is read with `pstack_history` when it is this run or one of its reviewable direct children (`scope: "children"` plus that `sessionId`); any other id needs a workspace-authorized reader, and this tool refuses an arbitrary id instead of opening one. A branch is reconstructed with `git`. An agent URL hosted in the cloud is not supported: ask for the session id, the branch, or the trail file instead, and say the cloud form was refused. Read the first events and the tail first, then scan back for the decision points. Parse a long log in a `pstack_subagent` and keep the reduced timeline in the main thread, as `principle-guard-the-context-window` requires; read its `SKILL.md` at its absolute resource path. Pick that subagent's role per the Subagents section of `poteto-mode`; read its `SKILL.md` at its absolute resource path. Start from the level the role line names, raise it for hard work and lower it for routine work by passing `reasoningEffort`; a child that cannot call `set_reasoning_effort` keeps the level you gave it.
-2. Reconstruct operational state. The branch and worktree, what already landed (`git log`, `git diff` against the base), the open todos, the decisions made. The prior trail is authoritative input. Resist the bias to re-derive it.
-3. Diff done vs pending. Compare what shipped against what was planned, name the resume point, do not re-run the prior repro or redo completed work. A "let me verify from scratch" pass means you're treating the trail as untrustworthy when it's authoritative.
-4. Route the remaining work to the matching playbook and pick the verdict: continue the execution, ship a finished recommendation, ratify or override a prior conclusion, or postmortem a failed run. The pickup playbook ends here. The routed playbook owns the rest.
-5. Verify the inherited claims against the original goal on the real artifact, as `principle-prove-it-works` requires; read its `SKILL.md` at its absolute resource path. A passing prior self-report is not the proof.
-
-**Reply:** where the prior agent stopped, what you inherited vs redid (ideally nothing redone), the resume point, and the outcome.