The short answer
Put stable project conventions in repository instructions or the client’s rule mechanism. Use a skill for a reusable procedure selected when a matching task arises, and use the task prompt for today’s inputs and scope. Avoid copying the same policy into all three places.
What belongs in your Skiller library
Skiller manages installed agent skills: you can inspect their instructions, edit SKILL.md and synchronize copies across selected agents. Use that library for reusable procedures you want to discover and invoke. Keep repository-specific commands and conventions in the project's instruction files.
For example, keep a general release-review procedure as a skill, then have it read the active repository's instructions for the test command and release-note location. When you inspect the skill in Skiller, check that it refers to project guidance instead of carrying an obsolete copy of it.
This also makes updates easier to reason about. A change to one repository's build command belongs in that repository. A better method for checking release claims belongs in the shared skill, which you can review and sync to the clients that use it.
Separate project facts from procedures
When an agent ignores an instruction, adding another copy of it can feel like the fastest fix. Over time, the repository file, several skills and personal rules disagree. A better starting point is deciding where each instruction belongs and which source owns future updates.
Repository instructions describe the project: its commands, architecture, conventions and boundaries. A skill describes a repeatable procedure: how to review a migration, investigate a bug or prepare release notes. The task prompt supplies the current request, inputs and scope. These can work together without repeating every instruction in every file.
Choose the appropriate location
| Instruction | Suggested home |
|---|---|
| Use the repository's package manager and test command | Repository instructions |
| Review database migrations for compatibility | A migration-review skill |
| Review this diff without publishing anything | The current task prompt |
| Apply a convention only to a specific file type | A supported scoped rule |
Each client has its own mechanism for loading instructions. Codex documents AGENTS.md; Cursor provides rules and documents its support for project instructions and skills. Consult the target client's documentation for scope and precedence. A familiar filename does not guarantee identical behavior across clients.
Split a release workflow cleanly
Suppose your team prepares a release every Friday. The project instructions can state the real build and test commands, where release notes live and which generated files should not be edited. Those facts belong close to the code and should change when the project changes.
A release-review skill can tell the agent to compare notes with the requested Git range, identify user-visible changes, inspect migrations and report unsupported claims. It should read the repository instructions to learn the project's actual commands rather than bundling an outdated copy of them.
# Repository instruction
Use the documented project commands for build and tests.
Release notes are maintained in CHANGELOG.md.
# Skill procedure
1. Read repository instructions.
2. Compare the supplied release notes with the requested diff.
3. Verify claims and report missing migration guidance.
# Task prompt
Review these notes against main...release-candidate.
Do not edit files or publish the release.This division makes the workflow portable. Another repository can use the same procedure with different commands and a different release-note location. Read how to write SKILL.md for a complete procedural example.
Avoid duplicated authority
If a skill and a repository file both define the test command, choose one owner. Leave a reference in the other location where appropriate. Do not turn a portable skill into an inventory of every repository you use; have it locate and read the project's guidance.
Keep personal style preferences separate from shared engineering requirements. A global preference suitable for a solo project may be wrong in a team repository. If the agent reports conflicting instructions, resolve the source conflict before expanding the skill. Do not assume a procedural file can override the client's higher-priority instructions.
Check which instruction was loaded
Before changing content, verify the active project and the paths your client scans. A missing nested instruction file and an ambiguous skill trigger are different failures. Test a small task that reveals the relevant convention, then invoke the skill explicitly to check its procedure.
When using several clients, maintain the shared content deliberately and test each supported environment. The cross-agent sharing guide covers copy management. Shared text is useful, but client scope and selection behavior still need their own verification.
FAQ
Should an instruction go in AGENTS.md or a skill?
Put repository conventions in AGENTS.md or the client’s project rules. Put a reusable task procedure in a skill when it should be selected only for relevant work.
Can skills replace all Cursor rules?
Usually not. Persistent project guidance and task-specific procedures have different jobs. Keep each instruction in the place that owns it.
What does Skiller manage in this workflow?
Skiller manages reusable skill content and agent targets. Keep repository instruction files and project rules in their appropriate locations.
Your skills. One place.
Inspect, edit and sync your skill library across coding agents.
Download Skiller
