Separate Project Instructions from One Task's Request

Put repeated project guidance where future work can find it, and keep temporary experiments with the task that needs them. Before promoting a note into an instruction file, identify its intended scope, lifetime, and evidence status.

An experiment can accidentally become a permanent convention when a handoff says “use the compact layout” without retaining the experiment boundary. A sample observation can become an invented requirement when “eight rows appeared” is rewritten as “always discard blank rows.” Classifying the note first prevents those changes in meaning.

The fictional repository below has two code areas, ui/ and parser/. Its notes, instruction examples, and cleanup history are original teaching materials. No real repository instructions or agent settings were changed, and no project commands were run.

Give each note a scope and a lifetime

The example's code map is small:

ui/
└─ cards/note-card.tsx
parser/
└─ readers/rows.py

Proposed supporting documents:
.github/copilot-instructions.md
.github/instructions/ui.instructions.md
.github/instructions/parser.instructions.md
decisions/0001-parser-boundary.md
evidence/observation-E1.md
evidence/commands-to-check.md
tasks/EXP-12.md
tasks/COPY-13.md

These paths describe the fictional design; they are not a runnable checkout. There is no package manifest or implemented validation command in this teaching package.

Here are all eight candidate notes before classification:

ID	Complete candidate note
N01	Preserve agreed public input/output contracts during a scoped change. In completion notes, distinguish code inspected, checks actually run, and checks still unrun.
N02	In `ui/`, a control that only opens the local preview is labeled `Open preview`. Keep the separate send action distinct.
N03	In `parser/`, `read_rows` returns records to its caller; keep file writes and network work outside that function.
N04	For experiment EXP-12, compare compact and wide note-card layouts in a local proposal. Do not treat compact as the project default.
N05	The fictional project chose a separate parsing module so its interpretation rules can be discussed independently from rendering. Record why this boundary was chosen and when to revisit it.
N06	An illustrative note E1 says one sample list showed eight rows rather than nine. The cause and the treatment of blank rows are unknown.
N07	A draft handoff proposes `npm run check:board` as the validation command, but no package manifest or run record is supplied.
N08	For task COPY-13, investigate a note-card wording proposal from `Open preview` to `Preview now`. Return a wording-only proposal; do not turn it into a permanent label convention.

The notes contain different kinds of information. Repetition alone would not make N07 a verified command, and a short lifetime would not make N04 unimportant to its experiment.

Choose one primary home for each note

Note	Primary home	Scope and lifetime
N01	Repository guidance	Both code areas, across routine tasks until the policy changes
N02	Path guidance	`ui/`, until its interface contract changes
N03	Path guidance	`parser/`, until its function contract changes
N04	Task message	EXP-12 only; ends with that experiment
N05	Architecture decision record	Preserve the historical rationale, including a replacement pointer if superseded
N06	Evidence record	One illustrative observation with an unresolved cause
N07	Evidence record and follow-up verification item	Unchecked command proposal, not a known working instruction
N08	Current task message	COPY-13 only; the proposed wording still needs a decision

N05 explains why a boundary exists. N03 tells routine parser work to preserve its current contract. Keeping their roles distinct avoids turning every architecture paragraph into an operational command.

N06 also needs careful wording. Its evidence record should retain the limited statement and the unknown cause. It should not introduce a blank-row filtering rule that no requirement selected.

Use a host-bounded file example

GitHub documents repository guidance in .github/copilot-instructions.md and path files under .github/instructions/ using applyTo globs. Its Copilot-on-GitHub instructions page describes path support for the cloud agent and code review, with matching repository and path instructions both used. The following syntax illustrates that documented host scope; check the chosen feature and settings before adapting it elsewhere.

The complete proposed repository file contains N01:

# Shared project guidance

Preserve agreed public input/output contracts unless the current agreed task changes them.

In completion notes, distinguish code inspected, checks actually run, and checks still unrun.

The complete UI path file contains N02:

---
applyTo: "ui/**"
---

For a control that only opens the local preview, retain the label `Open preview`. Keep the separate send action distinct.

The complete parser path file contains N03:

---
applyTo: "parser/**"
---

Preserve the `read_rows` contract: return records to its caller, keeping file writes and network work outside that function.

No command is listed as verified. N07 remains in evidence/commands-to-check.md, with status NOT_RUN and the missing command definition identified. A later task can inspect the actual project and establish an appropriate check before anyone presents a command as known to work.

Write the applicability matrix before relying on it

Here is the intended scope of those notes:

File being worked on	Repository guidance	Path guidance	Temporary request
`ui/cards/note-card.tsx`	N01	N02	N04 during EXP-12, or N08 during COPY-13
`parser/readers/rows.py`	N01	N03	Neither UI task applies
`decisions/0001-parser-boundary.md`	N01	No UI/parser path note	Only the task that is actually updating this record

The UI label rule should not become parser behavior. An observation about one sample should not become a rule for any path. An old experiment should not remain active merely because a later task can still read its record.

This matrix is an authored applicability contract, not a test of a host's matching or instruction enforcement. If a task touches several paths, the host may supply guidance relevant to more than one area. Keep each rule's own subject explicit and verify the actual host's supported mechanism rather than assuming file separation isolates all context.

Remove a temporary rule without losing its history

Suppose a bad draft of repository guidance has accumulated these lines:

Always use the compact layout for UI work.
Always discard blank rows.
Always run npm run check:board before describing a change.

Those lines incorrectly promote N04, N06, and N07. A useful cleanup history makes the correction visible:

Step	What changes in the proposed documents	What remains true
H0	Identify the three bad standing directives	This is an invented bad draft, not installed configuration
H1	Reclassify N04 as temporary, N06 as observation, and N07 as unchecked	Their original meanings remain available
H2	Remove those directives from durable guidance	EXP-12 retains its task note; E1 and the command proposal retain evidence records
H3	Close EXP-12	No compact-layout default carries into later work
H4	Open COPY-13 and compare its wording proposal with N02	The `Open preview` path rule remains until its intended change is resolved

Do not delete the experiment's history to make the present guidance look consistent. Retaining the task record explains why a compact variant was once considered without telling every future UI task to use it.

Make the remaining conflict explicit

COPY-13 proposes Preview now, while N02 retains Open preview. The agent should identify that conflict before treating either phrase as a settled new convention. A useful response asks whether the person intends a temporary wording comparison or a durable change, and names the affected control.

Avoid inventing a universal rule such as “the newest message always overrides the path file.” Host instruction handling and the current human's intended scope must be established in their own context. The example does not prescribe a hierarchy for every coding agent or imply a CueSpec feature.

Use this complete request for the first investigation step:

For COPY-13, investigate a wording-only proposal in ui/cards/note-card.tsx:
Open preview -> Preview now. Preserve what the action does and keep the
send action separate. Do not edit files in this first step.

Read the applicable project/path guidance. Identify N02's existing Open
preview rule and report the conflict. Ask whether this is a temporary
comparison or a durable label change; do not decide that by guessing
instruction precedence.

Keep EXP-12's compact/wide experiment out of this task. Treat E1 as an
illustrative observation with unknown cause, not a blank-row requirement.
Treat npm run check:board as an unverified proposal, not a checked command.

Before proposing instruction-file edits, verify the chosen host/feature
supports the repository/path mechanism and state its intended matching
scope. If it differs from the GitHub example, explain that difference.

Return the applicable-note map, the one-control wording proposal, the
unresolved decision, and a validation plan grounded in the actual project.
No package installation, project execution, real instruction-file edits,
publication or deployment in this investigation step.

GitHub's task guidance supports describing a clear problem and acceptance criteria and investigating before implementation. The eight-note classification and cleanup history here are our worked method for making that request precise.