Turn a Manifest into a standalone goal defining what done means, in at most 4,000 characters. Use when the user wants to paste the work into a goal field without a Manifest file reference.
Installs into .claude/skills of the current project.
Are you the author of Manifest To Goal?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/doodledood-manifest-to-goal)
---
name: manifest-to-goal
description: 'Turn a Manifest into a standalone goal defining what done means, in at most 4,000 characters. Use when the user wants to paste the work into a goal field without a Manifest file reference.'
argument-hint: '<manifest path or inline text>'
user-invocable: true
---
Turn the supplied Manifest — the specification of what to deliver, what counts as done, and the constraints that hold throughout — into a standalone definition of done. Before drafting, invoke the prompt-engineering skill and apply its principles.
Read the whole Manifest and references needed to understand its intent and requirements. Use the Manifest identified in the request or conversation; ask which one if the target is missing or ambiguous. Apply explicit user amendments, distinguishing settled decisions from suggestions still under discussion. Ask a focused question only when an unresolved choice or contradiction would materially change the goal.
Write for an agent that will have neither the Manifest nor this conversation. Build upward from the finished outcome, adding the conditions that make it acceptable: deliverables, scope, consequential thresholds, quality bar, and delivery or authorization limits. Preserve source-grounded purpose and rationale that guide interpretation or trade-offs, and examples that define a meaningful boundary. Keep assumptions qualified. A retained detail must not revive a superseded goal.
Leave execution strategy to the agent, preserving methods only where they are binding requirements. Omit advisory implementation steps, derivable detail and repeated explanations that add no decision-relevant information. Synthesize related requirements without weakening their conditions. Use plain language in place of gate IDs and workflow jargon; inline essential requirements rather than sending the reader to the Manifest or another requirements document.
Make the successful end state and its proof explicit: carry the specified checks and pass conditions, including qualitative criteria, and require observed results to support completion. Concrete check commands and target artifact names may define success. Preserve supplied stopping limits and approval boundaries without inventing metrics, budgets, reporting formats or extra review gates.
Include execution policy only when specified by the source or user; omit policy already supplied by the known destination. Express retained behavior without depending on a Manifest-specific workflow. A generic execution contract is not required.
Check the draft against the complete source for lost obligations, invented requirements and conflicting scope. If fitting the goal would require a material scope decision, ask rather than conceal an omission.
Return one paragraph inside a single plain-text code fence, with no surrounding commentary. Count the goal text inside the fence programmatically, including spaces and punctuation, and revise until it is at most 4,000 characters; the ceiling is not a target. This invocation drafts text only: it does not edit the Manifest, set a running goal or begin the work it describes.
