菜单
Use when a session is working under Structured-Prompt-Driven Development (SPDD), when prompts/specs must be versioned delivery artifacts, or when logic-heavy changes need a prompt-first closed loop.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The Pat Helland lens: treat durable data as immutable, append-only facts that carry their own identity and version; and design across service, machine, or org boundaries assuming you cannot have distributed transactions — only idempotent, at-least-once messages that must be reconciled. Apply this on in-place updates and overwrites, "just UPDATE the row," two-phase commit or distributed transactions at scale, exactly-once delivery assumptions, shared mutable state across services, and any data that crosses a boundary of service, machine, org, or time. Trigger even when Helland isn't named — the smell is mutation-in-place and pretending distributed systems can be transactional.
The Rich Hickey lens: pursue simple (un-braided, one role) over easy (familiar, near-at-hand), decomplect concerns that got tangled together, and separate value, identity, state, and time. Apply this whenever "easy," "convenient," or "it's what we already use" is doing the work of justifying a design; when state is braided into logic, policy into mechanism, or data into behavior; when object-soup would be plainer as data; and when a hard design decision is being made at the keyboard under time pressure instead of thought through first. Trigger even when Hickey isn't named — the smell is complecting, and confusing "easy" with "simple."
The John Carmack lens: minimize the mutable state you have to reason about, do the simple thing before the clever one, and treat correctness tooling — static analysis, warnings-as-errors, determinism — as non-negotiable. Apply this on sprawling mutable state, "we'll clean it up later," debugging by print- statement whack-a-mole, silenced compiler warnings, nondeterministic or non-reproducible behavior, premature abstraction, perf work that skips measurement, and any "what should we actually work on" prioritization call. Trigger even when Carmack isn't named — the smell is code whose full set of states you can't hold in your head, and effort that isn't ruthlessly focused.
The Fabrice Bellard lens: build the smallest self-contained thing that fully does the job, get performance from insight instead of hardware, and reuse existing machinery instead of reinventing it. Apply this whenever code is growing dependencies, frameworks, services, or infrastructure to solve a problem that a smaller, sharper implementation could handle — or whenever someone says a thing needs a cluster, a big framework, or a rewrite. Use for size/complexity audits, "do we really need this dependency/service?" questions, performance work where the reflex is to add hardware or caching, green-field "should this be one file or a platform?" decisions, and any moment the answer is trending toward "that's impractical, you'd need X." Trigger even when the user doesn't name Bellard — the smell is scope inflation and reaching for resources over insight.
Use when iteratively researching a topic and filing the synthesis into an Obsidian vault for later ingestion. Output goes to `<vault>/raw/` (NOT directly into wiki pages) so that `vault-ingest` can process it on its own schedule. Triggers: '/vault-autoresearch', 'autoresearch [topic]', 'research [topic] into the vault', 'deep dive into [topic]', 'find everything about [topic] for the vault', 'research and stage'.
Ingest sources into the Obsidian wiki vault. Reads a source, extracts entities and concepts, creates or updates wiki pages, cross-references, and logs the operation. Supports files, URLs, and batch mode. Triggers on: ingest, process this source, add this to the wiki, read and file this, batch ingest, ingest all of these, ingest this url.
| name | using-spdd |
| version | 0.1.0 |
| targets | ["claude-code","codex","gemini","pi"] |
| type | skill |
| description | Use when a session is working under Structured-Prompt-Driven Development (SPDD), when prompts/specs must be versioned delivery artifacts, or when logic-heavy changes need a prompt-first closed loop. |
| category | {"primary":"workflow","secondary":["backpressure"]} |
Structured-Prompt-Driven Development (SPDD) treats prompts as first-class delivery artifacts: versioned, reviewed, reused, and kept in sync with code.
Announce at start: "I'm using the using-spdd skill to keep prompt assets and code in a closed loop."
Use SPDD for logic-heavy, audit-heavy, team-shared, or repeatable delivery work where intent drift is expensive. Avoid it for emergency recovery, throwaway spikes, one-off scripts, or taste-led creative work unless the user explicitly wants the governance overhead.
spdd-alignment before design or code.spdd-analysis against only relevant code and domain artifacts.spdd-reasons-canvas before implementation.spdd-generate; no scope beyond Operations, Norms, and Safeguards.spdd-iterative-review.spdd-prompt-update, then update code.spdd-sync.Default location: docs/superpowers/spdd/YYYY-MM-DD-<slug>/.
A complete SPDD slice has:
story.md or linked requirement source.analysis.md for domain concepts, risks, scope, and strategy.reasons-canvas.md as the executable prompt/spec.verification.md or test script notes mapping behavior to acceptance criteria.Keep artifacts current in the same branch as the code they govern. Never let chat-only instructions replace the canvas.
When reality diverges, classify the divergence before changing anything:
Reviewers should check the intent artifact before the diff. A code change is not ready if the code passes tests but the canvas no longer describes what the system does.