CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

18.2 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 4 flagged

Securityscore 52 · 4 findings

MEDIUMInstruction telling the agent not to ask for approvalSS-SKILL-INJECT-DONT-ASK-01 · Prompt injection · .github/agents/speckit.checklist.agent.md

MEDIUM — it fires on intent; the real damage depends on the host agent's own approval-gating.

Why it matters

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 exact value spotted

excerpt.github/agents/speckit.checklist.agent.md· markdown

60- If presenting options, generate a compact table with columns: Option | Candidate | Why It

… (7 chars elided on L60)

61- Limit to A–E options maximum; omit table if a free-form answer is clearer

62- Never ask the user to restate what they already said

63- Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm wh

… (26 chars elided on L63)

Occurrences

1 occurrence · at L62

How to fix

Remove the approval-skipping instruction, or scope it narrowly to a specific safe, reversible action.

Delete blanket "don't ask / no need to confirm" directives from the skill.
If the skill is a genuine autonomous job, restrict the opt-out to a named non-destructive action rather than all actions.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-DONT-ASK-01sha2565084aa178cfd9d97…rubric 365aacaView on GitHub

MEDIUMInstruction telling the agent not to ask for approvalSS-SKILL-INJECT-DONT-ASK-01 · Prompt injection · .github/agents/speckit.specify.agent.md×2

MEDIUM — it fires on intent; the real damage depends on the host agent's own approval-gating.

Why it matters

The exact value spotted

excerpt.github/agents/speckit.specify.agent.md· markdown

21## Outline

23The text the user typed after `/speckit.specify` in the triggering message **is** the featur

… (108 chars elided on L23)

25Given that feature description, do this:

Occurrences

2 occurrences · first at L23, also L205

Show all 2 locations

Line

File

L23

.github/agents/speckit.specify.agent.md

L205

.github/agents/speckit.specify.agent.md

How to fix

Remove the approval-skipping instruction, or scope it narrowly to a specific safe, reversible action.

Delete blanket "don't ask / no need to confirm" directives from the skill.
If the skill is a genuine autonomous job, restrict the opt-out to a named non-destructive action rather than all actions.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-DONT-ASK-01sha25668b030f55bcd484a…rubric 365aacaView on GitHub

MEDIUM"Never tell the user" non-disclosure imperative in the skillSS-SKILL-INJECT-IMPERATIVE-01 · Prompt injection · .github/agents/speckit.clarify.agent.md

MEDIUM — it fires on intent; whether the agent honors the non-disclosure imperative depends on the host model.

Why it matters

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.

The exact value spotted

excerpt.github/agents/speckit.clarify.agent.md· markdown

130- User signals completion ("done", "good", "no more"), OR

131- You reach 5 asked questions.

132- Never reveal future queued questions in advance.

133- If no valid questions exist at start, immediately report no critical ambiguities.

134

Occurrences

1 occurrence · at L132

How to fix

Remove the non-disclosure imperative, or rescope it so it limits output format, not honesty to the user.

Delete any "never reveal / never tell the user" line aimed at the model's own behavior.
Keep legitimate confidentiality rules about external data (e.g. "do not echo API keys"), which are user-protective, not user-deceiving.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-IMPERATIVE-01sha25631af9ccee29e8511…rubric 365aacaView on GitHub

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

skills/speckit-baseline/SKILL.md · 1 file

skills/speckit-baseline/SKILL.md4.4 KB · Markdown

name: speckit-baseline

description: Generate feature specifications by analyzing existing source code.

Spec Kit Baseline Skill

When to Use

You need a spec for existing or legacy code.
You want to document a feature before refactoring.
You inherited a codebase without written requirements.

Inputs

A target path, file list, or glob pattern describing the code to analyze.
Repo context with .specify/ scripts and templates.

If the target is missing or ambiguous, ask a focused question before continuing.

Goal

Generate a technology-agnostic spec for existing code, then create the feature branch/spec file using the standard Spec Kit templates.

Workflow

Parse target input: Identify files, directories, or patterns to analyze.

Accept file paths, glob patterns, or directory paths.
If empty: stop and ask for a concrete target.

Discover and read source files:

Expand globs to a file list.
Read file contents for analysis.
Identify primary language(s) and frameworks.
Map key file relationships and dependencies.

Analyze code structure:

Identify entry points and public interfaces.
Extract function/method signatures and behaviors.
Find data models and entities.
Detect API endpoints and routes.
Identify user-facing functionality.

Generate a short name (2-4 words) from the analyzed code:

Use action-noun format (e.g., "user-auth", "payment-processing").
Base on primary functionality discovered.
Preserve technical terms where meaningful.

Create the feature branch and spec file:

Find the highest existing feature number for this short name (branches/specs).
Run .specify/scripts/bash/create-new-feature.sh --json with the calculated number and short name.
Read BRANCH_NAME, FEATURE_DIR, and SPEC_FILE paths from the script JSON output.
For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

Load the spec template from .specify/templates/spec-template.md.

Draft the specification using the template structure:

User Stories: Infer from user-facing code paths and interactions.
Acceptance Scenarios: Derive from validation logic, error handling, and tests.
Functional Requirements: Extract from business rules and constraints.
Key Entities: Identify from data models and schemas.
Success Criteria: Infer from metrics, logging, or performance-related code.
Assumptions: Document inferences made during analysis.

Abstract implementation details:

Convert technical patterns to user-focused requirements.
Remove framework-specific terminology.
Focus on WHAT the code does, not HOW it does it.

Create spec quality checklist at FEATURE_DIR/checklists/requirements.md.

Report completion with:

Branch name and spec file path.
Summary of analyzed files.
Key features discovered.
Areas needing clarification or review.

Outputs

specs/<feature>/spec.md
specs/<feature>/checklists/requirements.md

Key rules

Focus on extracting WHAT and WHY from HOW.
Abstract away implementation details in the generated spec.
Document assumptions made during code analysis.
Flag areas where code behavior is unclear.
Preserve discovered business rules and constraints.
Use [NEEDS CLARIFICATION] for ambiguous code sections (max 3).
Generated specs should be validated by someone who knows the feature.

Examples

Code Pattern → Spec Requirement:

if (user.role === 'admin') → "System MUST restrict action to administrator users"
password.length >= 8 → "Passwords MUST be at least 8 characters"
cache.set(key, value, 3600) → "System MUST cache results for improved performance"
try { ... } catch (e) { notify(e) } → "System MUST notify users when errors occur"

Code Pattern → User Story:

Login endpoint with OAuth → "As a user, I can sign in using my social account"
Shopping cart logic → "As a customer, I can add items to my cart for later purchase"
Report generation → "As an analyst, I can generate reports on system activity"

Next Steps

After generating spec.md:

Clarify with domain experts using speckit-clarify.
Plan modernization/refactoring with speckit-plan.
Compare the generated spec with actual requirements to identify gaps.

speckit-baseline— agent skill

Is speckit-baseline safe to install?

Spec Kit Baseline Skill

When to Use

Inputs

Goal

Workflow

Outputs

Key rules

Examples

Next Steps

Audit the pieces. Scan the whole. Decide.