Skip to content
skillsafebeta
← Report library
Purpose / Other

Write Product Spec Skill Security Audit

What the author says it does (original text)

Write a PRODUCT.md spec for a significant user-facing feature in Warp, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.

Independent security check

No obvious risks found in this check

Files checked
1
Risks found
0
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.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

8 instruction sections

The Skill’s main function is to write a user-behavior-focused PRODUCT.md for a significant feature, while explicitly excluding internal types, algorithms, and other implementation details.

View source
SKILL.md:8In the instructionsOpen original file
Write a `PRODUCT.md` spec for a significant feature in Warp.## OverviewThe product spec should make the desired behavior unambiguous enough that an agent can implement it correctly and avoid regressions. Describe the feature purely from the user's perspective — what the user sees, does, and experiences, and the invariants that must hold for them. Do not include implementation details (internal types, state layout, module boundaries, data flow, algorithms).

It creates or maintains a persistent file at specs/<id>/PRODUCT.md, with the directory ID taken from a Linear ticket, GitHub issue, or a user-provided feature name.

View source
SKILL.md:25In the instructionsOpen original file
Write specs to `specs/<id>/PRODUCT.md`, where `<id>` is one of:- a Linear ticket number (e.g. `specs/APP-1234/PRODUCT.md`)- a GitHub issue id, prefixed with `gh-` (e.g. `specs/gh-4567/PRODUCT.md`)- a short kebab-case feature name (e.g. `specs/vertical-tabs-hover-sidecar/PRODUCT.md`)`specs/` should contain only id-named directories as direct children — no engineer-named subdirectories.
SKILL.md:102In the instructionsOpen original file
## Keep the spec currentApproved specs may ship in the same PR as the implementation. As implementation evolves, update `PRODUCT.md` in the same PR when user-facing behavior or UX details change. The checked-in spec should describe the feature that actually ships.

For features with UI or interaction design, it requires asking whether a Figma mock exists and recording any supplied link in the specification; purely backend features skip this question.

View source
SKILL.md:41In the instructionsOpen original file
If the feature has any UI or interaction design, ask the user whether a Figma mock exists before drafting the Behavior section, and include the link in the spec when one is provided. A mock is often the most reliable source of truth for visual states, spacing, and edge-case layouts — not asking can cause the Behavior section to guess at intent the designer already settled.- If the user provides a link, include it under a short `## Figma` section (or inline near the top of Behavior) as `Figma: <link>`.- If the user confirms no mock exists, note `Figma: none provided` so the absence is explicit rather than ambiguous.- If the feature is purely backend (data model, API, CLI with no visual surface), skip the question and omit the section.

The Skill mentions possible external ticket creation through Linear MCP or gh, but explicitly limits it to cases where the user asks for it and requires clarification when the team, labels, or repository are unclear.

View source
SKILL.md:33In the instructionsOpen original file
Ticket / issue references are optional. If the user has a Linear ticket or GitHub issue, use its id. If they don't, ask them for a feature name to use as the directory. Only create a new Linear ticket or GitHub issue when the user explicitly asks for one; in that case use the Linear MCP tools or `gh` CLI respectively (and `ask_user_question` if team, labels, or repo are unclear).
Start here · InstructionsSKILL.md
write-product-spec
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 1 more sections are available in the original file.
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
165
File checksum (to compare versions)
4e7ef781aad1cd42e3178680f6e9d72de439d66c1b99023e4386103065a5fb19