Skip to content
skillsafebeta
← Report library
Purpose / Development

Implement Specs Skill Security Audit

What the author says it does (original text)

Implement an approved feature from PRODUCT.md and TECH.md, keeping specs and code aligned in the same PR as implementation evolves. Use after the product and tech specs are approved and the next step is building the feature.

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.No risks found
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.Risks found: 1
Medium risk

The Skill can directly rewrite approved product and technical specifications during implementation

Source references: 4
What we found

The Skill tells the agent to update checked-in PRODUCT.md or TECH.md when it concludes that intended behavior or design “should change,” without requiring renewed approval from the user or original approver for material changes. Keeping specifications and code in one PR aids review, but does not ensure reviewers recognize a specification edit as a new product decision.

Why this matters

Implementation difficulty or agent judgment could become a new requirement, user experience, architecture, or success criterion. The code would then be validated against the rewritten specification rather than the scope the user originally approved.

The Skill requires approval only before implementation starts. If behavior or design later “should change,” it directs the agent to update checked-in PRODUCT.md/TECH.md and include those changes with the code in one PR. A PR enables review, but the text does not require pausing for renewed authorization after material product, UX, architecture, or validation changes. An implementation judgment could therefore become a specification decision affecting user expectations and later approvals. Users can ask the author to add an explicit re-approval gate and restrict the agent to proposing such changes until approval is given.

SKILL.md:58In the instructionsOpen original file
### 4. Update specs as the implementation evolvesIf implementation reveals that the intended behavior or design should change, update the checked-in specs rather than letting them go stale.In particular:- update `PRODUCT.md` when user-facing behavior, UX, edge cases, or success criteria change- update `TECH.md` when architecture, sequencing, module boundaries, or validation strategy change- keep those updates in the same PR as the corresponding code changesThe PR should describe the feature that actually ships, not just the initial draft of the specs.
Show 3 other places
SKILL.md:72In the instructionsOpen original file
Before considering the work complete, verify that the code matches the current specs.
SKILL.md:22In the instructionsOpen original file
- confirm that `PRODUCT.md` exists- confirm that `TECH.md` exists when the feature warranted one- confirm that the relevant specs have been reviewed and approved enough to start implementation
SKILL.md:64In the instructionsOpen original file
- update `PRODUCT.md` when user-facing behavior, UX, edge cases, or success criteria change- update `TECH.md` when architecture, sequencing, module boundaries, or validation strategy change- keep those updates in the same PR as the corresponding code changes
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

This Skill implements a feature from approved PRODUCT.md and TECH.md files and keeps the specifications, code, and tests in the same change workflow.

View source
SKILL.md:8In the instructionsOpen original file
Implement an approved feature from `PRODUCT.md` and `TECH.md`.
SKILL.md:52In the instructionsOpen original file
- keep behavior aligned with `PRODUCT.md`- keep architecture and sequencing aligned with `TECH.md`- add or update tests and verification artifacts as the work landsUse the same PR for the specs and implementation when practical so the full feature evolution is reviewable in one place.

Before implementation, it calls for confirming that the required specifications exist and have been reviewed and approved enough to begin, but it does not prescribe an approver or confirmation mechanism.

View source
SKILL.md:20In the instructionsOpen original file
Before using this skill:- confirm that `PRODUCT.md` exists- confirm that `TECH.md` exists when the feature warranted one- confirm that the relevant specs have been reviewed and approved enough to start implementation

For large features, the Skill may first offer PROJECT_LOG.md or DECISIONS.md to the user; the text explicitly identifies them as optional aids.

View source
SKILL.md:37In the instructionsOpen original file
### 2. Offer optional implementation aids for large featuresFor large or long-running features, optionally offer one of these aids to the user before implementation begins:- `PROJECT_LOG.md` to track checkpoints, explored paths, partial findings, and current implementation state- `DECISIONS.md` to capture concrete product and technical decisions made during the PRD and tech design processThese are optional aids, not required deliverables. Offer them when they would reduce confusion or help future agents avoid re-exploring the same paths.
Start here · InstructionsSKILL.md
implement-specs
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
91
File checksum (to compare versions)
36ad3e40d17fe9e644b41def77be3dd654452f4c825bc9af3c289feae7500d9f