菜单
Workflow for drafting a tight, free-form issue — short, simple, focused on one thing. For bugs, captures what's broken and how to reproduce it (or where it was observed when it can't be reproduced). Use when the user asks to file, open, write, or draft an issue, bug report, or feature request.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/MQ37/poisson --skill create-issue命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Self-verification — spawn a fresh-context subagent to independently check that finished work actually satisfies the original request. Re-derives the task from a briefing you write (poisson subagents start with a blank conversation, not a copy of this one), re-reads the diff, runs build/tests, and returns a PASS/FAIL verdict. Use before declaring non-trivial work done, or when asked to check/verify/self-verify.
Universal code-quality principles for any language or codebase — simplicity, clarity, and minimalism in the spirit of the suckless manifesto, Linus Torvalds' "good taste", a hacker's distrust of complexity, and the conviction that one mind can understand the whole machine. Use proactively before writing functions, adding comments, handling errors, naming things, allocating resources, or opening a PR. Catches bloat, over-abstraction, AI-slop comments, over-defensive error handling, magic literals, deep nesting, leaked resources, needless dependencies, and code nobody fully understands.
General code review process — scan lenses (correctness, performance, edge cases, test coverage, security, API design, boundary/type cleanliness, orchestration/atomicity, ambitious simplification with a file-size ceiling and spaghetti-growth check, comment hygiene), verify every finding against the real code with subagents, re-evaluate severity against a presumptive-blockers bar, and optionally auto-apply real fixes (apply/escalate/skip). Diff-source-agnostic — works on a PR diff, a local branch diff, or a pasted change. Use when you want a thorough code review, not just a stacked-diff write-up.
正在显示 SKILL.md
| name | create-issue |
| description | Workflow for drafting a tight, free-form issue — short, simple, focused on one thing. For bugs, captures what's broken and how to reproduce it (or where it was observed when it can't be reproduced). Use when the user asks to file, open, write, or draft an issue, bug report, or feature request. |
"Debugging is twice as hard as writing the code in the first place." — Brian Kernighan
An issue exists so someone can act on it. Give them exactly what they need to act — no more. Write it free-form: there is no section ritual to satisfy. Use headings only when they help a reader skim; a good issue is often just a short paragraph.
One issue, one thing. If you're describing two problems, file two issues.
Keep it short. ≤30 lines for non-trivial, a few lines for the rest. The right size is where cutting one more sentence would lose information the fixer needs.
Never manually wrap lines. Write each paragraph as one long line — GitHub soft-wraps it for the reader. Hard-wrapping at ~70–80 chars only deforms the rendered body and the raw markdown.
A broken thing is self-justifying — don't write a business case for why a bug matters. A bug report needs exactly two things:
file:line), and paste the minimal snippet, error, or log line if you have it. The evidence is the snippet; don't restate it in prose.If you can't reproduce it, say so plainly and give where it was observed instead: the environment, the run/request/timestamp, a log excerpt, a link. "Seen once in prod, log attached, couldn't reproduce locally" is a complete, honest report — far more useful than a fabricated repro.
Do not pad a hard-to-reproduce bug with a speculative root-cause essay. A guess dressed up as analysis sends the fixer down the wrong path. If you have a real hunch, mark it as a hunch in one line and move on.
Say what you want, plainly. Add why only if it's non-obvious — and keep it to a sentence. If you propose a fix or approach, pick one; don't hand the reader a menu of options to choose from. Point at the relevant code so they can start.
| Pattern | Why |
|---|---|
| A justification essay for an obvious bug | The breakage is the justification |
| Invented / guessed reproduction steps | Worse than none — sends the fixer the wrong way |
| Speculative root-cause analysis padding a hard-to-repro bug | A guess dressed as fact wastes time |
| Multi-option fix menus ("Option 1… Option 2…") | Decide, or it's not actionable |
| "Acceptance criteria" on simple work | Implicit from a clear ask |
| Restating the snippet's meaning in prose | The reader can see the code |
| Marketing fluff ("improves developer experience") | Doesn't help the fixer |
| AI hedges ("this allows us to", "it should be noted") | Reads as slop |
Reproducible bug:
`parseConfig` (`config.ts:42`) swallows parse errors and returns null, so a malformed config looks identical to an empty one.
Repro: start with `config.json` = `{ "port": }` → server boots with defaults, no error logged.
Bug that can't be reproduced:
Checkout intermittently double-charges. Seen twice in prod (orders #4471, #4488; logs attached) — couldn't reproduce locally. Both hit the retry path in `payment.ts` within ~2s of a gateway timeout. Hunch: retry fires before the first charge settles, but unconfirmed.
Feature / change:
Add a `--dry-run` flag to the import command that prints what would change without writing. Entry point is `import.ts:20`.
create-pr skill — when you're opening the fix, not reporting it.code-quality skill — the principles a fixer will hold the change to.