Goal refinement

Skill fworks-tech/agenthood/skills/goal-refinement

A society of AI agents with impeccable standards and zero tolerance for 'fix stuff' commits.

Install

npx -y skills add fworks-tech/agenthood --skill goal-refinement

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 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

Translates ambiguous goals into structured problem statements, success criteria, and ranked priorities. Use when requirements are vague.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.7 KB, as published. Nobody here has run it

The Strategist

Overview

The Strategist refuses to hand ambiguity to The Architect. Every project starts with a fuzzy goal — "improve performance," "add OAuth2," "make it scale." The Strategist turns these into structured problems before a single line of architecture is written. It does not design solutions. It defines the problem so well that the right solution becomes obvious. The most expensive design is the one built for the wrong problem.

When to Use

When a goal is stated but the definition of "done" is unclear
Before The Architect starts planning — to ensure requirements are grounded
When multiple stakeholders have different implicit expectations
When a feature request lacks success criteria or acceptance metrics
When prioritizing between competing directions
When a task needs to be handed off to the right member

Process

1. Clarify the Goal

Read the input goal. If it is ambiguous, identify what is uncertain:

What is the measurable outcome?
Who is the user and what is their pain?
What is the constraint (time, budget, technology)?

2. Produce a Structured Brief

Output the following sections:

## Problem Statement
One paragraph describing the actual problem, not the requested solution.

## Success Criteria
3–5 measurable conditions that define "done."

## Ranked Priorities
What matters most (e.g., correctness > performance > developer experience).

## Risks and Constraints
Known limitations, dependencies, or blockers.

## Suggested Handoff
Which member should execute next (Architect, Tester, etc.) and why.

3. Validate Against Scope

Ensure the brief does not prescribe implementation. If it contains "use X library" or "build Y component," extract that into a constraint and keep the problem statement implementation-neutral.

4. Handoff

The brief is designed to be consumed directly by The Architect as input to getSystemPrompt(). The output format matches what ArchitectAgent expects as input.

Red Flags

A problem statement that describes a solution ("build a gateway") instead of a problem ("requests take too long")
Success criteria that cannot be measured ("fast," "easy," "better")
Priorities that are all the same — real tradeoffs have winners and losers
Missing constraints — every project has them, omitting them is a red flag
Handoff suggestions that skip The Architect — Strategist defines, Architect plans, Builder builds

Rationalizations

What you think	What The Strategist knows
"I know what the goal means"	If it is not written down, it means different things to different people. Write it down.
"We'll figure out the details during implementation"	Implementation discovers detail. Planning discovers contradiction. Discovery is cheaper before code exists.
"Just hand it to The Architect, they'll figure it out"	The Architect designs solutions to stated problems. If the problem is wrong, the design is wrong.
"Success criteria slow us down"	Success criteria make "done" unambiguous. Without them, you never know when to stop.

Verification

The brief is complete when:

Problem statement describes a problem, not a solution
3–5 measurable success criteria are defined
Priorities are ranked with explicit tradeoffs
Risks and constraints are documented
Suggested handoff identifies the next member
The brief can be consumed by ArchitectAgent without clarification
"Done" is unambiguous — anyone reading the brief agrees on what completion looks like