warpdotdev/common-skills
22 skills304k installs3.3k starsGitHub
Install
npx skills add https://github.com/warpdotdev/common-skillsSkills in this repo
1Spec Driven Implementationspec-driven-implementation guides developers through a spec-first workflow for significant features by establishing PRODUCT.md and TECH.md before coding. Developers use this when starting substantial features, planning agent-driven implementation, or when specs should be version-controlled. The workflow evaluates feature scope and risk to determine if specs are justified, writes product specs describing user behavior and success criteria, optionally adds tech specs for multi-system or architecturally complex work, implements from approved specs while keeping them current, and verifies behavior against those specs via tests and walkthroughs. Specs live in specs/<linear-ticket-number>/ and should be checked into the same PR as related code, with updates reflecting actual shipped behavior rather than initial intent.16.3kinstalls2Review PrReview a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub. --- name: review-pr description: Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub. --- # Review PR Skill Review the current pull request and write the output to `review.json`. ## Context - The working directory is the PR branch checkout. - The workflow usually provides an annotated diff in `pr_diff.txt`. - The workflow usually provides the PR description in `pr_description.txt`. - If `spec_context.md` exists, it contains spec context for implementation-vs-spec validation.16.3kinstalls3Write Product SpecThis skill generates PRODUCT.md specs for significant user-facing features in Warp, documenting desired behavior from the user's perspective without implementation details. Developers use it early in the feature cycle to codify behavior, reduce ambiguity, and create a foundation for tech specs and implementation. The spec focuses on user-visible states, transitions, inputs, edge cases, error handling, and invariants that must hold - written as testable, numbered claims in a Behavior section.16.2kinstalls4Write Tech Specwrite-tech-spec guides developers and AI agents in authoring TECH.md specifications that translate product requirements into detailed implementation plans grounded in actual codebase structure. It covers context (current code, relevant files with commit-pinned links), proposed changes (modules, types, data flow, tradeoffs), testing/validation strategies mapped to product behaviors, and parallelization guidance for multi-agent execution. The spec framework emphasizes concrete architectural decisions, commit-linked code references, and right-sizing documentation to feature complexity (40-150+ lines depending on scope). Developers use it when implementations span multiple modules, involve tradeoffs, or need pre-review planning; it eliminates guessing by requiring direct codebase inspection and keeps specs current as implementation details change.16.2kinstalls5Fix ErrorsThis skill diagnoses and fixes compilation errors, clippy linting violations, formatting issues, test failures, and WASM-specific problems in the warp Rust codebase. Developers use it when builds fail, presubmit checks don't pass, or tests break during development. Key workflows include running individual cargo fmt, clippy, and nextest commands; gating WASM-incompatible code behind feature flags; and interpreting common error patterns like type mismatches, unused imports, struct field changes, and enum variant additions. The presubmit script orchestrates all checks at once; specific test filtering and per-package runs target narrow issues.16.2kinstalls6Resolve Merge ConflictsThis skill provides a Python script that extracts unresolved merge conflicts without loading entire files into context. It generates a summary of conflicted paths and their conflict hunks, then allows drilling into individual files to view compact diffs between ours/theirs versions. Developers use it when merges, rebases, cherry-picks, or stash pops stop on conflicts. The workflow prioritizes minimal context by showing only nearby conflict regions and unified diffs, then prompts resolution via git checkout or direct editing, followed by validation to ensure no markers remain.16.2kinstalls7Implement Specsimplement-specs guides engineers through building a feature after product and tech specifications are approved. The skill emphasizes treating PRODUCT.md as the source of truth for user-facing behavior and TECH.md for architecture and implementation sequencing. Engineers read approved specs first, optionally create tracking documents like PROJECT_LOG.md or DECISIONS.md for complex features, then implement against those specs while synchronously updating both documentation and code in the same PR as requirements or design decisions evolve. Verification happens through unit tests, integration tests, and alignment checks between final code and updated specs.16.2kinstalls8Create Prcreate-pr guides developers through the pull request workflow for the warp codebase, covering pre-PR validation (merging master, running presubmit checks), review preparation (examining diffs, writing descriptions), and test requirements (regression tests for bugs, unit tests for algorithmic code, layout tests for UI components, integration tests for P0 use cases). Developers use this skill when submitting code changes for review, ensuring all automated checks pass and proper test coverage exists before opening the PR. Key workflows include running ./script/presubmit (cargo fmt, clippy, tests), reviewing changes with git log and git diff, linking Linear tasks via branch naming and PR title, and marking PRs ready for review once feedback is addressed.16.1kinstalls9Update Skillupdate-skill is a workflow for creating and maintaining skill definitions in the Warp repository. Developers use it to generate new skills or refactor existing skill documentation by authoring SKILL.md files with required YAML frontmatter (name, description) and structured markdown content. The skill enforces naming conventions (kebab-case), description best practices (action verb + use case), and file organization rules (keep simple skills under 200 lines in SKILL.md, split complex skills into references/ subdirectories). Key workflows include validating frontmatter with skills-ref, formatting code examples, and following progressive disclosure patterns for clarity.16.1kinstalls10Diagnose Ci FailuresThis skill diagnoses CI failures for pull requests by querying GitHub CLI to fetch PR status, extract error logs from failed checks, categorize errors by type (formatting, linting, compilation, tests, platform-specific), and generate a structured plan document for review. Developers use it when CI checks fail to quickly understand what broke and prioritize fixes without making changes directly. The workflow verifies a PR exists, polls check status, pulls logs from failed runs, groups errors by category, and outputs a plan referencing the fix-errors skill for resolution guidance.16.1kinstalls11BrandalfBrandalf is a branding guidance skill for creating and revising Warp and Oz branded assets. It fetches canonical brand rules from a hosted source covering visual style, typography, voice, component patterns, and naming conventions. Developers use it when building launch pages, documentation, HTML/CSS components, UI mockups, social assets, copy, or presentations that must align with Warp or Oz brand identity. The core workflow is: fetch the canonical brand skill, extract relevant guidance, apply rules to output, and document constraints that shaped decisions.15.9kinstalls12Pr WalkthroughGenerate a static interactive D3 walkthrough of a pull request. Use when the user wants a zoomable PR map, graph/canvas PR orientation, or alternate visualization of PR system components, data flow, code dependencies, and user actions. --- name: pr-walkthrough description: Generate a static interactive D3 walkthrough of a pull request. Use when the user wants a zoomable PR map, graph/canvas PR orientation, or alternate visualization of PR system components, data flow, code dependencies, and user actions. --- # PR Walkthrough Create a local static HTML/CSS/JavaScript walkthrough that orients a reviewer to the current branch's pull request as four separate interactive D3 views. The walkthrough should help the reviewer understand the affected code and the PR from four distinct views: - **System overview view**: a concise standalone code overview for the subsystem touched by the PR. It should not feel like a graph.15.7kinstalls13CouncilCouncil orchestrates multiple subagents with different models and assigned perspectives to investigate the same question in parallel, then synthesizes their independent reports into a final recommendation. Developers use it for high-stakes judgment calls: architecture tradeoffs, risky bug fixes, code review red-teaming, rollout safety decisions, and incident analysis. The workflow frames the question, selects model-diverse council members, briefs them with shared context, collects structured reports covering evidence/risks/confidence, and produces a concise decision memo that compares findings by quality rather than vote.15kinstalls14Check Impl Against SpecCompare a pull request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during PR review when approved or repository spec context is available. --- name: check-impl-against-spec description: Compare a pull request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during PR review when approved or repository spec context is available. --- # Check implementation against spec Use this skill only when `spec_context.md` exists during PR review. ## Goal Determine whether the implementation in the checked-out PR materially matches the approved spec context. This is a supplement to the normal code review, not a separate output. ## Inputs - `spec_context.md` contains the spec context to compare against. It may include both product spec content (intended behavior, acceptance criteria) and tech spec content (implementation details, file changes). - `pr_diff.txt` contains the annotated diff for the PR.14.6kinstalls15Reproduce Bug ReportLaunch Oz cloud agents with computer use to reproduce UI-focused bug reports, capture visual evidence, and report reproduction findings. Use when investigating a specific interactive or visual bug from an issue, ticket, support report, or prompt. --- name: reproduce-bug-report description: Launch Oz cloud agents with computer use to reproduce UI-focused bug reports, capture visual evidence, and report reproduction findings. Use when investigating a specific interactive or visual bug from an issue, ticket, support report, or prompt. --- # Reproduce bug report Use this skill when the current context is a GitHub issue, support report, Linear ticket, or user prompt describing a specific bug that may be reproduced through visible application behavior. It is primarily for UI, rendering, windowing, settings, editor, terminal-display, onboarding, or other interactive bugs where screenshots or recordings make the result more actionable. The parent agent should not try to manually reproduce the UI bug locally unless the user explicitly asks.14.5kinstalls16Respond To Pr Comments In BlocklistWalk users through PR review comments, fetching and displaying them first when needed, collect per-comment response decisions, apply requested fixes, and preview GitHub replies and resolutions before posting. Use when responding to PR review comments on the current branch. --- name: respond-to-pr-comments-in-blocklist description: Walk users through PR review comments, fetching and displaying them first when needed, collect per-comment response decisions, apply requested fixes, and preview GitHub replies and resolutions before posting. Use when responding to PR review comments on the current branch. --- # Respond to PR comments in blocklist Use this skill to respond to PR comments on the current branch. If comments are already visible in the conversation, typically from the built-in `/pr-comments` skill, continue from that context. If comments are not already visible, fetch and display them first, then guide the user through each actionable comment, collect an explicit decision, make requested code changes, and only then ask for approval before posting GitHub replies or resolving review threads.12.9kinstalls17Validate Changes Match SpecsValidate that a branch or pull request implementation matches introduced product, technical, security, and related specs. Use when reviewing or finishing a spec-driven change and resolving mismatches between checked-in specs and implementation. --- name: validate-changes-match-specs description: Validate that a branch or pull request implementation matches introduced product, technical, security, and related specs. Use when reviewing or finishing a spec-driven change and resolving mismatches between checked-in specs and implementation. --- # Validate changes match specs Use this skill to verify that a branch or pull request implements the behavior and design promised by its specs. The workflow finds specs introduced by the change, compares them against code, tests, documentation, and validation artifacts, then walks the user through every material mismatch. ## Goals - Find specs introduced or modified by the current change. - Extract concrete product, technical, security, migration, rollout, and validation commitments. - Compare those commitments against the actual implementation.12.8kinstalls18ResearchThe research skill delegate noisy investigation to one or more subagents so the orchestrator's context stays clean, then work from the distilled answer. Use this skill whenever answering a question would require reading many files, long logs, large diffs, or wide codebase surveys - i.e. when producing the answer generates far more noise than the answer itself. Use it for "how does X work", "where is Y used", "what's the root cause of Z", "summarize this PR/log" style questions, and reach for it liberally before reading a pile of files inline.. Research Use this skill to answer a question by delegating the work of finding the answer to a subagent, so that the byproducts of that work - file contents, log noise, dead-end reads - never enter your own context. You get back a distilled answer plus the evidence that supports it, and you stay sharp for the actual task. Why this matters Your context window is your most valuable and limited resource. Reading twenty files to discover that three9.4kinstalls19Cross CritiqueThe cross-critique skill run a second round on a contested question by circulating each subagent's independent proposal to the other authors and asking for structured pros and cons, then synthesize. Use this skill whenever you have multiple independent proposals or opinions on a contested decision - architecture tradeoffs, code review disagreements, design choices, competing root-cause theories - and want sharper analysis than you'd produce by synthesizing alone. Pairs naturally with the council and research skills; reach for it liberally whenever proposals diverge.. Cross-Critique Use this skill to run a second round after several subagents have independently produced proposals or opinions on the same contested question. Instead of synthesizing their reports yourself, you circulate each proposal to the other authors and ask them to critique it - pros and cons - and then you synthesize the richer set of analyses that results. Why this matters When you generate independent proposals (different models, different angles), each author ends up with deep context on the question - often deeper than yours, since they9.4kinstalls20SagaSaga is an orchestrator skill for medium-to-large feature implementation using a three-phase workflow: spec planning, delegated worker execution, and final validation. The orchestrator transforms rough requirements into airtight specs with explicit validation criteria, then delegates parallelizable tasks to worker subagents while preserving its own context window. State lives in a saga directory (outside the repo) enabling resumption across sessions. Workers self-validate against contracts, commit durably, and report compactly. Human involvement is limited to spec approval and final manual acceptance. Success depends on tight task definitions and validation criteria written before any implementation begins.8.3kinstalls21Write Feature DocsThe write-feature-docs skill draft a complete documentation page for a new Warp feature from its PRODUCT.md and/or TECH.md spec. Use when an engineer has written a spec and needs to produce a first-pass MDX draft for the warpdotdev/docs repo. Also handles features without specs by researching the codebase first. Invoke this skill whenever an engineer mentions writing docs for a feature, drafting a docs page, creating feature documentation, starting the eng-docs workflow, or converting a spec into documentation. Works from w # write-feature-docs Draft a complete documentation page for a new Warp feature. You read the feature's spec, verify technical claims by researching the codebase yourself, present a concise outline for the engineer to confirm, then produce a complete MDX draft and open a draft PR in `warpdotdev/docs` - tagging the docs team for review. The engineer's job is to confirm what you couldn't verify from the spec and code - not to do a full accuracy review, not to polish prose, not to know docs conventions.6.9kinstalls22Scan New SpecsThe scan-new-specs skill scan warpdotdev/warp and warp-server for recently merged PRODUCT.md specs that don't yet have a corresponding docs PR in warpdotdev/docs. When a complete spec is found, auto-generates a full docs draft PR and tags the engineer. When a spec is too thin to draft from, pings the engineer directly. Designed to run as a scheduled Oz ambient agent (e.g., every 2-3 days). Use when setting up the automated docs trigger or running a manual docs coverage sweep. # scan-new-specs Scan `warpdotdev/warp` and `warp-server` for recently merged product or tech specs that lack a corresponding docs draft. For each gap: - **If the spec is complete** - automatically run `write-feature-docs` in ambient mode to generate a full draft PR in `warpdotdev/docs`, then ping the engineer to review it - **If the spec is thin** - ping the engineer directly to either flesh out the spec or kick off the docs workflow manually In both cases, post a summary to `#growth-docs`.6.9kinstalls