write-feature-request — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited write-feature-request (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use this skill to create high-quality, structured feature requests. It's most valuable when:
The skill runs in a multi-step conversation. At each step it asks focused questions, evaluates the quality of your answers, and only proceeds when it has enough information to produce excellent output.
Before starting: If the user's input reads as exploratory — vague problem description, no clear outcome defined, or language like "I'm thinking about..." or "wondering if we should..." — surface this before proceeding:
"If you're still exploring the problem space, /superpowers:brainstorming is a good first step — it sharpens the problem statement before we commit to a spec."If the user's input is specific and outcome-focused, skip the nudge and proceed directly.
Existing FR scan (silent): Before asking questions, scan for related work:
find . -maxdepth 4 \( -name "FR-*.md" -o -name "feature-request-*.md" \) 2>/dev/null | head -10If related FRs are found, surface them before proceeding: "I found [N] existing feature requests that may be related — [titles]. Is this a new spec, or should we update one of these?"
The skill collects four foundational inputs:
| Input | Questions Asked |
|---|---|
| Problem | What pain or gap exists? Who is affected? What is the evidence this is a real problem? |
| Solution | What do we want to build to solve it? What does it look like or do? What does it not do? |
| Outcomes | What customer value does this deliver? What changes for users if this is shipped? |
| Requirements | What must the feature do (functional) and how well must it do it (non-functional)? Each requirement is captured independently with its type. |
The skill accepts loose, conversational answers and structures them — you don't need to write formally.
For every requirement collected, the skill attempts to generate at least one concrete Acceptance Criterion (AC). A good AC must be:
If an AC cannot be written, it means the requirement is underdetermined. The skill will:
This loop continues until every requirement has at least one valid AC.
Once all ACs are validated, the skill assembles the complete FR in the output format below and returns it to the user.
The skill returns the FR in the following Markdown structure:
# [Feature Title]
## Problem
[Clear description of the problem, who it affects, and the evidence for it.]
## Solution
[Description of what will be built and its boundaries (what's in/out of scope).]
## Outcomes (Customer Value)
[What changes for users or the business if this feature ships. Written from the customer's perspective.]
## Requirements
### Functional Requirements
#### REQ-1: [Requirement Name]
> **Type**: Functional
[Description of the requirement]
| # | Acceptance Criterion | Notes |
|---|---|---|
| AC-1 | [Criterion] | [Optional context] |
| AC-2 | [Criterion] | [Optional context] |
#### REQ-2: [Requirement Name]
> **Type**: Functional
[Description]
| # | Acceptance Criterion | Notes |
|---|---|---|
| AC-1 | [Criterion] | |
### Non-Functional Requirements
#### NFR-1: [Requirement Name]
> **Type**: Non-Functional — [Performance | Security | Accessibility | Reliability | Scalability | Usability | Compliance]
[Description]
| # | Acceptance Criterion | Notes |
|---|---|---|
| AC-1 | [Criterion] | |
## Open Questions
| # | Question | Owner | Status |
|---|---|---|---|
| 1 | [Question] | [Role or person] | Open |
## Risks
| # | Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|---|
| 1 | [Risk description] | High / Medium / Low | High / Medium / Low | [Mitigation idea] |When generating ACs, the skill evaluates each requirement against the following:
| Dimension | Description | Failure Mode |
|---|---|---|
| Specificity | Is the behavior defined precisely enough that two people would interpret it the same way? | Vague verbs ("works well", "is fast", "feels intuitive") |
| Testability | Can QA write an automated or manual test that unambiguously passes or fails? | No clear trigger, action, or outcome described |
| Outcome-Focus | Does the AC describe what the user experiences, not how the system implements it? | Implementation details creep ("the database must use...") |
| Measurability | Are thresholds, counts, or time bounds specified where relevant? | Relative/subjective metrics ("significantly faster") |
| Severity | Meaning | Action |
|---|---|---|
| 🚫 Blocker | AC cannot be written at all — the requirement is too vague or contradictory | Skill pauses and requests clarification before continuing |
| ⚠️ Warning | AC can be written but with assumptions — assumptions are made explicit | Skill writes the AC with a note flagging the assumption |
| ✅ Pass | AC is fully deterministic and testable | AC is included in the FR |
The FR is only assembled when all requirements have at least one `✅ Pass` AC. Requirements with only ⚠️ Warning ACs are included, but assumptions are surfaced in the Open Questions section for the team to resolve.
When collecting requirements, the skill classifies each into a type. This classification is used to:
| Type | Description | Example |
|---|---|---|
| Functional | What the system must do | "Users can filter results by date range" |
| Performance | Speed, throughput, or latency targets | "The page loads in under 1.5s on a 4G connection" |
| Security | Access control, data protection, compliance | "Only the account owner can access billing records" |
| Accessibility | WCAG or assistive technology compliance | "All interactive elements are keyboard-navigable" |
| Reliability | Uptime, fault tolerance, error recovery | "The feature degrades gracefully on API timeout" |
| Scalability | Volume, concurrency, or growth targets | "Supports up to 10,000 concurrent users" |
| Usability | UX quality or learnability expectations | "A first-time user can complete the flow in under 2 minutes" |
| Compliance | Regulatory or legal requirements | "Meets GDPR data deletion requirements" |
After generating the FR, the skill automatically identifies:
1. Be rough with your inputs. The skill is designed to work with messy, incomplete thoughts — it will ask for what it needs.
2. Push back on vague requirements. If you find yourself answering "I'm not sure" more than twice about the same requirement, that requirement probably isn't ready and should become an open question.
3. Use NFRs deliberately. Most FRs are light on non-functional requirements, which causes surprises in implementation. The skill will prompt you to consider performance, security, and accessibility.
4. Treat the AC table as a contract. The AC table in the output is written to be directly usable as a QA checklist. Share it with engineering as-is.
5. Iterate fast. You can re-run Phase 2 on any single requirement by asking: "Rework the ACs for requirement [X]" — it will only regenerate that section.
Trigger:
"Help me write a feature request for letting users export their data"
Skill — Phase 1 Questions:
Let's build your FR. I'll start with the problem.
>
1. Problem: Who is asking to export data, and what are they trying to do with it that they can't do today? Is there any data (support tickets, churn signals, user feedback) that shows how often this is a pain point?
User:
Power users are asking us for a way to get their data out so they can do analysis in Excel. We get about 10 support requests a month for this and it consistently shows up in NPS verbatims.
Skill:
Got it. Now the solution.
>
2. Solution: What format should the export be in (CSV, JSON, Excel, all of the above)? What data is included — everything, or specific sections? Is this a one-time download or can they schedule recurring exports? Any data that should explicitly be excluded?
(... conversation continues through outcomes and requirements ...)
Skill — Phase 2, AC Blocker Example:
⚠️ I can't write a testable AC for requirement REQ-3: "Export should be fast" — "fast" is not measurable.
>
Can you tell me: - What's the maximum acceptable wait time for a user after clicking "Export"? - Does this vary by data volume (e.g., users with 10k rows vs. 1M rows)?
User:
Under 5 seconds for most users, maybe up to 30 seconds for large accounts.
Skill:
✅ Got it. I'll write two ACs: - AC-1: For accounts with fewer than 100,000 rows, the export file is available within 5 seconds of the user initiating the export. - AC-2: For accounts with 100,000 rows or more, the export is processed asynchronously and the user receives an email with a download link within 30 seconds.
(... continues until all requirements have ACs, then returns the full FR ...)
Ask your assistant to write a feature request by saying things like:
This skill will automatically, guide you through the conversation, and return a fully structured FR in Markdown.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.