Write Tech Spec Skill Security Audit
What the author says it does (original text)
Write a TECH.md spec for a significant Warp feature after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.
No obvious risks found in this check
- Files checked
- 1
- Risks found
- 0
Inside this skill
The Skill’s main behavior is to research the existing code and product specification, then create a technical specification at `specs/<id>/TECH.md`; this is a persistent file write, but it directly matches the stated purpose.
View source
Write a `TECH.md` spec for a significant feature in Warp.Write specs to `specs/<id>/TECH.md`, where `<id>` is one of:- a Linear ticket number (e.g. `specs/APP-1234/TECH.md`)- a GitHub issue id, prefixed with `gh-` (e.g. `specs/gh-4567/TECH.md`)- a short kebab-case feature name (e.g. `specs/vertical-tabs-hover-sidecar/TECH.md`)Before drafting, it instructs the agent to read the product specification and inspect relevant code, types, data flow, and ownership boundaries so the resulting document is grounded in the current implementation.
View source
## Research before writingBefore drafting, read the product spec (if any), inspect the relevant code, and identify the main files, types, data flow, and ownership boundaries. Do not guess about current architecture when the code can be inspected directly.When referencing relevant code chunks in the spec, prefer commit-pinned references so future readers can inspect the exact code you researched. Capture the current commit SHA for each repository you inspected (for example, `git rev-parse HEAD`) and, when possible, make file references Markdown links to the corresponding GitHub `blob/<sha>/...#Lx-Ly` URL. Use the linked text to keep the path readable in the spec.It does not independently authorize creation of external tickets: Linear or GitHub issue creation is permitted only when explicitly requested by the user, with clarification required if the team, labels, or repository are unclear.
View source
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).The parallel-agent language asks the author to evaluate and document a possible future implementation strategy in the technical specification, rather than directly launching agents; the section is skipped when the relevant capability is unavailable.
View source
3. **Testing and validation** — How the implementation will be verified against the product behavior. Owns everything about proving the feature works: unit tests, integration tests, manual steps, screenshots, videos, and any other verification. Reference the numbered Behavior invariants from `PRODUCT.md` directly rather than restating them; each important invariant should map to a concrete test or verification step. This section is where validation lives — `PRODUCT.md` intentionally does not have a Validation section.4. **Parallelization** — Actively evaluate whether parallel sub-agents (launched via `run_agents`) would meaningfully reduce wall-clock time or isolate work. Skip this section if `run_agents` is not available. When the spec proposes using sub-agents, include for each proposed agent: - A short name/role and the subtask it owns. When parallelization is NOT proposed, briefly note why it isn't beneficial (e.g. the task is small, or subtasks are tightly coupled) so reviewers can challenge that judgment. Propose concrete defaults for worktrees, branch names, and execution mode rather than leaving them open-ended.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
Operations mentioned in code and instructions
Connect to websites
1. **Context** — What's being built, how the current system works in the area being changed, and the most relevant files with line references. Combine the "problem," "current state," and "relevant code" into one grounded section. Example re … - [`app/src/workspace/mod.rs:42 @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/mod.rs#L42) — entry point for the user flow - [`app/src/workspace/workspace.rs (120-220) @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/workspace.rs#L120-L220) — state and event handling that will likely change - [`app/src/workspace/mod.rs:42 @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/mod.rs#L42) — entry point for the user flow - [`app/src/workspace/workspace.rs (120-220) @ <commit-sha>`](https://github.com/warpdotdev/warp/blob/<commit-sha>/app/src/workspace/workspace.rs#L120-L220) — state and event handling that will likely change Reference `PRODUCT.md` for user-visible behavior rather than restating it.- Lines read
- 96
- File checksum (to compare versions)
- 53cf3077c7e2fd7178027aa9cf89ff03eff26500ed1405da8362e0d87160cd1b