wwas

Overview of wwas skill

wwas is a prompt skill for writing product backlog items in Why-What-Acceptance format. Use the wwas skill when you need a backlog item that is more than a feature summary: it should explain the business reason, describe the change clearly, and define acceptance criteria that a team can test.

This is a strong fit for product managers, analysts, designers, and AI agents that need to turn rough feature ideas into sprint-ready work items. The real job-to-be-done is to preserve strategic context while keeping items independent, valuable, and negotiable. The wwas skill is especially useful when you want consistent backlog language across a team without over-specifying implementation.

What wwas is best for

wwas works best for feature breakdowns, incremental product delivery, and cross-functional planning where the team needs clarity on intent before code. It helps when your raw input is messy, such as a meeting note, a design link, or a half-formed request.

Why wwas is different

Compared with a generic prompt, wwas pushes the model to separate Why, What, and Acceptance Criteria. That reduces vague tickets, keeps scope smaller, and makes the output easier to review in planning. It also encourages items that can be ordered, estimated, and tested without turning the prompt into a full specification.

When wwas is a good install

Install wwas if your workflow depends on backlog hygiene, repeatable ticket quality, or AI-assisted requirements planning. It is most valuable when your team needs a shared format for Requirements Planning rather than one-off prose generation.

How to Use wwas skill

Install wwas and find the source files

Install the skill with npx skills add phuryn/pm-skills --skill wwas. Then read SKILL.md first, because it contains the workflow, item template, and argument list that shape wwas usage. If you are adapting it for your own process, also inspect the broader skill directory for any conventions in adjacent skills.

What to supply to wwas

wwas works best when you provide four inputs: product or system name, the feature or capability, a design link if available, and assumptions or strategic context. Weak inputs like “improve onboarding” usually produce vague acceptance criteria. Strong inputs sound like: product name, target user, desired outcome, and constraints.

How to write a better prompt

A good wwas prompt names the delivery unit and the business reason. For example: “Create a WWA item for the mobile checkout flow. Why: reduce cart abandonment for returning users. What: add saved payment selection, using the Figma link. Assumptions: authenticated users only, no new payment provider.” That gives the skill enough context to produce a usable backlog item, not just a polished paragraph.

Practical workflow for Requirements Planning

Use wwas after you have a feature direction, but before detailed specification. First, gather the rough request and any design or discovery notes. Second, run wwas to produce the Why-What-Acceptance structure. Third, review for independence, scope size, and testability. If the item still bundles multiple outcomes, split it and rerun wwas on the smaller unit.

wwas skill FAQ

Is wwas only for product managers?

No. The wwas skill is useful for anyone who needs Requirements Planning output that engineering and design can act on: PMs, business analysts, founders, delivery leads, and AI-assisted documentation workflows.

How is wwas different from a normal prompt?

A normal prompt may produce a descriptive feature note. wwas is narrower: it forces a backlog-item structure with strategic context, a concise feature description, and acceptance criteria that are observable. That usually means less cleanup after generation.

Do I need design files to use wwas?

No, but design links improve precision. If you do not have a design, provide enough context to define the user need, the boundary of the work, and the expected behavior. Without that, the skill may produce items that are too broad.

When should I not use wwas?

Do not use wwas when you need detailed technical design, implementation tasks, or release notes. It is a Requirements Planning tool, not a coding spec generator.

How to Improve wwas skill

Give it a sharper problem statement

The best wwas outputs start with a concrete user or business problem. Replace “add filters” with “help support agents find open cases faster in a high-volume queue.” That kind of input improves the Why section and prevents generic acceptance criteria.

State the boundaries early

wwas performs better when you say what is out of scope. If the feature is mobile-only, internal-only, or limited to one user segment, say so up front. This prevents acceptance criteria from drifting into unrelated cases.

Check for independence and testability

The most common failure mode in wwas usage is a backlog item that mixes multiple deliverables. If the output bundles UI, analytics, and permissions into one item, split those concerns and rerun the skill. Also verify that acceptance criteria describe outcomes you can observe, not implementation details.

Iterate using the first draft

Treat the first wwas output as a planning draft. If the Why is weak, feed back the business goal. If the What is too large, narrow the feature. If the acceptance criteria are too vague, add role, trigger, and expected result. That iteration loop usually improves the final Requirements Planning artifact more than adding more initial context.