New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Create Tech Spec

by warpdotdev in warpdotdev/oz-for-oss

Create a technical spec from a GitHub issue in this repository by applying the shared write-tech-spec workflow with Oz-specific issue context and output paths.

MITAuto-check passedDevelopment

Install Create Tech Spec

skills CLI
$ npx skills add warpdotdev/oz-for-oss --skill create-tech-spec -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install warpdotdev/oz-for-oss create-tech-spec --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/warpdotdev/oz-for-oss.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/create-tech-spec .claude/skills/create-tech-spec && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
create-tech-spec
GitHub stars
313
Token cost
~1.2k tokens
SKILL.md length
610 words
Files
1
Skills in repo
17
Repo updated
First seen
Licence
MIT

At a glance

Create a technical spec from a GitHub issue in this repository by applying the shared write-tech-spec workflow with Oz-specific issue context and output paths.

  • Works in 11 steps: Start from the shared write-tech-spec… → Read the issue details carefully. If a… → Inspect the repository to understand the… → …
  • Without creating commits
  • SKILL.md covers Overview, Inputs, Process and Outputs
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Create Tech Spec is an agent skill from warpdotdev/oz-for-oss. Create a technical spec from a GitHub issue in this repository by applying the shared write-tech-spec workflow with Oz-specific issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under specs/GH<issue-number/tech.md and the agent should prepare file changes only, without creating commits or pull requests itself unless a cloud workflow explicitly asks for it.

Its SKILL.md is about 1.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Pull requests. It works with GitHub. The repository describes itself as: Workflows and skills to help people and agents collaborate on open-source software with the power of Oz! The licence is MIT.

When your agent uses it

  • Without creating commits
  • Pull requests itself unless a cloud workflow explicitly asks for it

Example prompts

  • “/create-tech-spec”

Workflow steps

11 steps, taken from the first numbered list in SKILL.md.

  1. Start from the shared write-tech-spec guidance and follow its structure and writing standards unless this wrapper says otherwise.
  2. Read the issue details carefully. If a product spec exists at specs/GH/product.md, read it first to understand the intended behavior. If…
  3. Inspect the repository to understand the current implementation and the likely scope of the requested work before writing the spec. Do not…
  4. Create or update specs/GH/tech.md.
  5. Use the shared skill's structure as the baseline, adapted to this repository and issue format. At minimum, cover
  6. Keep the tech spec concise, actionable, and grounded in actual code paths and ownership boundaries in this repository.
  7. Do not implement the feature or modify production code as part of this task. Limit changes to the tech spec artifact and any minimal…
  8. Do not include issue number references (e.g. (#N), Refs #N) in commit messages. The issue is already linked in the PR.
  9. If the prompt asks for it, write pr-metadata.json at the repository root containing a JSON object with the fields branch_name, pr_title…
  10. Default behavior: do not stage files, create commits, push branches, open pull requests, or use the GitHub CLI. If the prompt explicitly…
  11. In your final response, provide a brief summary of the tech spec and call out any assumptions or open questions so the workflow can reuse…

What it can do on your machine

Read from SKILL.md and the folder at commit a2bb45f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Create Tech Spec loads about 1.2k tokens when it runs. Until then it costs about 108 tokens; SKILL.md has 610 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~108
When it runs · the whole SKILL.md, loaded when a task matches
~1.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from warpdotdev/oz-for-oss at commit a2bb45f, republished under its MIT licence (© warpdotdev). 610 words, ~1,156 tokens.

Download SKILL.mdSave it as .claude/skills/create-tech-spec/SKILL.md (or your agent's skills folder).
name
create-tech-spec
description
Create a technical spec from a GitHub issue in this repository by applying the shared `write-tech-spec` workflow with Oz-specific issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/GH<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or pull requests itself unless a cloud workflow explicitly asks for it.

create-tech-spec

Create a tech spec from a GitHub issue for this repository.

Overview

This skill is a thin Oz wrapper around the shared tech-spec workflow:

  • write-tech-spec

Use that shared skill as the base behavior and structure unless this wrapper overrides it. Keep the same emphasis on grounding the plan in current code, documenting relevant files and data flow, explaining tradeoffs, and defining validation.

The Oz-specific differences are:

  • the primary input is a GitHub issue, not a Linear issue
  • the output path is specs/GH<issue-number>/tech.md
  • issue_comments.md and triggering-comment context are additional design inputs
  • a workflow may also request a structured PR metadata file in pr-metadata.json
  • do not create or edit Linear issues as part of this workflow

Inputs

Expect issue details in the prompt, including the issue number, title, description, labels, assignees, and optional prior discussion captured in issue_comments.md.

When available, the product spec at specs/GH<issue-number>/product.md should be treated as the primary input for understanding the intended behavior. The tech spec translates that product intent into an implementation approach.

Process

  1. Start from the shared write-tech-spec guidance and follow its structure and writing standards unless this wrapper says otherwise.
  2. Read the issue details carefully. If a product spec exists at specs/GH<issue-number>/product.md, read it first to understand the intended behavior. If issue_comments.md exists, review it for clarifications, prior decisions, and design nuance that should influence the tech plan.
  3. Inspect the repository to understand the current implementation and the likely scope of the requested work before writing the spec. Do not guess about current architecture when the code can be inspected directly.
  4. Create or update specs/GH<issue-number>/tech.md.
  5. Use the shared skill's structure as the baseline, adapted to this repository and issue format. At minimum, cover:
    • problem
    • relevant code
    • current state
    • proposed changes
    • end-to-end flow when useful
    • risks and mitigations
    • testing and validation
    • follow-ups or open technical questions
  6. Keep the tech spec concise, actionable, and grounded in actual code paths and ownership boundaries in this repository.
  7. Do not implement the feature or modify production code as part of this task. Limit changes to the tech spec artifact and any minimal repository metadata needed to support it. Treat temporary context files such as issue_comments.md as scratch input only and do not commit them.
  8. Do not include issue number references (e.g. (#N), Refs #N) in commit messages. The issue is already linked in the PR.
  9. If the prompt asks for it, write pr-metadata.json at the repository root containing a JSON object with the fields branch_name, pr_title, and pr_summary. The pr_summary should summarize the resulting spec changes, validation, and any reviewer-relevant assumptions or open questions. For spec-only PRs, include a non-closing reference to the source issue such as Related issue: #<issue-number> rather than closing keywords like Closes or Fixes.
  10. Default behavior: do not stage files, create commits, push branches, open pull requests, or use the GitHub CLI. If the prompt explicitly instructs you to publish a named branch, you may commit and push exactly the requested spec changes to that branch, but still do not open or update the pull request yourself unless the prompt explicitly asks for it.
  11. In your final response, provide a brief summary of the tech spec and call out any assumptions or open questions so the workflow can reuse that summary when creating the PR.
Show full SKILL.md (59 more words)Show less

Outputs

  • Leave the repository with the new or updated tech spec file ready to be committed by the workflow.
  • When requested by the prompt, leave a ready-to-use pr-metadata.json with branch_name, pr_title, and pr_summary.
  • If the issue is underspecified, still produce the best possible tech spec and clearly capture assumptions or open questions in the spec file and final response.

© warpdotdev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/create-tech-spec of warpdotdev/oz-for-oss.

Open the folder on GitHubat commit a2bb45f

Compare with similar skills

Create Tech Spec next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Create Tech Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Create Tech Spec this skillwarpdotdev/oz-for-oss313—~1.2kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Check PRonyx-dot-app/onyx32k2 repos~2.3kAutomated safety check: PassMIT
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0
Pull Request Title and Body Writeropeninterpreter/openinterpreter69k2 repos~1.1kAutomated safety check: PassApache-2.0

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Check PR

    onyx-dot-app/onyx

    Checks a GitHub, GitLab, or Perforce (p4) pull request (or merge request, or shelved changelist) for unresolved review comments, failing status checks, and incomplete PR descriptions.

    32k GitHub starsUsed in 2 repos~2.3k tokens
    DevelopmentAuto-check passed

  • Contributor-First PR Merge

    HKUDS/OpenHarness

    Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed

  • Create Pull Request

    cline/cline

    Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed

  • Pull Request Title and Body Writer

    openinterpreter/openinterpreter

    Rewrites the title and body of one or more pull requests with gh, leading with why the change was made, then what changed, and describing only the net result.

    69k GitHub starsUsed in 2 repos~1.1k tokens
    DevelopmentAuto-check passed

  • GitHub Review Iteration

    prisma/orm

    Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed

More from warpdotdev/oz-for-oss

All 17 skills in this repo

  • Update Dedupe

    warpdotdev/oz-for-oss

    Update the repo-local dedupe-issue-local companion skill using closed-as-duplicate signals.

    313 GitHub stars~927 tokensUpdated 20 days ago
    Auto-check passed

  • Update PR Review

    warpdotdev/oz-for-oss

    Update the repo-local review-pr-local and review-spec-local companion skills using human feedback left on pull request conversations.

    313 GitHub stars~1.6k tokensUpdated 20 days ago
    Auto-check passed

  • Bootstrap Issue Config

    warpdotdev/oz-for-oss

    Bootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate .github/issue-triage/config.json and .github/STAKEHOLDERS.

    313 GitHub starsUsed in 1 repo~1.3k tokens
    Auto-check passed

  • Update Triage

    warpdotdev/oz-for-oss

    Update the repo-local triage-issue-local companion skill using signals from recently triaged issues (maintainer re-labels, re-opens, follow-up comments).

    313 GitHub stars~1k tokensUpdated 20 days ago
    Auto-check passed

  • Implement Issue

    warpdotdev/oz-for-oss

    Implement a GitHub issue in this repository by applying the shared implement-specs workflow with Oz-specific issue, spec-context, and summary-file handling.

    313 GitHub stars~2k tokensUpdated 20 days ago
    Auto-check passed

  • Review Spec

    warpdotdev/oz-for-oss

    Review a spec/plan pull request diff and write structured feedback to review.json for the workflow to publish.

    313 GitHub stars~1.9k tokensUpdated 20 days ago
    Auto-check passed

Works with

Categories

Questions about Create Tech Spec

What does Create Tech Spec do?

Create a technical spec from a GitHub issue in this repository by applying the shared write-tech-spec workflow with Oz-specific issue context and output paths. Create Tech Spec is an agent skill from warpdotdev/oz-for-oss. Create a technical spec from a GitHub issue in this repository by applying the shared write-tech-spec workflow with Oz-specific issue context and output paths.

When should I use Create Tech Spec?

Create Tech Spec fits situations like: without creating commits; pull requests itself unless a cloud workflow explicitly asks for it.

How do I install Create Tech Spec in Claude Code?

Run `npx skills add warpdotdev/oz-for-oss --skill create-tech-spec -a claude-code`. Or copy the skill folder (.agents/skills/create-tech-spec in warpdotdev/oz-for-oss) into .claude/skills/create-tech-spec in your project. Claude Code loads it when a task matches its description.

How do I install Create Tech Spec in Codex?

Run `npx skills add warpdotdev/oz-for-oss --skill create-tech-spec -a codex`. Or copy the skill folder (.agents/skills/create-tech-spec in warpdotdev/oz-for-oss) into .agents/skills/create-tech-spec in your project. Codex loads it when a task matches its description.

Can I use Create Tech Spec in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add warpdotdev/oz-for-oss --skill create-tech-spec -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-tech-spec, .gemini/skills/create-tech-spec, .github/skills/create-tech-spec and .opencode/skills/create-tech-spec in your project.

What does Create Tech Spec need to run?

SKILL.md names no scripts, command-line tools or credentials: Create Tech Spec is instructions for the agent only.

Does Create Tech Spec access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Create Tech Spec safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Create Tech Spec use?

Create Tech Spec is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Create Tech Spec use?

About 1.2k tokens (SKILL.md is roughly 4.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Create Tech Spec?

Skills that share tags, products or a category with Create Tech Spec: PR Babysitter (openinterpreter/openinterpreter, 69k stars), Check PR (onyx-dot-app/onyx, 32k stars), Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars) and Create Pull Request (cline/cline, 70k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Create Tech Spec?

warpdotdev (a GitHub organization) maintains it in warpdotdev/oz-for-oss, which has 313 GitHub stars. The repository holds 17 skills in this directory. The repository was last updated on September 17, 2026.

Source: warpdotdev/oz-for-oss on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.