speckit-specify — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited speckit-specify (Agent Skill) and scored it 75/100 (yellow). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 6 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 6 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
A bulleted imperative like {match} tells the agent to never reveal, disclose, or mention something to the user. Used adversarially it can instruct the agent to hide its tool calls or lie about what it did — stripping the transparency a user relies on to trust the agent.
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.
.specify/ scripts and templates.If the description is missing or unclear, ask a targeted question before continuing.
The user's feature description in the request is the input. Do not ask them to repeat it unless it is missing.
Given that feature description, do this:
a. First, fetch all remote branches to ensure we have the latest information:
git fetch --all --pruneb. Find the highest feature number across all sources for the short-name:
git ls-remote --heads origin | grep -E 'refs/heads/[0-9]+-<short-name>$'git branch | grep -E '^[* ]*[0-9]+-<short-name>$'specs/[0-9]+-<short-name>c. Determine the next available number:
d. Run the script .specify/scripts/bash/create-new-feature.sh --json "<feature description>" with the calculated number and short-name:
--number N+1 and --short-name "your-short-name" along with the feature description.specify/scripts/bash/create-new-feature.sh --json --number 5 --short-name "user-auth" "Add user authentication".specify/scripts/bash/create-new-feature.sh -Json -Number 5 -ShortName "user-auth" "Add user authentication"IMPORTANT:
.specify/templates/spec-template.md to understand required sections.If empty: ERROR "No feature description provided"
Identify: actors, actions, data, constraints
If no clear user flow: ERROR "Cannot determine user scenarios"
Each requirement must be testable Use reasonable defaults for unspecified details (document assumptions in Assumptions section)
Create measurable, technology-agnostic outcomes Include both quantitative metrics (time, performance, volume) and qualitative measures (user satisfaction, task completion) Each criterion must be verifiable without implementation details
a. Create Spec Quality Checklist: Generate a checklist file at FEATURE_DIR/checklists/requirements.md using the checklist template structure with these validation items:
# Specification Quality Checklist: [FEATURE NAME]
**Purpose**: Validate specification completeness and quality before proceeding to planning
**Created**: [DATE]
**Feature**: [Link to spec.md]
## Content Quality
- [ ] No implementation details (languages, frameworks, APIs)
- [ ] Focused on user value and business needs
- [ ] Written for non-technical stakeholders
- [ ] All mandatory sections completed
## Requirement Completeness
- [ ] No [NEEDS CLARIFICATION] markers remain
- [ ] Requirements are testable and unambiguous
- [ ] Success criteria are measurable
- [ ] Success criteria are technology-agnostic (no implementation details)
- [ ] All acceptance scenarios are defined
- [ ] Edge cases are identified
- [ ] Scope is clearly bounded
- [ ] Dependencies and assumptions identified
## Feature Readiness
- [ ] All functional requirements have clear acceptance criteria
- [ ] User scenarios cover primary flows
- [ ] Feature meets measurable outcomes defined in Success Criteria
- [ ] No implementation details leak into specification
## Notes
- Items marked incomplete require spec updates before the speckit-clarify or speckit-plan skillsb. Run Validation Check: Review the spec against each checklist item:
c. Handle Validation Results:
## Question [N]: [Topic]
**Context**: [Quote relevant spec section]
**What we need to know**: [Specific question from NEEDS CLARIFICATION marker]
**Suggested Answers**:
| Option | Answer | Implications |
| ------ | ------------------------- | ------------------------------------- |
| A | [First suggested answer] | [What this means for the feature] |
| B | [Second suggested answer] | [What this means for the feature] |
| C | [Third suggested answer] | [What this means for the feature] |
| Custom | Provide your own answer | [Explain how to provide custom input] |
**Your choice**: _[Wait for user response]_| Content | not |Content||--------|d. Update Checklist: After each validation iteration, update the checklist file with current pass/fail status
NOTE: The script creates and checks out the new branch and initializes the spec file before writing.
specs/<feature>/spec.mdspecs/<feature>/checklists/requirements.md.specify/scripts/bash/create-new-feature.shAfter generating the spec:
When creating this spec from a user prompt:
Examples of reasonable defaults (don't ask about these):
Success criteria must be:
Good examples:
Bad examples (implementation-focused):
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.