Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/sapegin/dotfiles --skill to-specThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Based on SOC occupation classification
Showing SKILL.md
| name | to-spec |
| description | Turn the current conversation into a spec file. |
| disable-model-invocation | true |
Take the current conversation context and codebase understanding and produce a spec (you may know this document as a PRD). Do NOT interview the user — just synthesize what you already know. Do not invent requirements, affected users, motives, decisions, or constraints. Identify material missing information as unresolved in the appropriate section, and omit unsupported optional content.
Context.md exists in the current working directory, read it as working material. Treat the conversation as authoritative when they differ.Subject for the filename and document heading.specs folder, save the spec as specs/<subject-slug>.md, where <subject-slug> is the lowercase kebab-case form of Subject. Otherwise, save it as ~/murder/Specs/<Subject>.md, replacing characters unsuitable for a filename while preserving readable words and capitalization.Create only the destination file, not a missing specs folder. Never overwrite an existing spec; if the destination exists, preserve Subject and append a numeric suffix such as -2 before the filename extension. Replace the filename placeholder and the Subject heading with the chosen forms.
Summarize the problem, affected users, proposed outcome, and why it matters in a few short paragraphs.
Include this entire section only when the work changes user-facing behavior or involves business decisions that nontechnical stakeholders should review. Omit the heading and all of its subsections for purely technical work.
Keep this section brief. It is an overview for approval, not the technical plan translated into nontechnical language. Include only the most significant outcomes, constraints, trade-offs, scope boundaries, and unresolved questions — especially matters a stakeholder may object to or decide differently. Do not include architecture, modules, APIs, schemas, file paths, code, implementation steps, or exhaustive edge cases.
Describe the implementation work. Technical details belong here, not in the business specification.
A numbered list of concrete steps in implementation order. Make each step clear enough for a person or agent to execute without inferring missing work. Include dependencies, required decisions, data migration or rollout work, and validation where they belong in the sequence.
A list of implementation decisions that were made by the user. This can include:
Do not include specific file paths or code snippets. They may end up being outdated very quickly.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
Omit the heading and all of its subsections if there were no user decisions.
Known implementation risks, trade-offs, assumptions, and unresolved technical decisions.
Omit the heading and all of its subsections when there are none.