WEBVTT

1
00:00:00.000 --> 00:00:02.485
A task prompt explains what you want now.

2
00:00:02.810 --> 00:00:06.595
Project instructions explain what
usually matters in this repository.

3
00:00:06.978 --> 00:00:10.681
In this lesson, we will write
a concise AGENTS dot md file

4
00:00:10.809 --> 00:00:14.106
that points an agent toward the
right context and verification.

5
00:00:14.617 --> 00:00:18.147
Start with your preserved checkpoint-two
project. You should already

6
00:00:18.205 --> 00:00:22.083
understand the README, hardware reference,
and the available replay and build

7
00:00:22.129 --> 00:00:26.100
commands. Think about the information
you keep repeating in coding requests.

8
00:00:26.541 --> 00:00:29.095
Read the requirements
before changing policy.

9
00:00:29.536 --> 00:00:32.717
Use the exact board reference
before making hardware claims.

10
00:00:33.101 --> 00:00:36.084
Keep the change bounded.
Report actual results.

11
00:00:36.467 --> 00:00:41.019
These expectations are useful across
tasks, so they deserve a maintained home.

12
00:00:41.402 --> 00:00:44.874
Repeating them from memory in every
prompt makes it easy to omit one

13
00:00:44.897 --> 00:00:48.995
when the work becomes interesting. The
instruction file should be a signpost,

14
00:00:49.111 --> 00:00:51.677
not a second copy of
every project document.

15
00:00:52.060 --> 00:00:54.394
Detailed behavior belongs in requirements.

16
00:00:54.673 --> 00:00:57.389
Exact hardware facts belong
in the hardware reference.

17
00:00:57.900 --> 00:01:00.907
Tool and target pins belong
in the dependency record.

18
00:01:01.151 --> 00:01:03.728
The instruction file tells
the agent when to consult

19
00:01:03.763 --> 00:01:06.689
these sources and what evidence
to provide when it finishes.

20
00:01:07.014 --> 00:01:11.264
Create the exact filename AGENTS
dot md at the Sensor Monitor root.

21
00:01:11.589 --> 00:01:15.188
Confirm that the editor has not
added a hidden dot txt extension.

22
00:01:15.513 --> 00:01:18.857
Check the active folder too.
A correct file in a neighboring

23
00:01:18.938 --> 00:01:22.398
exercise copy does not guide
the task you opened elsewhere.

24
00:01:22.723 --> 00:01:25.683
The root is the folder
containing the project's README,

25
00:01:25.857 --> 00:01:28.899
scripts, firmware, host,
and docs directories.

26
00:01:29.340 --> 00:01:32.754
Codex has documented rules for
discovering project guidance,

27
00:01:32.905 --> 00:01:36.782
including global and project-level
files and more local overrides.

28
00:01:37.026 --> 00:01:40.532
The official reference is linked in
the written lesson. For this course,

29
00:01:40.683 --> 00:01:44.584
begin with one root file and inspect
the active interface when testing.

30
00:01:45.188 --> 00:01:49.123
We do not need nested instructions
merely to demonstrate that they exist.

31
00:01:49.448 --> 00:01:51.933
A small repository is
easier to reason about when

32
00:01:51.956 --> 00:01:54.348
its active guidance is
visible in one place.

33
00:01:54.951 --> 00:01:58.040
Open the conceptual diagram
that separates four roles.

34
00:01:58.550 --> 00:02:00.791
The task prompt names the current outcome.

35
00:02:01.302 --> 00:02:04.205
Project guidance states
recurring expectations.

36
00:02:04.715 --> 00:02:07.432
Reference documents contain
facts and rationale.

37
00:02:07.873 --> 00:02:10.625
Runtime permissions
govern actual operations.

38
00:02:10.950 --> 00:02:13.864
A Markdown sentence cannot
grant network access,

39
00:02:14.015 --> 00:02:17.370
install a compiler, or securely
fence off another folder.

40
00:02:17.753 --> 00:02:22.328
Guidance expresses intent; the environment
supplies and controls capabilities.

41
00:02:22.653 --> 00:02:24.557
Write the purpose in a short paragraph.

42
00:02:24.998 --> 00:02:28.667
The core project will exercise
shared C++ logic with synthetic

43
00:02:28.725 --> 00:02:32.115
input and cross-compile firmware
for a documented target.

44
00:02:32.498 --> 00:02:35.749
This early baseline currently
prints a fixed synthetic report.

45
00:02:36.260 --> 00:02:39.034
This tells the agent why host
replay exists and prevents

46
00:02:39.069 --> 00:02:42.343
it from treating a software result
as a physical measurement. It also

47
00:02:42.390 --> 00:02:46.592
helps keep an ordinary documentation task
from expanding into board upload or wiring

48
00:02:46.639 --> 00:02:49.530
work. Next, add the context links.

49
00:02:50.133 --> 00:02:52.107
At this stage, read the project brief.

50
00:02:52.351 --> 00:02:56.090
Before policy changes in later stages,
read the applicable requirements.

51
00:02:56.368 --> 00:02:59.457
Before board-specific claims,
read the hardware reference.

52
00:02:59.898 --> 00:03:04.472
Use decisions for rationale and evidence
for actual results once those populated

53
00:03:04.519 --> 00:03:09.197
documents exist. Do not add broken links
to files absent from a fresh checkpoint.

54
00:03:09.522 --> 00:03:11.426
If the task concerns target settings,

55
00:03:11.600 --> 00:03:15.002
inspect the dependency record rather
than remembering a copied string.

56
00:03:15.513 --> 00:03:19.507
A link is useful only when its destination
exists and its purpose is clear,

57
00:03:19.785 --> 00:03:23.849
so check both. Now turn a vague
preference into an observable rule.

58
00:03:24.291 --> 00:03:27.089
Be careful with embedded code
does not identify a check.

59
00:03:27.472 --> 00:03:31.256
A better instruction says to keep
edits tied to the requested outcome,

60
00:03:31.582 --> 00:03:34.310
inspect the diff, run the
relevant maintained command,

61
00:03:34.484 --> 00:03:38.084
and report its actual result. A
reviewer can inspect the completed

62
00:03:38.130 --> 00:03:40.417
task and decide whether
those actions occurred.

63
00:03:40.928 --> 00:03:44.933
The current Windows entry points
are the project dot cmd wrappers.

64
00:03:45.317 --> 00:03:48.022
Earlier checkpoints provide
replay and firmware build.

65
00:03:48.347 --> 00:03:51.203
Host assertion tests arrive
at checkpoint seven and later.

66
00:03:51.528 --> 00:03:55.151
The guidance must respect that
progression. Do not direct a learner

67
00:03:55.232 --> 00:03:58.645
or agent to a test file that the
current checkpoint does not contain.

68
00:03:59.156 --> 00:04:02.837
The written lesson preserves the exact
commands, while the wrappers keep

69
00:04:02.895 --> 00:04:06.517
environment handling in reviewable
project code. Different changes need

70
00:04:06.564 --> 00:04:10.697
different checks. A documentation
edit may need link and preview review.

71
00:04:11.080 --> 00:04:14.238
A replay-related change needs
the appropriate replay check.

72
00:04:14.621 --> 00:04:17.059
A firmware integration
change needs a cross-build.

73
00:04:17.663 --> 00:04:21.877
Later, shared policy changes also need
the available host assertion tests.

74
00:04:22.388 --> 00:04:26.684
Requiring every expensive check after
every punctuation edit creates noise,

75
00:04:26.927 --> 00:04:29.981
while silently omitting a relevant
check weakens the evidence.

76
00:04:30.677 --> 00:04:34.648
Add a completion expectation. The
agent should report changed behavior,

77
00:04:34.764 --> 00:04:37.922
relevant checks, actual
outcomes, and limitations.

78
00:04:38.305 --> 00:04:41.870
An announced plan to run a command
is not an execution result.

79
00:04:42.195 --> 00:04:44.830
A host replay is not a board observation.

80
00:04:45.213 --> 00:04:48.906
If a required check cannot run, the
report should name the exact missing

81
00:04:48.952 --> 00:04:52.528
dependency or limitation instead
of supplying a decorative pass.

82
00:04:52.969 --> 00:04:54.873
Include a bounded-work expectation.

83
00:04:55.256 --> 00:05:00.051
Keep unrelated useful work intact and
confine changes to the requested outcome.

84
00:05:00.434 --> 00:05:03.603
A sentence such as improve
everything whenever possible

85
00:05:03.650 --> 00:05:06.761
can turn a small fix into
an unreviewable redesign.

86
00:05:07.086 --> 00:05:09.710
If the agent notices an
unrelated opportunity,

87
00:05:09.861 --> 00:05:13.553
it can describe it separately rather
than silently broadening the patch.

88
00:05:13.994 --> 00:05:16.432
This protects the usefulness
of the final diff.

89
00:05:16.815 --> 00:05:20.136
Read your file from beginning
to end. For each instruction,

90
00:05:20.379 --> 00:05:24.094
name the recurring error it prevents
and the behavior that would satisfy it.

91
00:05:24.478 --> 00:05:28.158
Remove duplicated detailed facts
and resolve contradictions.

92
00:05:28.541 --> 00:05:32.570
If one line says use the maintained
wrapper and another says skip checks

93
00:05:32.605 --> 00:05:37.202
to save time, the next task has inherited
a conflict rather than useful guidance.

94
00:05:37.713 --> 00:05:40.441
Your exercise is to
create or revise the root

95
00:05:40.488 --> 00:05:43.123
instruction file and
submit a static review.

96
00:05:43.507 --> 00:05:47.907
Confirm purpose, links, available
commands, scope, and completion evidence.

97
00:05:48.348 --> 00:05:52.052
Compare it with the supplied project
example without overwriting unrelated

98
00:05:52.098 --> 00:05:56.521
work. This lesson can establish that
the file is clear and correctly placed.

99
00:05:56.847 --> 00:06:00.678
It cannot yet establish that a fresh
agent session followed it. That behavior

100
00:06:00.725 --> 00:06:01.967
test is the next lesson.

101
00:06:02.245 --> 00:06:06.472
We will ask for a bounded task without
repeating every repository instruction,

102
00:06:06.715 --> 00:06:10.523
observe the actual actions, and
inspect the evidence independently.

103
00:06:10.907 --> 00:06:14.343
The purpose of persistent guidance
is to reduce repeated explanation

104
00:06:14.389 --> 00:06:18.627
while keeping engineering decisions
reviewable. A concise file with a testable

105
00:06:18.661 --> 00:06:22.667
role is a stronger starting point than
a long collection of broad promises.