Conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists. Use when defining new features, gathering requirements, or writing specifications. Invoke for feature definition, requirements gathering, user stories, EARS format specs, PRDs, acceptance criteria, or requirement matrices.
66
78%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/feature-forge/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly articulates specific deliverables, provides explicit trigger guidance with both 'Use when' and 'Invoke for' clauses, and covers a comprehensive set of natural keywords users would employ. The description is concise yet thorough, occupying a distinct niche in requirements engineering that would be easily distinguishable from other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'structured requirements workshops', 'feature specifications', 'user stories', 'EARS-format functional requirements', 'acceptance criteria', and 'implementation checklists'. These are all concrete, named deliverables. | 3 / 3 |
Completeness | Clearly answers both 'what' (conducts structured requirements workshops to produce feature specifications, user stories, EARS-format functional requirements, acceptance criteria, and implementation checklists) and 'when' (explicit 'Use when' and 'Invoke for' clauses with specific trigger scenarios). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'feature definition', 'requirements gathering', 'user stories', 'EARS format specs', 'PRDs', 'acceptance criteria', 'requirement matrices', 'specifications'. These cover a wide range of how users naturally phrase requirements-related requests. | 3 / 3 |
Distinctiveness Conflict Risk | Occupies a clear niche around requirements engineering and feature specification. The mention of EARS-format, requirements workshops, PRDs, and requirement matrices makes it highly distinctive and unlikely to conflict with general coding or documentation skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill demonstrates strong progressive disclosure with a well-organized reference table and clear structure. However, it falls short on actionability—the workflow steps are described at a high level without concrete examples of tool invocations or complete worked examples. The content could be tightened by removing obvious instructions and adding more specific, executable guidance for each workflow step.
Suggestions
Add a concrete worked example showing a complete mini-workshop cycle: a specific AskUserQuestions invocation with sample structured choices, a sample interview exchange, and the resulting EARS requirement—this would significantly boost actionability.
Add explicit validation checkpoints between workflow steps, such as 'Before proceeding to Document, verify you have: target users identified, at least 3 user stories, NFRs discussed' and 'If stakeholder rejects acceptance criteria in Validate, return to Interview step.'
Remove items Claude inherently knows from the MUST/MUST NOT lists (e.g., 'Ask for clarification on ambiguous requirements') to improve conciseness.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some unnecessary framing (e.g., 'Requirements specialist conducting structured workshops' role description, the 'When to Use This Skill' section largely restates the description). The MUST DO/MUST NOT DO lists have some items that are obvious to Claude (e.g., 'Ask for clarification on ambiguous requirements'). However, the reference table and inline examples are well-structured. | 2 / 3 |
Actionability | The workflow steps are named but lack concrete executable detail—there are no specific example prompts for AskUserQuestions, no sample structured choices, and the EARS/acceptance criteria examples are minimal templates rather than fully worked examples showing a complete feature spec. The guidance is directional rather than copy-paste ready. | 2 / 3 |
Workflow Clarity | The 5-step workflow is clearly sequenced and mentions validation (step 4), but lacks explicit checkpoints or feedback loops—there's no guidance on what to do if validation fails, no criteria for when discovery is 'complete enough' to proceed to documentation, and no verification that the final spec meets all required sections before saving. | 2 / 3 |
Progressive Disclosure | Excellent use of a reference table with clear 'Load When' conditions, pointing to five separate reference files for detailed guidance. The SKILL.md serves as a concise overview with inline examples for quick reference and one-level-deep pointers to detailed materials. Navigation is clear and well-signaled. | 3 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
e8be415
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.