Skills versus project instructions

Sort instructions by when they apply

A useful test is whether the rule should apply to a completely different task in the same repository. If yes, it probably belongs with ongoing project conventions.

Move a procedure without moving every rule

Start by listing the steps repeated for one job. Put those steps and their supporting examples in a focused package. Leave repository paths, team policies and broad validation expectations in the project's instructions.

Generated results belong in deliverables/.
Do not change approved source facts without flagging the change.
Explain how reviewers can open the delivered files.

For each update deck:
1. Read the brief and note missing evidence.
2. Organize progress, risk and decisions.
3. Build and inspect the promised output files.

Resolve conflicting instructions explicitly

Different agents have their own loading and precedence rules. Do not assume that a package overrides the project's conventions. If one method wants to publish a result while your task asks for a draft, identify the conflict before taking an external action.

Record the intended scope of a customized Skill. If it only works inside one repository, keep its dependencies and example brief close to that project rather than treating it as a universal personal installation.

Review the two layers separately

• Check project instructions when conventions or review requirements change.
• Check the Skill when the task procedure or supporting tools change.
• Run a representative task after either update.
• Keep local modifications outside an installation before replacing files.

See the agent-specific guides for the exact project file and directory supported by your environment. This comparison explains ownership of the guidance rather than prescribing one universal filename.

FAQ