The 27 skills cover real engineering work, with Warp assumptions attached
Common Skills is more useful than a folder of generic prompts. Its 27 skill files cover product and technical specs, implementation, CI diagnosis, error fixing, merge conflicts, pull-request review, bug reproduction, research delegation, and skill evaluation. Several entries include Python helpers, HTML assets, references, or JSON evaluation cases. The repository's organizing rule is sensible: reusable procedures live here, while repository-specific details should stay beside the project that needs them.
The collection does not always meet that rule yet. create-pr names the Warp repository, merges master, runs ./script/presubmit, looks for Linear tasks, and refers to internal companion skills. The README acknowledges that copied skills may retain local paths and assumptions. At commit f589e22, our 3-CPU, 8 GB lab had no supported project ecosystem or Dockerfile to execute, so we could not test whether an outside repository can install and use the advertised set cleanly.
Spec and review instructions are the strongest place to start
The spec group separates user-facing PRODUCT.md decisions from implementation-oriented TECH.md details, then connects approved documents to implementation and review. That chain gives an agent explicit checkpoints instead of asking it to infer product intent from a ticket. Review skills are similarly concrete: they resolve spec context, inspect diffs, classify findings, and produce structured feedback. The better files name when to stop, when to ask, and which evidence must be present before a remote action.
Some entries show evidence of revision rather than one-shot prompt writing. The write-pr-description folder contains 9 evaluation scenarios ranging from a 2-line change to a large foundational branch. Its commit history records changes made after outputs were too long or missed a security decision. None of those evaluations ran in our sandbox at f589e22, so they are repository evidence rather than lab results. Still, keeping cases beside the skill makes the intended behavior easier to review than a prose claim that the prompt is effective.
What happened when we ran it
We did not run Common Skills. The laboratory checkout used commit f589e22 in an unprivileged Debian container, but the harness found no supported ecosystem despite GitHub identifying Python as the primary language. No Dockerfile offered a container path. We therefore have no install time, build outcome, test result, dependency count, disk figure, or vulnerability audit to attach to this repository.
That outcome reflects the repo's mixed format. Most content is Markdown, while selected skills carry Python scripts, shell utilities, browser assets, or evaluation data. The 3 CPUs and 8 GB assigned to our sandbox never became a meaningful constraint because no standard project target started. A future lab profile for skill collections would need to validate frontmatter, install selected skills into supported harnesses, run included helper tests, and confirm that paths and commands resolve outside Warp's own repositories.
Installing every skill globally imports avoidable policy
The README offers an npx skills@latest command to inspect the catalog, install one named skill, or install * globally for Warp. The repository scripts add lock files, project and global targets, hash verification, and downstream updates. That is better version hygiene than copying folders by hand. Yet a global wildcard also installs deprecated, specialized, and internally flavored instructions that may trigger in unrelated projects. The README's own advice to copy only what a repository needs is the safer default.
The bootstrap path deserves a separate security decision. scripts/README.md shows a resolver fetched from raw GitHub and piped into Bash, then documents commit and branch overrides. Our f589e22 lab run did not execute that command. Pinning the reference narrows drift, but piping remote code into a shell still grants that fetched content the user's permissions. Regulated or high-trust environments should vendor and review the installer, then verify its hash before execution instead of relying on the moving main branch.
Skill Doctor is useful today for 3 harnesses, not every agent
skill-doctor reads local conversation histories, scores efficiency and code quality, drafts evidence-based edits, and renders a self-contained report. Its instructions say transcripts must remain local and list Warp, Claude Code, and Codex sources. That is a serious workflow with privacy boundaries, sampling rules, scoring rubrics, and a stop condition when the harness cannot be identified. It is also more invasive than a normal writing skill because it reads past sessions and may propose changes to installed instructions.
The limits are visible in current issue activity. Issues 84 and 86 request Amp and OpenCode support, while related pull requests were already open on August 29, 2026. The repository had 3 open issues and 29 open pull requests, and its last push was the same date as our f589e22 commit. That pace suggests active maintenance, though the absence of releases leaves consumers to choose a commit themselves. Start with one well-scoped skill and keep local overrides beside the repository that owns them.