Define goals
A collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.
npx -y skills add NjoyimPeguy/augments --skill define-goalsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use at the start of a new project or initiative — before scoping or building — to pin down what success means and its measurable criteria. Skip for a single feature; use interview-me for feature requirements.
SKILL.md
1.7 KB, as published. Nobody here has run it
Define Goals
A project without a clear goal ships features no one needed. Before scope or design, name the outcome — and how you'll know you hit it.
When to use
- Starting a new project, product, or substantial initiative with a fuzzy "why".
- Skip for a single feature or task — that's
interview-me's requirements job, not project goals.
Procedure
- Find the real objective. Ask "why this, why now?" until you reach an outcome, not a feature. A goal is something the world does differently afterward, not code that exists.
- Name the primary users or stakeholders and what changes for them.
- Make success measurable. For each goal, a criterion you could check later: a number, an observable behavior, a yes/no. "Users can X in under N seconds", not "better UX".
- State the value in one sentence — the elevator version.
- Write the
## Goalssection of the project brief — objective, users, success criteria, one-line value — to.augments/briefs/{{YYYY-MM-DD}}-{{topic}}.md(the standard briefs location; another path only if the user has set one).
With the goal agreed, the arc continues: feasibility-check if viability is genuinely uncertain, then scope-it to draw the boundary.
Common mistakes
- Listing features as goals — features are how; goals are what changes.
- Unmeasurable goals ("make it great") — if you can't check it later, it isn't a success criterion.
- Jumping to scope before the goal is agreed.