| name | red-hat-agile-skill |
| description | Generate structured agile project plans with Epics, Stories, and Tasks — each with Acceptance Criteria, Definition of Done, and intrinsic value statements. Uses thinking frameworks (First Principles, Dialectical, Six Hats) as multi-agent teams to ensure plans are grounded in real user needs rather than inherited assumptions. Use this skill whenever the user asks to create a project plan, break down a project into epics and stories, generate a backlog, plan a sprint, decompose requirements into agile artifacts, write acceptance criteria, define done, or wants to understand the value of their work items. Also trigger when users say things like "plan this project", "create stories for", "break this into tasks", "what epics do we need", "build me a backlog", "write acceptance criteria", "define done for", or "help me plan this feature". Even if the user doesn't explicitly say "agile" — if they're asking for structured work decomposition with clear deliverables, this skill applies.
|
Red Hat Agile Skill
Generate rigorous agile project plans where every item — Epic, Story, Task — has clear
Acceptance Criteria, a Definition of Done, and an articulated intrinsic value. The process
uses structured thinking frameworks to ensure the plan is grounded in real needs, not
inherited assumptions or wishful thinking.
Why This Exists
Most agile plans fail in one of four ways:
- Assumption inheritance — Stories decompose what was asked for, not what's actually needed
- Blurry acceptance — "This story works" is never defined in testable terms, so QA and dev disagree mid-sprint
- Missing "done" — Teams argue about completeness because DoD was vague or absent
- No independent value — Items only make sense as part of a chain, making prioritization impossible
This skill addresses all four by running the project vision through structured thinking
before any decomposition begins, and by treating Acceptance Criteria (per-story) and
Definition of Done (universal) as distinct artifacts.
Process Overview
Three phases, each using a different thinking framework adapted for agile planning:
Project Vision
|
v
Phase 1: DISCOVERY (First Principles)
Strip to fundamental truths → Build epic structure from bedrock
|
v
Phase 2: ELABORATION (Dialectical per Epic)
Advocate story breakdown → Challenge completeness → Integrate with AC + DoD + value
|
v
Phase 3: VALIDATION (Six Hats — abbreviated)
Facts → Risks → Value → Gut check → Final plan
|
v
Agile Project Plan
Epics > Stories > Tasks
Each with DoD + Intrinsic Value
Before You Begin
Gather Context
Before running the frameworks, collect this from the user (ask if not provided):
- Project Vision — What are we building and why? (1-3 sentences is fine)
- Target Users — Who benefits from this?
- Known Constraints — Budget, timeline, technology, regulatory, team size
- Success Criteria — How will we know this project succeeded?
- Existing Context — Any prior work, documents, or decisions already made
If the user gives you a brief prompt like "plan a customer portal", that's enough to start —
use the Discovery phase to flesh out the rest. Don't block on having perfect inputs.
Phase 1: Discovery (First Principles)
Goal: Strip the project vision to fundamental user needs and business truths, then
build an epic structure from only those truths.
Why this matters: If you skip this and jump straight to "what epics do we need?",
you'll inherit every assumption baked into the original description. First Principles
forces you to ask "what do users actually need?" before "what should we build?"
Read references/discovery-agents.md for agent prompts and orchestration.
Agent Chain
Project Vision + Constraints
|
v
Vision Archaeologist → Fundamental truths + assumption map
|
| truths ONLY (no original vision description)
v
Scope Architect → Epic structure from bedrock truths
|
| both original + reconstruction
v
Coverage Evaluator → Validated epic list with gap analysis
Information Barrier (Critical)
The Scope Architect must NOT see the original project vision or description. It receives
ONLY the fundamental truths from the Archaeologist. This prevents anchoring — the epic
structure should emerge from user needs, not from how the project was described.
Phase 1 Output
A validated list of Epics, each with:
- A clear scope boundary
- The fundamental truths it addresses
- A preliminary intrinsic value statement
Phase 2: Elaboration (Dialectical per Epic)
Goal: For each Epic, generate Stories and Tasks through structured debate. Each story
gets Acceptance Criteria (story-specific, testable behaviors), compliance with the
project-level Definition of Done (universal quality bar), and an intrinsic value
statement.
Why this matters: A single pass at story decomposition tends to produce either too-thin
slices (tasks disguised as stories) or too-thick slices (epics disguised as stories). It
also tends to blur acceptance — teams conflate "this specific story's behavior is correct"
(AC) with "this story meets our team's quality bar" (DoD), leading to sprint-time fights
about what "done" means. The dialectical process catches all three failure modes.
Read references/decomposition-agents.md for agent prompts and orchestration.
Agent Chain (runs once per Epic)
Epic Definition + Fundamental Truths + Project DoD
|
v
Story Advocate → Proposed stories with AC + DoD-fit + value
|
v
Story Challenger → Critique: INVEST, AC gaps, DoD-fit gaps, value gaps
|
v
Story Integrator → Final stories with refined AC + value (DoD applies universally)
|
v
Task Decomposition → Tasks per story with completion criteria
INVEST Criteria (enforced by the Challenger)
Every Story must be:
- Independent — deliverable without requiring other stories to be done first
- Negotiable — describes the what, not the how
- Valuable — delivers intrinsic value (see Value Framework below)
- Estimable — team can reasonably estimate effort
- Small — completable within a single sprint
- Testable — DoD is verifiable and unambiguous
Phase 2 Output
For each Epic:
- Stories with Acceptance Criteria (Given/When/Then), intrinsic value, and a DoD-fit check
- Tasks per story with completion criteria
- Dependency map (which stories/tasks block others)
A project-level Definition of Done (the universal quality bar applied to every story)
is defined once, near the top of the plan — not repeated per story.
Phase 3: Validation (Six Hats — Abbreviated)
Goal: Stress-test the complete plan from four perspectives before delivering it.
Why this matters: Phases 1 and 2 focus on structure and correctness. Phase 3 asks
"will this actually work in the real world?" — surfacing risks, confirming value, and
checking stakeholder readiness.
Read references/validation-agents.md for agent prompts and orchestration.
Agent Chain
Complete Plan (Epics + Stories + Tasks)
|
v
White Hat → Completeness check: gaps, missing requirements, data quality
|
v
Black Hat → Risk assessment: what threatens this plan?
|
v
Yellow Hat → Value validation: does the total value justify the effort?
|
v
Red Hat → Stakeholder gut check: will the org accept this?
|
v
Blue Hat → Synthesis: final adjustments + delivery recommendation
Phase 3 Output
- Risk register with mitigations
- Value summary (total intrinsic value across all items)
- Stakeholder readiness assessment
- Recommended iteration order (which epics/stories to tackle first)
Intrinsic Value Framework
Every Epic, Story, and Task should articulate its intrinsic value — the worth it delivers
independently, even if no other item in the plan existed.
Read references/output-templates.md for the full value framework and templates.
Value Dimensions
| Dimension | Question It Answers | Example |
|---|
| User Impact | How does this directly improve a user's life? | "Users can reset passwords without calling support" |
| Business Impact | What business outcome does this enable? | "Reduces support tickets by ~30%" |
| Technical Impact | What capability or quality does this create? | "Establishes the authentication foundation other features build on" |
| Learning Impact | What uncertainty does this reduce? | "Validates that our SSO integration approach works with the customer's IdP" |
Value Levels by Item Type
- Epic Value — Strategic: answers "why does this capability matter?"
- Story Value — Tactical: answers "what specific benefit does shipping this deliver?"
- Task Value — Operational: answers "why is this work necessary?" (tasks may reference their parent story's value when they don't carry independent value)
Tasks are the one level where intrinsic value can be inherited — a database migration task
may not have standalone user value, but it should still articulate why it's necessary
("enables the new schema required for feature X").
Acceptance Criteria & Definition of Done Framework
Acceptance Criteria (AC) and Definition of Done (DoD) are two distinct artifacts. Teams
that conflate them end up arguing during sprint review about whether a story is "done,"
because there's no shared contract for either what this story must do or what every
story must satisfy.
The Distinction
| Acceptance Criteria (AC) | Definition of Done (DoD) |
|---|
| Scope | Specific to this story | Universal — applies to every story |
| Answers | "Is this story's behavior correct?" | "Has this story met our quality bar?" |
| Form | Given/When/Then scenarios (preferred) or numbered testable statements | Checklist of team standards |
| Owned by | PO / BA, reviewed with QA | The team (engineering + QA + ops) |
| Changes per story? | Yes — every story has its own | No — set once per team/project, revisited rarely |
| Example | "Given a locked account, when the user submits valid credentials, then the system returns 403 with message 'Account locked. Try again in 15 minutes.'" | "All unit tests pass in CI; code reviewed by ≥1 teammate; feature flag configured; docs updated." |
A story is accepted when its AC pass. A story is done when it's accepted AND the
project DoD is satisfied.
Acceptance Criteria Quality Checklist
Good AC items answer YES to all of these:
- Written from the user/system perspective (observable behavior, not implementation)
- Covers the happy path, error paths, and at least one boundary/edge case
- Unambiguous — one interpretation only
- Testable — a QA engineer can write an automated or manual test directly from it
- Scoped to this story — doesn't drag in behaviors that belong to another story
Preferred format: Given / When / Then (Gherkin-style)
Scenario: User logs in with valid credentials
Given a registered user with email "user@example.com" and password "correct-pw"
When they submit the login form
Then they receive a JWT with a 24-hour expiry
And they are redirected to /dashboard
Plain testable statements are also acceptable when Given/When/Then feels forced (e.g., for
infrastructure stories): "The migration script runs idempotently — re-running it produces
no schema changes and no data loss."
Project Definition of Done
Defined once for the whole plan, near the top. Every story inherits this DoD implicitly.
Typical items:
- Code reviewed and approved by ≥1 teammate
- Unit tests present; CI pipeline passes (lint, test, build, security scan)
- Integration test covers the primary flow
- User-facing changes documented (release notes, help docs, runbook as applicable)
- Deployed to staging; smoke test passes
- Feature flag configured when rollout is risky
- No new accessibility or security regressions introduced
Teams may extend this — but the list should be short, stable, and universally applicable.
If a criterion only applies to some stories, it belongs in AC, not DoD.
Bad vs Good AC Examples
| Bad (blurs AC and DoD, or is vague) | Good (clean AC) |
|---|
| "User authentication works" | "Given valid email+password, when the user submits, then they receive a JWT and land on /dashboard. Given invalid credentials, then the response is 401 with message 'Invalid email or password.' Given 5 failed attempts in 15 min, then the account is locked for 15 min and a 403 is returned." |
| "Tests pass and code is reviewed" | (this is DoD, not AC — move it to the project DoD) |
| "Performance is acceptable" | "The login endpoint returns a response within 200ms (P95) under a load of 100 concurrent requests, validated by the load-test suite." |
Output Format
The final deliverable is a structured agile project plan. Use this hierarchy:
Read references/output-templates.md for the complete templates with all fields.
Summary Structure
# Project Plan: [Project Name]
## Vision Summary
[2-3 sentences from Discovery phase]
## Fundamental Truths
[Numbered list from Archaeologist]
## Project Definition of Done
[The universal quality bar applied to every story in this plan. Defined once here.]
- [ ] [team standard 1]
- [ ] [team standard 2]
- ...
## Epic Overview
| # | Epic | Stories | Intrinsic Value (1-line) | Priority |
|---|------|---------|--------------------------|----------|
## Detailed Breakdown
### Epic 1: [Name]
**Intrinsic Value:** [value statement]
**Epic-Level DoD:** [rollup criteria specific to the epic — e.g., "all stories accepted, end-to-end flow demoed"]
#### Story 1.1: [Name]
**Intrinsic Value:** [value statement]
**Acceptance Criteria:**
- Scenario 1: Given... When... Then...
- Scenario 2: Given... When... Then...
- Edge case: Given... When... Then...
**DoD Fit:** [confirm the project DoD applies cleanly; note any story-specific
additions such as "also requires a data migration runbook"]
**Tasks:**
| # | Task | Completion Criterion | Estimate |
|---|------|---------------------|----------|
[...repeat for all stories and epics...]
## Validation Summary
### Risks
### Value Map
### Recommended Iteration Order
### Stakeholder Readiness
Practical Guidance
Scope Calibration
The depth of analysis should match the project size:
| Project Size | Discovery | Elaboration | Validation |
|---|
| Small (1-2 sprints) | Light: skip Scope Architect, go straight from truths to stories | Single pass per epic | White + Black hats only |
| Medium (1-3 months) | Full 3-agent chain | Full dialectical per epic | All 5 hats |
| Large (3+ months) | Full chain + multi-cycle | Full dialectical + cross-epic dependency analysis | All 5 hats + recommended phasing |
When to Stop Decomposing
- Epics should be deliverable in 1-3 sprints (2-6 weeks of work)
- Stories should be completable in a single sprint (1-2 weeks)
- Tasks should be completable in 1-3 days
- If a task takes longer than 3 days, it's probably a story
Common Pitfalls
| Pitfall | How This Skill Prevents It |
|---|
| Feature factory (building without purpose) | Every item must articulate intrinsic value |
| Scope creep disguised as stories | Challenger agent enforces INVEST + traces back to fundamental truths |
| "Done" means different things to different people | Project DoD is defined once and universal; per-story AC is testable and story-scoped — both checked by the Challenger |
| Analysis paralysis | Scope calibration table right-sizes the process |
| Dependency spaghetti | Stories must be Independent (INVEST); dependencies are explicitly mapped |
Reference Files
Read the appropriate reference file BEFORE spawning agents:
| File | Contents | When to Read |
|---|
references/discovery-agents.md | Vision Archaeologist, Scope Architect, Coverage Evaluator prompts | Phase 1: before decomposing the project vision |
references/decomposition-agents.md | Story Advocate, Story Challenger, Story Integrator, Task Decomposer prompts | Phase 2: before elaborating each epic |
references/validation-agents.md | White, Black, Yellow, Red, Blue hat prompts adapted for plan validation | Phase 3: before validating the complete plan |
references/output-templates.md | Complete templates for Epics, Stories, Tasks + Value Framework details | When producing the final output |
