菜单
Pick one open task and implement it end-to-end as a unit of work. Use when the user asks to pick a task.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Render a document, a diagram, or a report as HTML for human visualisation.
Use when writing prose meant to read by humans: PR descriptions, docs, blog drafts, emails, design memos
Guidelines on creating issues on GitHub
Run a premortem on any plan, launch, product, hire, strategy, or decision. Assumes it already failed 6 months from now and works backward to find every reason why. Produces a revised plan with blind spots exposed. MANDATORY TRIGGERS: 'premortem this', 'premortem my', 'run a premortem', 'what could kill this', 'future-proof this', 'stress test this plan', 'what am i missing here', 'find the blind spots'. STRONG TRIGGERS: 'what could go wrong', 'am i missing anything', 'poke holes in this', 'where will this break', 'devil's advocate this'. Do NOT trigger on simple feedback requests, or factual questions. DO trigger when someone has a plan or commitment where the cost of being wrong is high.
Schedule a prompt to fire back at yourself at a future time or on a recurring cron pattern. Use when the user says "remind me", "every N minutes/hours/days", "at HH:MM tomorrow", "check X periodically", or otherwise asks for any time-based action. Triggered by the `schedule` tool plus the `/schedule` command for listing and deletion.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get roasted on their design, or mentions "brainstorm".
| name | work |
| description | Pick one open task and implement it end-to-end as a unit of work. Use when the user asks to pick a task. |
| user-invocable | true |
Task management is done with beans:
!beans prime
Do the following, in this specific order:
.beans/). Do not use beans query GraphQL mutations for updates — direct edits are simpler, easier to review in the diff, and avoid quoting issues. The CLI's beans update flags are fine for status-only changes; longer body edits go through Edit on the bean file.Use semantic commit messages with the following format:
<body>
Closes <bean ID>
The <body> should be short & concise (1-2 paragraphs at most), describing why the work was done, not what (that's in the code itself).
If the why can be trivally inferred from the bean contents, omit it entirely. Only add relevant context you encountered while doing the work, such as design decisions, tradeoffs, or implementation details that aren't obvious from the code itself.
The Closes <bean ID> line is important for traceability and automation.
When writing memories, extract the core lesson learned, don't focus on specific implementation details that can go stale. Use positive reinforcement phrasing: "when doing X, prefer using Y", rather than "don't do Z".