メニュー
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".