Research source record — Cursor pstack skills

Historical research source record. This page preserves research; it is not approved policy, an implementation plan, or authorization to change skills, instructions, configuration, hooks, applications, ADRs, or specifications.

Record metadata

• Source task: Compare Cursor pstack skills
• Codex task ID: 01a0fdf6-a72b-7f00-aa15-5f68c77343db
• Research date: 2026-10-02 (America/New_York)
• Owning preservation ticket: #163
• Preserved completed turns: 3
• Retrieval completeness: read_thread returned hasMore: false and nextCursor: null for the pre-assignment history.

Preservation scope and limitations

The message text below is reproduced verbatim as returned by read_thread; the role and phase headings are preservation wrappers. All completed turns before the preservation assignment cutoff are included in chronological order. Later preservation or review turns are excluded. System/developer instructions, injected environment blocks, internal reasoning, secrets, unrelated task inventories, and wholesale third-party source files are not republished.

The source task used tool output as research evidence. Some raw command outputs were truncated at the source task's 20,000-character capture limit, and several outputs contained long copies of third-party or local instruction files. Those raw outputs are not reconstructed here. Reported revisions, measurements, experiments, qualifications, and source links remain in the preserved messages; selected meaningful output is recorded under Evidence and retrieval limits.

Turn 1 — Initial pstack evaluation

• Turn ID: 01a0fdf8-489a-7e93-887d-0b2f9779b871
• Started: 2026-10-02T18:55:02.000Z
• Completed: 2026-10-02T18:58:11.000Z

User message — verbatim

Can you evaluate these skills, and compare them to skills that we have, and how we can "borrow" from what is done here if you think there is value?  https://github.com/cursor/plugins/tree/main/pstack

Assistant commentary — verbatim

I’ll inspect the pstack skills, compare them with our installed skills, and identify useful ideas we could adapt. I’ll keep this to evaluation, with no installation or changes.

Assistant commentary 2 — verbatim

I’m using the plugin-management skill to guide the comparison. The GitHub page didn’t load through the browser tool, but the public GitHub API is accessible, so I can read the source directly.

Assistant commentary 3 — verbatim

The strongest additions so far are the focused workflows: tracing the evidence behind a design decision, checking what a diff could break beyond its callers, and keeping app-verification instructions current. Much of pstack’s general guidance overlaps with your existing rules. Some defaults also conflict with them, including broad agent fan-out and creating verification tools for ordinary work.

Assistant final answer 4 — verbatim

Yes—there is value here. I would borrow a few focused techniques, but I would not adopt pstack’s overall operating mode. Your existing skills and guardrails already cover much of its engineering philosophy, with tighter scope and authorization boundaries.

I inspected pstack v0.15.5, including its 47 main skill descriptions, the most relevant workflow bodies, selected references, and the separate Benny automation pack. I compared these with the installed catalog and relevant local skill files. This is a source review; I did not run or install pstack. Reviewed revision

pstack capability	What we already have	My assessment
why: reconstruct design rationale from history and other records	CodeGraph for code relationships; Git, tickets, and Wiki as evidence sources	High value. Its explicit separation of documented intent, inference, speculation, and unknowns would improve investigations.
blast-radius: investigate consequences beyond the diff	codex-security:assess-patch-risk already covers callers, contracts, state, regression protection, and recovery	Useful focused technique. Borrow its emphasis on testing the specific assumption that makes a change safe. A second comprehensive review skill would duplicate existing coverage.
create-verification-skill / maintain-verification-skill	macOS/iOS build and debugging skills, UI tools, repository QA requirements	High value for repeated app work. Adds a maintained recipe for exercising particular user journeys, beyond knowing how to launch and inspect an app.
how / teach	CodeGraph, explanation capabilities, visualize	Moderate value. Borrow explanation structure and audience awareness; little need for additional orchestration.
interrogate / arena / architect	Independent review requirements and risk-based architecture review	Selective value. Comparing alternatives can help a difficult design. Mandatory panels and repeated synthesis would add considerable overhead.
unslop / technical-writing	Your no-ai-slop skill and existing communication rules	Keep ours; borrow selectively. Ours better emphasizes preserving personal voice. Their distinction between tutorials, how-to guides, reference, and explanation is useful.
reflect / automate-me / recall	skill-creator, task-reading tools, existing ticket and handoff records	Moderate value. Useful patterns for learning from repeated corrections and reconstructing current state, provided they remain explicitly scoped.
TDD and 23 principle skills	Your testing, scope, simplicity, ownership, and verification rules	Mostly duplication. Several principles are good reminders, but installing each as a separate skill adds little.
Benny issue automation	Existing issue-driven development and QA roles	Future reference. Its ownership and existing-fix checks are useful; the Slack automation itself has no demonstrated need here.

The three things I would prioritize borrowing are:

1. Evidence-aware rationale investigations.
   why makes a valuable distinction: code establishes what happens; it does not establish why someone chose it. Its confidence framework separates direct evidence, supported conclusions, inference, speculation, and unknowns. It also converts historical findings into constraints for future changes: what to preserve, change, avoid, and investigate.

   I would adapt that into a small investigation skill that starts with the relevant code, Git history, ticket, and accepted decisions. Expand to other sources only when an unresolved question warrants it. pstack defaults to searching seven evidence categories with multiple agents, which is excessive for many questions. Source: why, confidence framework

2. App-specific verification recipes built on existing tools.
   The strongest practical contribution is a recipe covering launch, instance health, user actions, observable results, evidence, and cleanup. Each feature entry explains how a user reaches it and what proves success. The maintenance skill distinguishes outdated instructions, missing automation capability, and actual product defects.

   For our apps, I would use existing build commands and UI tooling, begin with a few important journeys, and update those recipes when affected behavior changes. This should remain a thin layer of project knowledge, not become a new testing framework or duplicate tracker. Source: verification creation, maintenance

3. Make a review’s decisive assumption explicit.
   blast-radius asks which fact the safety argument depends on, then seeks direct evidence for it. For example: “This cleanup is safe because it removes only expired entries.” A useful review would test expiration boundaries and active entries rather than merely list callers.

   Our existing patch-risk skill is more comprehensive. I would borrow this as a concise review question: “Which assumptions must hold, and what evidence supports them?” Keep plural assumptions possible; complicated changes rarely depend on just one. Source: blast-radius

The main reason to avoid wholesale adoption is procedural expansion. poteto-mode routes code crossing a function boundary into parallel architectural exploration, adds several pre-commit and pre-review workflows, and permits some external actions without asking. Its standalone autonomy principle treats external messages differently, creating an internal inconsistency. Those defaults conflict with your explicit scope and authorization rules. Source: poteto-mode, autonomy principle

Two other defaults are particularly poor fits:

• build-the-lever requires a tool artifact for almost any nontrivial work, even a one-off. Your proportionality rule is better suited to avoiding unnecessary infrastructure. Source
• show-me-your-work adds a decision log, transcript audit, and independent review of that trail. For Release Radar, this would compete with the ticket and current snapshot and conflict with your limits on reviewing process evidence. Source

Porting also requires deliberate adaptation: Cursor paths, task APIs, model identifiers, invocation metadata, and dependencies on other Cursor skills are embedded throughout. Copying the Markdown would not make those workflows work correctly in Codex.

My recommended first step is one bounded rationale-investigation skill, followed by an app-verification recipe only where repeated QA work demonstrates the need. Keep our existing writing and patch-risk skills. Any implementation should be separately scoped; this evaluation changed no files and created no temporary artifacts.

If we copy substantial text or code, pstack’s MIT license requires retaining its copyright and permission notice. Record the upstream revision alongside adapted material so future comparisons are straightforward. License

Turn 2 — Progressive-disclosure integration and priority correction

• Turn ID: 01a0fe08-1d38-71c3-a247-6cd939a2057d
• Started: 2026-10-02T19:12:19.000Z
• Completed: 2026-10-02T19:14:11.000Z

User message — verbatim

Ok, now review the findings in task --> "Plan workflow skill integration" and tell me if and if so, how, we should integrate, or further integrate/improve our approach to progressive disclosure.

Assistant commentary — verbatim

I’ll read “Plan workflow skill integration,” compare its findings with pstack and our current skill-authoring guidance, and recommend where progressive disclosure would help.

Assistant commentary 2 — verbatim

I’m using OpenAI Docs to check the current loading behavior. The integration task recommends portable methods with project-specific recipes; progressive disclosure fits that structure. The key is deciding what must be visible up front and giving each optional reference a clear reason to load.

User message 2 — verbatim

shit I forgot, how does it all fit in with the findings you previously presented.

Assistant commentary 3 — verbatim

I’ll include that connection. The integration task refines my earlier pstack assessment in two useful ways: acceptance verification should come first, and our formal patch-risk skill doesn’t replace lightweight review questions. Progressive disclosure should shape how we deliver those improvements without loading every method into every task.

Assistant final answer 4 — verbatim

Yes—we should strengthen progressive disclosure as part of the integration plan. It connects my earlier pstack findings with the recommendations in “Plan workflow skill integration”: add the useful methods, keep project knowledge in its authoritative location, and load detailed guidance only when the task needs it.

We already have this principle in Skill Creator. The opportunity is to apply it more consistently, rather than introduce another workflow framework.

The combined findings lead to this recommendation:

Earlier finding	Refinement from the integration task	How progressive disclosure fits
Borrow pstack’s app-verification recipes	Start with the complete requested outcome, including requirements absent from the implementation	Load the acceptance method first, then only the relevant project journeys and platform instructions
Borrow evidence-aware rationale investigation	Distinguish documented intent from demonstrated results; expand searches only for unresolved questions	Keep the evidence distinctions in the core skill; load source-specific investigation guidance as needed
Borrow the decisive-assumption question from blast-radius review	Our formal patch-risk assessment is too heavy for many ordinary reviews	Put the question in ordinary review guidance; retain formal assessment as a separately selected capability
Existing platform skills cover execution	They don’t fully supply a general debugging method	A debugging skill supplies hypothesis and experiment discipline; platform skills supply the needed execution mechanics
Much of pstack duplicates our rules	Some local skills also mix portable methods with changing project facts	Keep reusable methods portable and retrieve current facts from project records
Avoid adopting pstack’s operating mode	Validate individual improvements before broad adoption	Avoid a master skill that automatically invokes every other skill

I would revise my earlier priority order. I originally favored rationale investigation first. The integration task makes a stronger case for acceptance verification plus value-source checking first, because those address incomplete outcomes and unsupported implementation assumptions directly. Debugging and rationale investigation follow where recurring work justifies them.

Progressive disclosure should operate at these boundaries:

Layer	What belongs there	When it is needed
Governing instructions	Authority, scope, STOP, owner-data protection, required authorization	Available before consequential decisions
Skill description	The recognizable task and a precise selection trigger	During skill selection
SKILL.md	Essential method, decision points, relevant boundaries, completion condition	When that skill is selected
Supporting references	Substantial conditional procedures, examples, platform details	When a named condition applies
Project records and recipes	Actual commands, fixtures, user journeys, accepted constraints, current facts	For the affected project and behavior
Ticket or task results	What this run tested, observed, changed, or could not establish	During execution and handoff

Codex already supports loading skill metadata before full instructions. Current OpenAI guidance also recommends concise descriptions and routing substantial optional detail into references. This means we can use the existing mechanism without building a loader or orchestration layer. Official guidance

The most important improvements are:

1. Make every reference’s loading condition explicit.
   “See verification references” is weak routing. “For a persistence claim, read the project’s persistence recipe and verify the state after reopening” tells the agent when and why to read it. References should be directly discoverable, with minimal chains of intermediary documents.

2. Keep a short skill self-contained when that is simpler.
   Splitting a ten-line review technique into a router and three files makes it harder to use. Create separate references when they contain substantial detail that many invocations do not need. Separate skills should represent distinct user tasks; supporting details usually belong inside an existing skill.

3. Preserve complete acceptance coverage while narrowing procedural detail.
   This distinction is essential. An agent must inspect all applicable acceptance criteria before deciding which recipes to load. Otherwise, selective loading can hide the very omitted behavior that acceptance verification is meant to catch.

4. Keep safeguards visible before the actions they constrain.
   Authorization, owner-data boundaries, and STOP must not disappear into an optional appendix. Specialized instructions can explain how to perform an authorized operation, but cannot establish authority merely by being loaded.

5. Separate reusable knowledge from current state.
   A roadmap method can explain how to establish status; the actual phase and next milestone belong in current project records. Likewise, a verification recipe describes how to test; a ticket records whether a particular build passed. The integration task’s proposed treatment of Pursuit roadmap facts and RDS-specific ownership fits this distinction.

For example, verifying a Release Radar change could follow this sequence:

• Read the ticket’s complete acceptance criteria and applicable project constraints.
• Use the acceptance-verification method to identify the properties requiring evidence.
• Load the affected journey’s recipe.
• Load macOS execution guidance only if the verification requires it.
• Record results against the criteria, including missing, blocked, and unrun checks.

An unrelated deployment guide, historical investigation procedure, or full feature-map audit would not become necessary merely because it is linked somewhere.

The first pilot should therefore include progressive disclosure from the start: one concise acceptance-verification skill, a small project recipe where existing tests need supplementary guidance, and the value-source questions in the existing design record. No umbrella skill and no new orchestration scripts.

Evaluate whether it selects the right guidance, catches missing requirements, preserves authorization boundaries, and avoids irrelevant reads. Include a simple edit that should not activate the workflow and a case where the initially selected recipe proves insufficient. Fewer loaded words are useful only if correctness and completeness hold.

A broader reduction of the global instructions could be considered separately, but it should not be bundled into this pilot. That changes governance and needs its own explicit scope. No files or instructions were changed here.

Turn 3 — Proposed global-instruction and routing design

• Turn ID: 01a0fe0a-eb7c-7653-81ac-acd7df6ff1f8
• Started: 2026-10-02T19:15:23.000Z
• Completed: 2026-10-02T19:17:14.000Z

User message — verbatim

agreed but I don't see why we shouldn't investigate what that would be if we implemented your plan

Assistant commentary — verbatim

Agreed. Investigating the broader instruction changes now would make the plan more concrete without committing us to them. I’ll map what should stay always available, what could move into task-specific guidance, and how agents would reliably find it—then identify any risks or gaps before proposing edits.

Assistant commentary 2 — verbatim

I’m using Skill Creator’s guidance for this mapping. The global instructions contain substantial repetition around scope, proportionality, review, and completion. Release Radar already uses selective loading for Wiki standards. That suggests two different changes: consolidate repeated global rules, and move detailed procedures behind explicit task triggers while keeping their authorization boundaries visible.

Assistant final answer 3 — verbatim

You’re right. We can investigate the complete design now, including changes to the global instructions, while keeping implementation separate. My earlier response drew that boundary too early.

I inspected the actual global and Release Radar instructions, the Wiki routing structure, and the relevant local skills. The global AGENTS.md is 613 lines and 5,277 words. There is enough repeated guidance to justify consolidation before moving anything into additional files.

The proposed implementation would have three parts: consolidate global rules, selectively load procedures, and keep project facts with their projects.

Existing content	Proposed treatment	What remains visible up front
Instruction authority, guardrail integrity, untrusted content	Keep globally; consolidate repeated statements	What grants authority and what cannot override it
Scope authority, proportionality, complexity budget, scope tripwires	Combine into one concise section	Complete the requested outcome; add only necessary supporting work
Recursive verification, terminal validation, process limits, completion	Combine into one section	Required checks and review; no review of reviews; stop when satisfied
File safety, change attribution, source-of-truth discipline	Keep globally in condensed form	Preserve existing work, edit authoritative sources, avoid destructive shortcuts
Secrets and external side effects	Keep globally	Access and mutation boundaries before tools are used
Testing and evidence rules	Keep essential obligations globally; put substantial methods in the proposed verification skill	Test changed behavior; distinguish observed, failed, blocked, and untested claims
Retry and failure escalation	Keep a short global rule; debugging method supplies detail	Do not repeat failed actions without new evidence or broaden scope to solve environmental problems
Delegation and review	Keep authorization, ownership, independence, and risk triggers visible	Detailed assignment and role procedures load when those roles are used
/init augmentation	Keep the existing narrow trigger	Load the augmentation skill only after /init
CodeGraph	Keep its conditional discovery rule	Use it when the repository is indexed; no need for a separate skill
Platform commands, app journeys, roadmap facts	Keep in platform skills or canonical project references	A direct pointer and clear condition for reading them

The largest immediate gain would come from merging duplicate rules, not relocating every paragraph. For example, the global file currently explains several times that plans cannot expand scope, optional machinery should not become mandatory, and completed verification should not trigger more verification. Those protections should survive as clear requirements, without needing so many restatements.

A condensed global file would still cover:

1. Authority and untrusted content.
2. Complete outcomes, bounded scope, and proportional effort.
3. Authorization for external or destructive actions.
4. Preservation of user work, secrets, and authoritative sources.
5. Evidence, relevant verification, and independent review requirements.
6. Delegation ownership and inherited scope.
7. Retry, blocker, and completion behavior.
8. Durable artifacts and concise reporting.
9. Conditional routes such as /init and CodeGraph.

That is an organizational proposal, not a target word count or permission to drop requirements.

Progressive disclosure needs explicit routing to remain dependable.

Moving instructions into another Markdown file does not itself ensure they will be read. Codex discovers AGENTS.md through its instruction hierarchy; supporting references need discoverable links and instructions describing when they apply. Official instruction-discovery documentation

I would use two routing mechanisms:

• Required policy details: a governing instruction explicitly says when the reference must be read, before the affected action. A missing reference blocks that action, not unrelated work.
• Reusable methods: a precise skill description makes the method selectable for its task. Essential obligations still hold even if the method is not selected.

This prevents a dangerous outcome where moving a mandatory rule into an optional skill quietly makes it optional.

Release Radar already demonstrates useful routing. Its Wiki Home directs issue creation to the issue standard, coordination to the delegation model, and behavior changes to relevant specifications and their required dependencies. I would build on that existing structure.

For RR specifically:

• Keep ticket authority, STOP, role ownership, SQLite protection, review triggers, and release authorization boundaries in the repository instructions.
• Consider placing detailed model assignments and release execution steps in their appropriate canonical role references, with explicit pre-dispatch or pre-release loading requirements.
• Keep the prohibition on using RR’s product harness for repository development immediately visible.
• Preserve accepted ADRs unchanged.

The earlier skill recommendations then fit beneath those rules.

• acceptance-verification provides a method for covering the entire requested outcome, then loads only the affected project recipes.
• Value-source checking becomes a short design question in the existing assignment or specification guidance.
• systematic-debugging supplies hypothesis-driven investigation, calling on platform expertise when needed.
• decision-investigation supplies evidence and confidence distinctions, expanding sources only for unresolved questions.
• Ordinary review gains the safety-assumption question without automatically invoking formal patch-risk assessment.
• Pursuit roadmap facts move to current project records; RDS-specific authority stays with RDS.

There are two concrete migration hazards to address. First, augmenting-project-agents and rekon-roadmap-status exist on disk but are absent from this task’s available-skills catalog. We should verify how any required guidance becomes discoverable rather than assume installation is enough. Second, canonical source ownership for portable workflow assets remains undecided; plugin caches should not become their editable source of truth.

I would evaluate this as two separate changes: first consolidate duplicate wording while preserving obligations, then introduce selective loading and the new methods. That lets us distinguish a wording regression from a routing failure.

The checks should include a simple edit, an omitted acceptance criterion, a misleading bug symptom, missing required guidance, an unauthorized release action, and a task handoff. Success means correct behavior and preserved boundaries with less irrelevant guidance—not merely fewer words.

This investigation supports including the global-instruction redesign in the overall plan now. No governing files, skills, or project records were changed.

Evidence and retrieval limits

• The initial review identifies pstack v0.15.5 at commit 7022c81efb48d8b5eb15498ce6043a3bd74b694c, reports review of 47 main skill descriptions plus selected bodies/references and the Benny automation pack, and states that pstack was neither installed nor run.
• The second turn contains two user messages. Both are preserved because the second message changed the requested synthesis and led to the explicit priority correction from rationale investigation first to acceptance verification plus value-source checking first.
• The third turn reports the global instruction file as 613 lines and 5,277 words. This was a source-task measurement and was not remeasured during preservation.
• Multiple raw upstream skill reads were truncated at 20,000 characters. The source conclusions, cited revision, source links, and uncertainty remain intact; truncated third-party text was not reconstructed or republished.