Skills, MCP or repository instructions? Start with the missing piece

A Next.js developer tried a general workflow skill and reported little improvement over their own prompting. In the same 14 October Reddit discussion, AnimusAstralis described a Qt-widget problem where a custom skill helped after downloaded ones had failed. Neither supplied a controlled comparison. The accounts raise a better question than which skill is popular: what is missing from this task? ^[1]

Use repository instructions for persistent context, a skill for a repeatable procedure, and an integration such as MCP for unavailable capabilities or data. They can work together; choose the missing piece first.

Ask what prevents the task from finishing

Consider a hypothetical dependency-maintenance task: inspect open upgrade requests, identify breaking changes, run the repository's checks and prepare a reviewable pull request. Before extending the agent, list what it can already do.

If its shell already has an authorized repository CLI, it may be able to read pull requests without a new MCP server. If it can read the requests but routinely skips the compatibility matrix, the missing piece is a procedure. If it repeatedly chooses the wrong package manager, the missing piece is stable repository context.

The table is our selection framework. Claude Code's extension overview also distinguishes persistent instructions, reusable workflows, external tools and event-driven hooks; it does not require an MCP server for every task. ^[2]

A skill packages knowledge and execution aids

The Agent Skills specification defines a directory with a required SKILL.md and optional scripts, references and assets. Its metadata describes what the skill does and when it applies; detailed instructions and resources are loaded as needed. Support for optional fields can vary by client. ^[3]

For the dependency example, a useful skill could tell the agent how to classify a change, which compatibility evidence to retain and what makes the result ready for review. A script might extract the package's current version and a template might organize the findings. Merely renaming a long prompt to SKILL.md does not make its procedure correct.

Keep the procedure specific enough to inspect. “Be a senior engineer and make the upgrade safe” leaves every important decision open. “Identify the changed APIs used by this repository, connect each to an affected call site, and record the check covering it” defines an output that can be challenged.

Do not treat skill installation as capability installation. A skill that says to query a private registry still needs an available tool and authorized access. A bundled script may itself call an API, so review its behavior and dependencies as code. The storage format does not tell you what permissions it will need in your environment.

MCP supplies a protocol, not a finished workflow

MCP standardizes communication between an application and servers that expose capabilities. Its core includes tools, resources and prompts. It is therefore too narrow to describe MCP as “only API calls” or to claim that it can never carry instructions. ^[4]

The version dated 28 July 2026 also lists an optional Skills over MCP extension. The specification says extensions require explicit client and server support. A server advertising one does not establish that your installed client consumes it. ^[4]

For the dependency task, the relevant question is whether the connection can perform the exact read or write needed. A registry search tool that returns package names may not expose release notes. A pull-request reader may not create a branch. Verify the actual tool schema and result before building a procedure around an imagined endpoint.

An MCP connection also does not turn returned text into authoritative instructions. Release notes are evidence about a release. Issue comments are statements by their authors. The procedure should use them as inputs while retaining the user's scope and the project's rules.

Compose one narrow workflow

Here is our proposed arrangement for the hypothetical upgrade:

1. Repository instructions name the package manager, generated files and stable public contracts.
2. The task brief names the dependency and required version, plus any explicit non-goals.
3. The upgrade skill supplies the compatibility review procedure and evidence format.
4. An existing tool or MCP connection reads the needed remote material and performs only authorized operations.
5. The repository's actual test and release controls decide what can pass or ship.

The interfaces between those pieces matter more than their names. The skill should state what data it expects and what to do when a required source is unavailable. The task should not silently expand into upgrading unrelated packages because the integration makes them easy to discover.

This also keeps failures diagnosable. If the agent cannot read the private registry, repair access. If it reads the changelog but misses an affected call site, repair the review method. If it understands the change but skips a mandatory check, inspect the enforcement. Adding a second skill addresses none of those failures automatically.

Judge the setup by an accepted change

Try the extension on one representative upgrade before distributing it across repositories. Keep the same acceptance criteria and record rework, missed compatibility issues, unnecessary reads and total effort. Our analysis of delegated work^[5] explains why a cheaper individual operation does not establish a cheaper accepted task.

Use the Reddit contrast as a reason to test local fit, not as proof that custom skills always win. A downloaded skill might encode valuable knowledge you lack. A home-grown skill might simply preserve your existing mistake more consistently.

Choose one missing piece in your current workflow and add only the mechanism that supplies it. Keep the extension when the resulting artifact makes review easier; revise or remove it when it adds ceremony without resolving the original gap.