Skip to content
skillsafebeta
← Report library
Purpose / Writing

Spec Driven Implementation Skill Security Audit

What the author says it does (original text)

Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.

Independent security check

Security risks found

Files checked
1
Risks found
1
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

Creates a real Linear record when no related ticket exists

Source references: 3
What we found

The Skill explicitly requires creating a missing Linear issue before writing specifications and names the write-capable `save_issue` operation. It asks the user only when the team or labels are unclear, not for confirmation of the issue creation itself.

Why this matters

A user seeking only feature planning or local specification drafts could still get a real workspace issue, potentially triggering notifications, assignments, reporting, or other automations.

When no relevant Linear issue exists, the Skill directs the agent to create one and explicitly names the write-capable `save_issue` operation. It asks the user only when the team or labels are unclear, not for confirmation of issue creation itself. Running this workflow could therefore add a record to the user's Linear workspace without per-action approval. The user can ask for a preview-and-confirm step or restrict the Skill to read-only Linear access.

SKILL.md:26In the instructionsOpen original file
If a relevant Linear issue does not already exist, create one before writing specs. Use the Linear MCP tools directly:- `list_teams` to find the appropriate team- `list_issue_labels` to inspect the expected labels/tags- `save_issue` to create the issue with the appropriate team and labels
Show 2 other places
SKILL.md:32In the instructionsOpen original file
If the correct team or labels are not obvious from the request and surrounding context, use `ask_user_question` to clarify rather than guessing.
SKILL.md:30In the instructionsOpen original file
- `list_issue_labels` to inspect the expected labels/tags- `save_issue` to create the issue with the appropriate team and labels
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.No risks found
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.No risks found
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

5 instruction sections

The Skill decides whether a substantial feature warrants specifications; small fixes, straightforward refactors, and narrow UI changes can generally skip them.

View source
SKILL.md:38In the instructionsOpen original file
Strongly prefer specs when the change is substantial, such as:- product or architectural ambiguity- expected implementation size around 1k+ LOC- deep or cross-cutting stack changes- risky behavior changes where regressions would be expensive- work where agent quality will improve materially from clearer inputs
SKILL.md:46In the instructionsOpen original file
Specs are often unnecessary for:- small, local bug fixes- straightforward refactors- narrow UI tweaks with little ambiguity

It creates PRODUCT.md and, when warranted, TECH.md under a ticket-numbered repository directory, then continues modifying them as implementation evolves.

View source
SKILL.md:14In the instructionsOpen original file
Specs should usually live in:- `specs/<linear-ticket-number>/PRODUCT.md`- `specs/<linear-ticket-number>/TECH.md`
SKILL.md:102In the instructionsOpen original file
### 5. Keep specs current during implementationIf implementation changes from the spec, update the spec rather than leaving it stale.

The workflow says implementation follows specification approval and final verification should map back to the specified behavior and validation goals.

View source
SKILL.md:89In the instructionsOpen original file
### 4. Implement approved specsAfter the specs are approved, use the `implement-specs` skill to build from the approved `PRODUCT.md` and `TECH.md`.The implementation can often be pushed in the same PR as the product and tech specs. As the engineer iterates, keep `PRODUCT.md`, `TECH.md`, code changes, and tests in that same PR so the review reflects the feature that will actually ship.
SKILL.md:121In the instructionsOpen original file
### 6. Verify behavior against the specBefore considering the work complete, make sure verification maps back to the specs. Prefer tests and artifacts that validate the product behavior directly:- unit tests and regression coverage that follow the repository's local testing conventions- integration tests for critical user flows- loom walkthroughs or equivalent feature demonstrations when appropriate- screenshots or videos when useful for UI-heavy work
Start here · InstructionsSKILL.md
spec-driven-implementation
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions
Lines read
144
File checksum (to compare versions)
6637aba0611b0ab34c7b5291cf7ce2ba5ada14ebc0f7f37aabdeb13e29cd4791