warpdotdev/common-skills
17 skills47.4k installs306 starsGitHub
Install
npx skills add https://github.com/warpdotdev/common-skillsSkills in this repo
1Review Prreview-pr is an agent skill from Warp’s common-skills pack for solo and indie builders who merge their own GitHub PRs and want review discipline without a full-time reviewer. It wires your coding agent to GitHub’s REST and GraphQL endpoints so a review pass can fetch pull request details, enumerate issues that close or were manually connected on the timeline, and relate the change set to spec context stored in the repository. When no approved or repository spec is available, the workflow returns a clear message instead of inventing requirements. The implementation is Python with urllib, argparse, and path resolution keyed off OZ_REPO_ROOT, which fits agents that execute repository scripts during Ship. Use it on open PRs before merge when you care about traceability to issues and alignment with written specs—not for greenfield coding or distribution work.3.5kinstalls2Resolve Merge ConflictsResolve-merge-conflicts is a Git-focused agent skill that wraps a Python utility to inventory unmerged paths and extract compact conflict hunks from your working tree. Solo builders and small teams hit painful three-way markers when syncing main, rebasing feature branches, or pulling dependency updates; dumping raw files into chat burns context and invites mistakes. The skill runs git against the repository root, walks conflict records, and returns structured summaries so Claude Code, Cursor, or Codex can propose resolutions file by file. It fits the build phase when integrations land and again during ship when you merge release or hotfix branches. It is procedural glue—not a hosted merge bot—so you still review and stage the final hunks. Pair it with your normal PR and code-review habits; use when git status shows unmerged paths or when the user explicitly asks to summarize or fix merge conflicts.3.5kinstalls3Fix ErrorsFix Errors is a Warp-maintainer agent skill that walks you through resolving compilation, Clippy, formatting, WASM-target, and test failures in the Warp Rust workspace. It is written for contributors who already cloned warpdotdev/warp and hit red presubmit—not for generic Rust tutorials. The skill centers on `./script/presubmit` as the all-in-one gate, then documents how to run individual checks when you need a tighter feedback loop. Expect workspace-wide Clippy with warnings denied, a separate pass for the `warp_completer` crate, WASM clippy on `wasm32-unknown-unknown`, and native formatting checks including clang-format for Objective-C/C/C++ sources. Use it when the user reports build breaks, lint noise, or flaky or failing tests and intends to land a Warp PR. Outside that repo, the commands and crate split will mislead you.3.5kinstalls4Write Product Specwrite-product-spec guides agents to author PRODUCT.md for significant Warp features where behavior is easy to misread. Solo builders and small Warp contributors use it when a feature is user-visible or when the consumer is another developer, service, or agent touching an API, data model, CLI, or library. The skill forces a single lens: what the consumer sees, can do, and can rely on—including edge cases—while ruling out internal type layouts and data-flow commentary that invite wrong implementations. That makes it valuable in Validate when scope is still fuzzy and in early Build when PM-style clarity prevents expensive rework during Ship review. Reach for it when someone asks for a product spec, PRD, or desired-behavior document before coding, especially when the change is large enough that chat-only planning would drift.3.5kinstalls5Spec Driven Implementationspec-driven-implementation is a Warp-originated agent skill that keeps substantial features honest by checking product and technical intent into the repo before agents write code. It prescribes a simple layout: each Linear ticket gets a directory under `specs/` containing PRODUCT.md (always for big work) and TECH.md when engineering choices need capture. Agents are told to use Linear MCP tools to discover teams and labels, create missing issues, and avoid engineer-named or feature-slug folders that would fragment history. The skill is pragmatic—routine fixes skip the ceremony—while agent-driven or ambiguous efforts benefit from reduced rework and easier human review. Solo builders adopting the same pattern get diffs that explain why features exist, not just what changed. Maintenance means updating both specs as implementation diverges, treating them as living documents tied to ticket numbers rather than one-off pitches.3.5kinstalls6Diagnose Ci Failuresdiagnose-ci-failures is an agent skill that programmatically inspects pull-request CI on GitHub, pulls failure logs, and synthesizes a human-reviewed plan to fix issues. Solo builders shipping through GitHub depend on green checks but rarely want the agent to silently rewrite code from noisy logs. This skill standardizes verification that a PR exists for the current branch, reads rollup status via gh, waits or reports when jobs are still running, and drills into failed runs for actionable error context. Output is always a plan document suitable for approval before edits. It pairs naturally with PR workflows and explicitly defers PR creation to create-pr when missing. Use it when CI is red after a push, when triaging flaky tests, or when you need a structured narrative of what broke across multiple jobs.3.5kinstalls7Update Skillupdate-skill captures Warp-aligned best practices for authoring and updating agent skills in `.agents/skills/`, with emphasis on progressive disclosure and maintainable reference layouts. Solo builders curating Claude, Cursor, or Warp skill libraries use it whenever a skill grows past a short SKILL.md—before shipping a bloated prompt that wastes context on every trigger. The guidance covers when to extract references, how deep linking should work, and organizational patterns for multi-domain skills. It is journey-wide methodology: the same rules apply while brainstorming docs in Idea, tightening ship checklists, or revising growth playbooks encoded as skills. Outcome is a lean trigger surface plus navigable reference files agents load only when the user’s task needs that depth.3.5kinstalls8Write Tech Specwrite-tech-spec is an agent skill for turning significant Warp feature intent into a TECH.md implementation plan grounded in the real repository. It is aimed at solo and indie builders (and small teams) who already have or are drafting a product spec and need a durable architecture and execution document—not ad-hoc chat planning. Use it when work spans multiple modules, involves meaningful tradeoffs, or when you want reviewers and coding agents to share one source of truth. The skill defines where files live under specs/<id>/, how ids relate to PRODUCT.md, and when to pull ticket metadata via Linear MCP or gh. The output makes later build and ship steps safer because constraints and choices are explicit before code changes land.3.5kinstalls9Create Prcreate-pr is a workflow skill for solo and team contributors working in the Warp repository who need to open or update pull requests without skipping repo hygiene. It walks through merging master into the feature branch, resolving conflicts before review, and running presubmit when the diff includes Rust or other code—formatting, Clippy as errors, and unit, doc, and integration tests. Docs-only changes such as skills or markdown can skip presubmit. The guide also points to companion skills for fixing presubmit failures, adding integration tests for user-visible flows, and gating risky work behind feature flags. Use it whenever you mention opening a PR, creating a pull request, submitting for review, or preparing code for merge so the branch matches team expectations and reviewers see a structured, test-backed change set.3.5kinstalls10Implement SpecsImplement-specs bridges approved planning artifacts and executable software for solo builders who document features as PRODUCT.md and TECH.md under a ticket folder. It is not for brainstorming or drafting specs from scratch—you confirm PRODUCT.md exists, TECH.md when warranted, and that reviewers have signed off enough to start. During implementation, user-visible behavior must stay consistent with PRODUCT.md while structure and sequencing follow TECH.md. The skill emphasizes a single pull request that carries spec updates alongside code so reviewers never chase a drifting narrative. That pattern suits indie teams shipping scoped tickets without a separate spec handoff meeting. As implementation reveals edge cases, you update the checked-in specs in the same branch rather than leaving silent divergence between docs and runtime behavior.3.5kinstalls11BrandalfBrandalf is an agent skill entrypoint for Warp and Oz branding work. Solo builders and small teams use it when creating or revising launch pages, documentation, HTML/CSS components, UI mockups, prompts, social creative, copy, or presentations that must read and look unmistakably on-brand. The skill treats a hosted URL as the single source of truth and instructs the agent to fetch it before relying on memory, then apply visual, typographic, voice, component, and capitalization rules to the requested deliverable. It is not a generic design system generator; it is a compliance workflow for two named brands plus related ADE materials. When the canonical URL is unavailable, the agent should say so and ask whether to retry or proceed with best-effort guidance.3.2kinstalls12Pr Walkthroughpr-walkthrough is a Warp common-skills package for building interactive, D3-powered tours that explain pull request changes as connected graphs rather than a flat file list. Solo and indie builders shipping through GitHub-style flows can use it when a diff is correct but hard to reason about—especially refactors, dependency moves, or multi-module features. The skill ships Python utilities that scaffold a walkthrough shell (header, stepped navigation, themed panels) and wire multiple SVG/graph views so reviewers see how pieces relate. It targets developers who already review in the browser and want a shareable HTML artifact for async review or launch notes. Complexity is intermediate because you need basic comfort editing generated HTML or Python glue and hosting a static page. It complements textual review checklists by making structure visible; it does not replace tests, security review, or line-by-line comment threads.3kinstalls13Check Impl Against SpecCheck implementation against spec is a checker skill for solo and indie builders who keep approved specs in spec_context.md and want PR review to catch drift before merge. It activates during PR review when that file is present, then walks a three-step process: parse concrete commitments from product and tech spec content, compare them to the annotated diff and working tree, and distinguish harmless naming or structure differences from material mismatches in behavior, scope, or required follow-ups. Outputs integrate into review.json rather than spawning a separate artifact, so it fits Warp-style review pipelines where one agent session owns the full review. Best when you already document intended behavior and planned changes in spec context; skip when no spec file exists or you are not in a PR review flow.2kinstalls14CouncilCouncil is a journey-wide orchestration skill for solo builders who want more than one agent take on the same hard question. You state the decision in one sentence, name competing options or hypotheses, point agents at a branch, PR, design, or issue, and decide whether subagents stay read-only or may edit code. Members should differ by model and by assigned lens so findings are not echo copies. Warp’s workflow walks from framing through parallel investigation to a synthesized final recommendation weighted on correctness, risk, cost, testability, rollout safety, or product behavior. It shines before irreversible merges, during incident postmortems, or when choosing between two technical paths. Use it whenever the user explicitly asks for a council, parallel investigation, or multiple models on one problem—not for trivial one-shot edits.1.9kinstalls15Reproduce Bug ReportReproduce Bug Report is a workflow skill for indie teams who need credible evidence that a UI bug is real before anyone burns a day on the wrong fix. The parent agent reads the ticket, separates expected from reported behavior, and notes environment constraints such as OS, build channel, feature flags, and account state. Instead of guessing locally, it launches one or more Oz cloud agents with computer use enabled so they can open the product, execute repro steps, and return screenshots or recordings. That makes the output useful for Ship QA gates and for Operate when regressions surface from support. The skill is intentionally narrow: visible application behavior—editors, terminals, settings, layout, onboarding—not headless logic bugs with no interactive path. Warp-oriented repos benefit most, but any solo builder maintaining a desktop or web UI can adopt the pattern when Oz access is configured.1.9kinstalls16Respond To Pr Comments In BlocklistRespond to PR comments in blocklist is a guided workflow for solo and indie builders who need to handle GitHub pull request feedback without accidentally posting half-baked replies. It assumes you are on the correct branch in the PR repository. When review comments are not already in the chat, it fetches and displays them—preferring the built-in `/pr-comments` flow, with GitHub CLI as fallback—so every thread has enough metadata to act on. You then move comment by comment: choose how to respond, implement requested changes locally, and only at the end review a preview of what would be sent to GitHub and which threads would be resolved. That approval gate matters for agents that might otherwise auto-reply or resolve threads prematurely. It pairs naturally with code-review skills and keeps ship-phase review disciplined: visible comments, explicit decisions, aligned code, then controlled publication.271installs17Validate Changes Match SpecsValidate Changes Match Specs is a checker skill for solo builders practicing spec-driven development. It starts from the real change set—PR base or `git merge-base` diff—finds specs added or modified on the branch, turns prose into concrete obligations, and audits whether code, tests, documentation, and validation artifacts actually satisfy them. When something drifts, it does not guess: it surfaces each material gap and lets you choose implementation fixes versus spec updates, then applies that choice systematically. Primary home is Ship review before merge, but it also supports Validate when a prototype must match an agreed spec and Build when docs and PM specs land alongside features.145installs