F. Project instructions and focused skills

Use a prompt for a one-time task, a project instruction file for stable local guidance, a deterministic script for a repeatable computation, and a skill for a procedure with a clear trigger and inputs. These can support one another. A skill is not improved by containing every possible project rule, and a README is not automatically loaded into every agent session merely because it exists.

Project instructions

For the selected Codex path, AGENTS.md supplies project guidance according to the host's discovery and scope rules. Confirm the current official behavior and test it in a fresh session. Guidance is not access control and does not itself create a subagent. Runtime permissions remain a separate mechanism. Codex project instructions

A useful file names the project purpose, stage-appropriate commands, source-of-truth documents, change boundaries, and expected completion evidence. At CP03, the applicable baseline is replay/build, not the later test suite. At CP09, tests and parser fixtures are present. Linking to a requirement or setup record keeps the instruction short while preserving detail.

The complete reference AGENTS.md belongs to its current source stage. Copying it into a much earlier checkpoint without adapting the commands can create false instructions. The learner instruction template explicitly requires that adaptation.

Skill structure and current host behavior

A skill directory contains SKILL.md, with metadata naming the skill and describing when it applies, followed by the procedure. Focused references or deterministic helpers can live beside it. The shared Agent Skills specification defines the format; each host determines discovery, invocation, and execution behavior. A valid directory alone does not prove activation. Agent Skills specification

The project uses .agents/skills/<skill-name>/SKILL.md for its selected repository-local path. Check the current host documentation and observe actual behavior in a fresh task. A description should help the runtime select the relevant procedure while excluding unrelated work. Explicit invocation is useful when testing the procedure itself; a separate test asks whether selection happens appropriately.

Datasheet-to-constraints procedure

The complete editable package is in learner resources, including its supporting extraction rules. Its job is to turn supplied primary documents for an exact component or board into a traceable constraints table. It requires identity and source applicability, separates chip limits from board connections, and preserves missing facts.

Test it with a positive case supplying an exact source excerpt and requesting interface constraints. Check whether each value has a unit, source location, and consequence. Then give an unrelated README punctuation task; the procedure should not inappropriately drive that task. Finally omit a necessary board mapping and check that the result reports the gap instead of inventing a pin.

These are three different tests: useful output for relevant input, appropriate trigger boundaries, and honest incomplete-input behavior. A single successful invocation does not establish all three. Save actual request, activation evidence where available, output, and review.

Firmware-review procedure

The complete editable firmware-review skill reads a bounded diff, nearby callers, and requirements. It checks actionable correctness issues such as timing arithmetic, invalid/stale/recovery paths, command bounds, conversions, and whether tests distinguish the required behavior. It reports findings with a trigger, consequence, file location, and evidence.

The positive test uses a meaningful seeded defect, such as missing clear equality. The negative test uses an unrelated documentation change. The incomplete-input test omits the governing requirement or executable environment and checks that the review states the limitation. A review that invents a problem to fill a finding quota fails the procedure just as a review that ignores a real boundary can fail it.

If no actionable issue is supported, a concise statement of that result and material verification gaps is appropriate. Do not let the skill silently rewrite the diff when the task was review. Separate observed behavior from predicted consequences and distinguish host evidence from physical checks.

Maintain the package

When a tool update changes discovery or command behavior, rerun the relevant behavior cases. Keep references short and current. If two instruction files conflict, identify their scope and the actual rule selected before changing several files at once. If a helper can compute something reliably, use it for that computation and let the skill explain the decision around it.

The success criterion is observed useful behavior: the right procedure, supported output, appropriate restraint, and a reproducible record. A plausible filename or attractive frontmatter is only the beginning.