pstack
ChatGPT pluginEngineering agent workflows
- Featured
- No
not on the featured shelf
Movement
From our daily snapshots over the last 30 days.
Rank by placement
Rank in Developer tools
In its category
How this plugin compares with others in the same category. Positions are counted within the category, not across the whole directory.
Developer tools207th of 537 by placement
| # | Plugin | Position | 7d |
|---|---|---|---|
| 204 | #3148 | — | |
| 205 | #3162 | 107places down | |
| 206 | #3166 | — | |
| 207 | #3169 | — | |
| 208 | #3174 | — | |
| 209 | #3184 | — | |
| 210 | #3189 | — |
An unofficial ChatGPT port of pstack, providing rigorous reusable workflows for engineering, reasoning, review, and writing.
Example prompts
- “Explain how this subsystem works. Trace the code flow and flag the parts most likely to confuse developers.”
- “Review this PR for blast radius. Find what could break outside the diff and what still needs verification.”
- “Rewrite this to sound human. Keep the meaning and tone, but remove AI tells, filler, and generic phrasing.”
Skills
architect
Design types, interfaces, module boundaries, data flow, and ownership before implementation. Use for 'architect this', 'design this', API or domain modeling, refactors, new subsystems, or non-trivial changes where choosing the wrong shape would make the implementation harder.
blast-radius
Find what a code change could break outside the diff by tracing callers, contracts, shared data, external integrations, lifecycle behavior, and downstream consumers. Use for 'blast radius of X', 'what could this break', risky PR reviews, regression analysis, and checking whether a small change is actually isolated.
bro
Restate the last message in plain human language, with no jargon.
how
Explain how a codebase, subsystem, feature, API, or technical artifact works by inspecting the available source. Use for 'how does X work', code walkthroughs, runtime flows, architecture questions, ownership questions, and 'where should this live'.
principle-boundary-discipline
Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI, config, network, external APIs); trust internal types and keep business logic in pure functions.
principle-build-the-lever
Apply to any non-trivial work, not just bulk work: edits, migrations, analyses, checks. Build the tool that does it or proves it (codemod, script, generator, or a skill your subagents follow) instead of working by hand. The tool is the artifact a reviewer can rerun.
principle-encode-lessons-in-structure
Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text.
principle-exhaust-the-design-space
Apply when facing a novel UI interaction or architectural decision with no precedent in the codebase. Build 2-3 competing prototypes and compare side by side before committing.
principle-experience-first
Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones.
principle-fix-root-causes
Apply when debugging. Trace each symptom to its root cause and fix it there; reproduce first, ask why until you reach it, resist nil-check guards that silence crashes.
principle-foundational-thinking
Apply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share. Get the data structures right so downstream code becomes obvious.
principle-make-operations-idempotent
Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs.
Show all 26Show fewer
principle-migrate-callers-then-delete-legacy-apis
Apply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers.
principle-minimize-reader-load
Apply when reviewing or shaping code that's hard to trace. Count layers between question and answer, and hidden state in the reader's head; collapse one-caller wrappers and shrink mutable scope.
principle-model-the-domain
Apply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files. Encode the domain in a structure instead of scattered conditionals.
principle-prove-it-works
Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'
principle-redesign-from-first-principles
Apply when integrating a new requirement into an existing design. Redesign as if the requirement had been a foundational assumption from day one, instead of bolting it on.
principle-separate-before-serializing-shared-state
Apply when concurrent actors might write to the same file, branch, key, or state object. Eliminate the sharing first; serialize structurally only when one shared writer is a real invariant.
principle-subtract-before-you-add
Apply when sequencing an addition, refactor, or rewrite. Remove dead weight, redundant validators, and stub references first, then build on the simpler base.
principle-type-system-discipline
Apply when designing types, reviewing a function signature, or writing code in any statically-typed language. Make illegal states unrepresentable, brand semantic primitives, parse external data at boundaries, refuse to lie to the compiler, exhaust variants, derive from authoritative schemas.
recall
Reconstruct recent working context from prior conversations, remembered context, and connected project sources, then give a concise current-state brief. Use for 'recall my work on X', 'catch me up', 'what have I been working on', 'where did I leave off', or before resuming earlier work.
teach
Explain a codebase, subsystem, feature, change, or technical idea so the user actually understands it. Use for 'teach me this', 'help me understand X', 'explain this change', 'walk me through this', or when the user wants more than a reference answer.
technical-writing
Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.
typescript-best-practices
TypeScript best practices. Use when reading or editing any .ts or .tsx file.
unslop
Cut AI tells from any writing. Must always apply.
why
Investigate why a codebase, feature, design decision, threshold, workaround, or architectural choice exists by tracing evidence across the sources available to ChatGPT. Use for 'why does X work this way', 'why did we choose Y', design rationale, regressions, postmortems, historical context, and tradeoff questions.
- Categories
- Made by
- FetchUpstream · Website
- Sign-in
- On Install
- Availability
- Available
- Version
- 0.2.0
- Keywords
- pstack, workflow, engineering, writing, unslop
- Created
- August 19, 2026