# Adapting Prior Art URL: https://stevekinney.com/courses/ai-development-setup/adapting-prior-art Canonical: https://stevekinney.com/courses/ai-development-setup/adapting-prior-art Author: Steve Kinney Language: en-US Modified: 2026-10-05T04:17:56.000Z Description: Treat popular skills as exemplars, not installs. Adapt each one to your codebase, because specific instructions beat generic advice almost every time. Course: AI Development Setup Course URL: https://stevekinney.com/courses/ai-development-setup --- There are a lot of popular plugins chock full of skills and other functionality. (A _plugin_ is a bundle of skills, hooks, and other pieces you install in one step.) It's tempting to install a few and call the setup done. My advice, which may be controversial, is to treat these as inspiration and exemplars, and then tailor them to the unique needs of your codebase. Specific instructions will often beat more generalized guidance. A skill that explains TypeScript to an agent that already knows TypeScript isn't doing much. A skill that explains _how your repository_ does things is. Here's a tour of skills worth stealing from, and what I'd change about each one. If you haven't yet, [Skills](skills.md) explains the pieces. ## Adapted examples - **`implement-project-feature`** (my own idea, not borrowed from a published skill): Instead of explaining Next.js or TypeScript generally, give the agent a small set of exemplary features from your _actual_ codebase. Teach it how to choose the relevant example, trace the implementation, and adapt the pattern without copying unrelated machinery. The trick is to tune this skill to the specifics of _your_ code. - **`root-cause-analysis`**: Inspired by [Superpowers' `systematic-debugging` skill](https://github.com/obra/superpowers/tree/main/skills/systematic-debugging) (Superpowers is a popular plugin full of skills), which codifies a staged process: investigate the root cause, compare patterns, test a hypothesis, and then (and _only_ then) implement a fix. My adaptation requires a reproducible scenario, a small set of competing explanations, and an experiment that distinguishes them. The result includes the evidence supporting the diagnosis, not just a patch. It replaces speculative editing with an investigation that makes each subsequent action more informative. - **A test-driven development skill**: Test-driven development means writing the failing test first. Inspired by [Matt Pocock's `tdd` skill](https://github.com/mattpocock/skills/tree/main/skills/engineering/tdd). A repository-specific adaptation should teach the agent which boundaries to test through, which collaborators to keep real, and what good tests look like in this project. - **A web application testing skill**: Inspired by [Anthropic's `webapp-testing` skill](https://raw.githubusercontent.com/anthropics/skills/main/skills/webapp-testing/SKILL.md). Record how to start _your_ application, load synthetic test data, authenticate a test user, and navigate to the relevant feature. I'd write any helper scripts with the repository's existing TypeScript and browser tooling, rather than add a separate toolchain just for testing. - **A CI repair skill**: CI is continuous integration, the service that runs your checks on every push. Inspired by [OpenAI's `gh-fix-ci`](https://raw.githubusercontent.com/openai/skills/main/skills/.curated/gh-fix-ci/SKILL.md), which inspects GitHub Actions checks and logs, extracts the actionable failure, proposes a plan, and separates investigation from approved implementation. An adaptation would also compare the failing revision with a relevant baseline. It would distinguish an application regression from an infrastructure failure, missing configuration, or an existing flaky test. - **A verification skill**: Inspired by [Superpowers' `verification-before-completion`](https://github.com/obra/superpowers/tree/main/skills/verification-before-completion), which requires fresh verification evidence and distinguishes different claims. A passing linter doesn't establish that a build succeeds, and a passing test suite doesn't automatically establish that all requirements were implemented. An adaptation would map each acceptance criterion to evidence, rerun relevant checks after the final edit, inspect the final diff, and explicitly report anything that couldn't be tested. (This is the evidence-to-claim matching from [Verification and Evidence](verification-and-evidence.md), packaged up as a skill.) - **Research an integration and finish with a decision**: This should be much more specific than "research this library." I'd have it determine the versions involved, consult primary documentation, identify constraints in the existing application, and build the smallest disposable experiment that resolves the most important uncertainty. The output contains a recommendation, supporting evidence, unresolved questions, and a minimal working example, or a concrete explanation of where the experiment failed. ## Playbooks Inspired by [Vercel](https://github.com/vercel-labs/agent-skills/tree/main)'s [`composition-patterns`](https://github.com/vercel-labs/agent-skills/tree/main/skills/composition-patterns) and [`react-best-practices`](https://github.com/vercel-labs/agent-skills/tree/main/skills/react-best-practices), you can build a _playbook_: a skill made of rules and a style guide rather than a step-by-step procedure for one task. Codify your own, and it pushes agents into making better decisions. They hold up even better when you back them up with lint rules or some other external check. A rule the linter enforces doesn't depend on the agent remembering it. ## Inspiration These are skill ideas that don't come from any one source. Each one changes what question the agent is answering. A few of them (a fresh session, an isolated copy, a disposable environment) can't happen inside your current conversation. Run those as a forked skill or a subagent, or have the skill call a script. [Skill or Subagent?](skill-or-subagent.md) covers the choice. - **Explain why this weird code exists**: Before simplifying suspicious code, have the skill inspect its introduction, related changes, tests, comments, and available issue history. - **Find counterexamples to the specification**: Rather than ask the agent to critique a specification abstractly, require concrete scenarios in which two reasonable implementations would behave differently. The skill generates cases involving transferred ownership, membership removal, in-flight jobs, shared resources, and deletion requested twice. It then separates questions answerable from existing policy from decisions that actually need your input. - **Prove these tests notice broken behavior**: After adding tests, deliberately introduce a few targeted defects in an isolated copy and check whether the tests detect them. The skill should justify each mutation, verify that it changes the relevant behavior, run the narrow test set, and restore the isolated copy. An equivalent mutation (a change that doesn't alter the code's behavior, so no test could catch it) or an unrelated compilation error shouldn't count as useful evidence. - **Design the API from the caller's side first**: Require realistic usage examples before implementing the abstraction: a simple case, a composed case, an advanced case, invalid usage, and migration from the current API. The skill compares a few API shapes against the same examples, then evaluates inference, discoverability, diagnostics, runtime behavior, and implementation complexity. - **Review what the diff forgot to change**: Instead of reviewing only edited lines, infer the feature's affected surfaces and inspect the ones that were left untouched. Say a pull request adds API-key creation. The skill checks whether expiration, revocation, permission checks, audit events, SDK exposure, documentation, and tests are relevant, and whether they were addressed. It should derive expectations from the requirements and comparable features, not declare every imaginable integration mandatory. It changes the review question from "Is this code reasonable?" to "Is this change complete?" - **Generate fixtures designed to embarrass the interface**: Have the skill produce deterministic, reproducible test data that targets the assumptions of a particular interface. For a project picker, I'd request duplicate names with different identifiers, very long names, Unicode, archived entries, missing optional metadata, mixed permissions, no results, and enough entries to exercise pagination. - **Rehearse failure and recovery**: Use this for asynchronous jobs, workflows, event processing, uploads, and external API calls. The skill identifies important interruption points, defines the expected recovery behavior, and creates controlled experiments in a disposable environment. - **Find a smaller change that still satisfies the requirements**: After implementation, ask the skill to challenge the necessity of new abstractions, configuration, dependencies, and unrelated edits. The skill must preserve a fixed acceptance checklist and compare alternatives in an isolated branch or copy. Passing existing tests alone is insufficient when they don't cover a requirement. - **Pretend the next maintainer didn't watch us build this**: Start from a clean checkout and a fresh session (a new conversation with no history), and use only committed documentation and supported setup procedures. Try to start the application, run relevant tests, locate configuration, exercise the feature, and diagnose one representative failure. - **Extract a reusable procedure from what we just learned**: After a difficult task, inspect the actual session evidence: failed approaches, corrections, successful commands, missing context, and the final verification. That's how most of your own skills should start. Many of these ideas also work as [subagents](exemplar-subagents.md) when you want them run in a separate context. Borrow the structure, then replace every generic example with one of yours.