sm:yagni

Require documented user evidence before staging implementation.

5|2|Updated Mar 8, 2026
One-click install
npx skills add https://github.com/mnfst-ai/Stage_Manager_Skills --skill sm-yagni
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sm:yagni
Source: https://github.com/mnfst-ai/Stage_Manager_Skills/tree/main/plugins/stage-manager/skills/yagni
Command: npx skills add https://github.com/mnfst-ai/Stage_Manager_Skills --skill sm-yagni

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

YAGNI prevents teams from moving into implementation based on untested assumptions by forcing a quick check for evidence and user contact before staging. It reduces wasted engineering effort, long-term maintenance costs, and product risk by ensuring decisions are grounded in observed user needs.

Core Features & Use Cases

  • Gatekeeping: Intervenes when a builder proposes starting work without documented validation.
  • Quick Triage: Asks one focused question to surface whether who was spoken to, what was found, and what signal justifies building.
  • Actionable Outcomes: If evidence exists, the skill clears the way; if not, it offers pathways to run invalidation prep, proceed with a visible YAGNI flag, or defer to a skip when appropriate.
  • Use Case: A developer suggests building feature X; YAGNI asks for validation, and either authorizes the build when evidence is provided or routes the team into an invalidation flow.

Quick Start

Ask the builder: Before we build — what did you find out, and who told you?

Frequently Asked Questions about sm:yagni

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent developers from building features without user validation?

Gating implementation requires teams to document who was interviewed, what user needs were discovered, and what validated signal justifies moving to code before staging begins.

What is the best way to stop untested assumptions from reaching the staging phase?

The best way to stop untested assumptions is applying a quick triage gate that asks builders what they found out and who told them, clearing the way only when documented evidence exists.

How do I triage a feature request to check for documented user research?

You triage a feature request by asking one focused question to surface whether the builder spoke to users, what they found, and what validated signal justifies building the feature now.

What should I do if a team member proposes starting implementation with no user contact?

If a team member proposes starting implementation with no user contact, you route them into an invalidation prep flow or defer the work until validated signals are gathered.

Can I proceed with coding if I attach a visible YAGNI flag instead of user research?

You can proceed with coding under a visible YAGNI flag when appropriate, but it marks the build as unvalidated, ensuring the team acknowledges the product risk of missing user research.