CtrlK
BlogDocsLog inGet started
Tessl Logo

igmarin/agnostic-planning-skills

A curated library of 12 language-agnostic planning skills and 4 personas for technical project management, product planning, and agile execution.

91

1.16x
Quality

94%

Does it follow best practices?

Impact

91%

1.16x

Average score across 16 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

SKILL.mdskills/analysis/requirements-clarifier/

name:
requirements-clarifier
type:
atomic
license:
MIT
description:
Transforms vague task descriptions into actionable specifications with user stories acceptance criteria and identified edge cases — NEVER write implementation code or suggest solutions, do NOT edit project source files, do NOT produce implementation configuration or test cases, produce requirements only. Creating planning deliverables is permitted. Language-agnostic. Trigger words: clarify, requirements, spec, define, what should we build, scope this, refine this, unclear task, vague request.
metadata:
{"version":"1.0.0","user-invocable":"true","output":"Clarified requirements with user stories, acceptance criteria, edge cases, and open questions","constraints":"NO CODE — produces requirements only. Never implementation. Creating planning deliverables (documents, specifications) is permitted; editing project source/config/test files is prohibited."}

Requirements Clarifier

Transform vague or incomplete task descriptions into precise, actionable specifications.

Core principle: Before any implementation begins, requirements must be unambiguous enough that an engineer can build them and QA can test them.

Quick Reference

AspectRule
InputVague feature request, ambiguous task, incomplete description
OutputClarified requirements with user stories, acceptance criteria, edge cases, open questions
FormatStructured markdown — scannable, never prose-heavy
ScopeWHAT and WHY only. Never HOW.
Hard gateDo not write implementation code. Do not edit project source/config/test files. Creating requirements planning deliverables is permitted.

HARD-GATE

NO CODE — This skill produces requirements only.
Do not write implementation code, configuration, or test cases.
Do not edit project source, configuration, or test files. Creating planning deliverables (e.g., requirements documents, answer.md) is permitted.
If asked for implementation, respond: "I produce requirements, not code."

Core Process

  1. Analyze the request — Identify what is stated, what is implied, and what is missing.
  2. Ask clarifying questions — Surface ambiguities one group at a time:
    • Target users and actors
    • Success criteria and acceptance tests
    • Dependencies and integrations
    • Constraints (performance, security, compliance)
    • Out-of-scope boundaries
  3. Structure the output using this format:

Output Template

## Clarified Requirements

### Summary
One-paragraph synthesis of what is being asked.

### Scope
**In scope:** Bullet list of what this covers.
**Out of scope:** Bullet list of explicit exclusions.

### User Stories
- As a [user], I want [goal] so that [benefit]. *(Priority: P0/P1/P2)*

### Acceptance Criteria
**Story: [title]**
- [ ] Given [context] when [action] then [expected result]
- [ ] Given [context] when [action] then [expected result]

### Edge Cases & Constraints
- Technical: [performance, security, compatibility]
- Business: [compliance, localization, timing]
- Behavioral: [empty states, concurrent actions, invalid inputs]

### Open Questions
1. [Specific question that blocks implementation]
2. [Specific question that blocks implementation]
  1. Validate: Before submitting, verify:
    • Would an engineer know what to build?
    • Can QA write test cases from the acceptance criteria?
    • Are the 3 most likely edge cases identified?
    • Are questions specific enough to get actionable answers?

Guidelines & Pitfalls

GuidelineDetail
No fluffEvery sentence adds value. Eliminate filler.
Testable criteriaAcceptance criteria must be verifiable, not aspirational. Use "Given X, when Y, then Z" — never "works correctly" or "should".
Explicit boundariesState what is out of scope as clearly as what is in scope.
Proactive depthIf requirements are already clear, confirm understanding and ask if refinement is needed.
No implementation detailsOutput describes what, not how. Never write "use Redis" or "create a POST endpoint".
Edge cases are mandatoryThe most valuable part of this skill is identifying what can go wrong. Never leave the edge cases section empty or with fewer than 3 items.
Use the templateDo not merge clarifications into a prose blob. Scannability matters.
Watch for driftIf you find yourself writing production code, configuration files, or leaving open questions empty for a non-trivial request, stop and reset. Creating requirements documents and planning deliverables is expected.

Integration

SkillWhen to chain
create-prdAfter clarifying a feature request, draft the PRD
product-owner (persona)The product-owner persona invokes this in Phase 1 (Discovery)
tech-lead (persona)The tech-lead persona invokes this during feasibility assessment
generate-tasksAfter requirements are clear and approved, break into tasks

skills

analysis

requirements-clarifier

SKILL.md

README.md

tile.json