M05-L03 — Package a repeatable procedure
Package a focused procedure for deriving hardware constraints from primary material. Start with the source-checking practice from Module 4 and a preserved CP03 folder. The output is a valid skill file, a focused reference, and a static review.
Choose a skill only when the task needs a reusable sequence and judgment. A one-off request can remain a prompt. General project expectations belong in AGENTS.md. Deterministic transformations may belong in scripts. The constraints procedure needs exact-source identification, units and conditions, uncertainty handling, and reviewable output.
Create .agents/skills/datasheet-to-constraints/SKILL.md. YAML frontmatter contains the matching lowercase name and a concise description. The description should identify the task: deriving interface or operating constraints for an exact board or component from supplied primary documents. Exclude unrelated prose and general coding tasks.
Below the metadata, state inputs, steps, and output. Require exact part/board identity, publisher/title/revision when available, and relevant source sections. Separate chip limits from board connections. Preserve units, operating conditions, and the distinction between typical values and limits. Missing data should remain explicit.
The output table needs claim, value/unit, source section/link, confidence or missing data, and design consequence. A row whose source does not support its value is a failure even if the table looks polished. Require the agent to check each row and list only unresolved questions that affect the requested decision.
Add a focused references/extraction-rules.md explaining missing-information examples and source identity. Link it relatively from the skill root. Do not copy an entire manufacturer manual or add scripts merely to make the directory look substantial. The first version can be instruction-only.
Read the metadata and procedure independently. Valid frontmatter checks packaging; correct discovery and output require behavior tests in the next lesson. The shared Agent Skills format is distinct from Codex's local .agents/skills discovery and invocation behavior. Use the official references and the installed host's actual state when testing.
D10 shows the relationships between metadata, body, reference, and optional scripts. Explain why a missing pin mapping should produce an explicit gap and a next source request rather than a guessed number.
Resources and completion
Use the Sensor Monitor CP03 download and its README.md; project paths in this lesson are relative to that root. Read Chapter 11 for the full lab and explanatory review answers. Figure IDs: SS11-01, SS11-02, D10. Primary references: OpenAI AGENTS.md and OpenAI build skills. Complete the exercise, preserve actual evidence, and use the separate instructor answer key for self-check after attempting the task. Narration scripts are production sources; final transcripts must match the actual narrated edit.
Recording transcript
A repeated procedure becomes easier to reuse when its inputs, steps, and output are explicit. In this lesson, we will package the source-checking workflow as a skill. The result is a focused directory containing metadata, instructions, and a short supporting reference. Start with the source discipline from Module Four and a preserved checkpoint-three project. We will test runtime behavior in the next lesson.
First decide whether a skill is the right form of reuse. A one-off question can stay a prompt. General project expectations belong in AGENTS dot md. A deterministic transformation may belong in a script. A skill is useful when a recurring task needs judgment and a recognizable sequence, such as identifying the exact hardware source, extracting relevant constraints, and explaining missing information.
Our task is datasheet-to-constraints. It should derive interface or operating constraints for an identified board or component using primary technical material. It should not become a universal embedded-engineering assistant that activates for every code edit and documentation change. A narrow purpose makes both the input contract and the evaluation much clearer.
Create the dot agents folder at the project root, then skills, then datasheet-to-constraints. CP03 does not yet supply this skill. Create the required file named SKILL dot md. The shared Agent Skills specification describes the package format. Codex has its own documented discovery and invocation behavior. Keep those two ideas separate: a package can be well formed while the current host has not discovered or selected it.
At the top of the file, YAML frontmatter sits between delimiter lines. The required name should match the directory, using the specification's lowercase naming form. The description should say what task this skill handles and when it is relevant. A phrase such as helps with hardware is too broad. It does not tell the host whether a README typo or a firmware timing review belongs here.
Write the description around the actual task: derive constraints for an exact board or component from supplied primary documents. Include a short boundary for unrelated prose and general coding work. Put the useful task words early. The description is a selection aid, not a place for a long sales pitch or every detail of the procedure.
Below the metadata, define the inputs. We need the exact part or board identity, the source material, and the question the user wants answered. Preserve the document title, publisher, revision when available, and relevant sections. If the revision is absent, the procedure should say that it is not established. A required field must not pressure the agent into inventing a value just to fill a table.
Now write the steps as actions an engineer could perform manually. Confirm the identity. Separate chip-level facts from board-level connections. Extract only the constraints relevant to the request. Retain units and conditions. Attach a source location to every supported claim. Label any inference and explain its basis. Mark unavailable or conflicting information explicitly, then explain what it means for the project.
The output contract makes the result reviewable. Use columns for claim, value and unit, source section or link, confidence or missing information, and design consequence. A reviewer should be able to pick a row, open its source, and decide whether the source supports the value. A beautifully formatted row with an unsupported pin number is a failure, even when the rest of the table is correct.
Be careful with confidence. A numerical percentage can suggest precision without evidence. Phrases such as explicitly documented, inferred from named facts, or not established by the supplied excerpt are more useful here. They explain the basis of the statement. An absent pin mapping should remain absent, accompanied by the exact source or variant needed to resolve it.
Add a focused supporting reference under references slash extraction-rules dot md. Checkpoint four supplies an authored example for comparison. Your new reference should explain identity, units, conditions, and missing-data handling. Link to it relatively from the skill directory. Check that the file exists and that the link works. A reference that cannot be found is a defect in the package, not useful extra context.
Keep the reference small and relevant. Do not copy an entire manufacturer manual into it. Link to primary material and preserve only content that the project has rights to distribute. Do not add scripts merely to make the skill look substantial. A deterministic helper can be valuable later if a repeated check earns its maintenance cost, but the first version can be instruction-only.
Include one positive example of uncertainty handling. If a source establishes the board family but not its exact pin mapping, the output should mark the mapping unresolved and identify the missing board reference. Also explain the failure case: inserting a familiar ESP32 pin from memory. Even a lucky guess fails the evidence rule because its claimed support does not exist.
Review the finished file in two passes. The first checks packaging: filename, name match, YAML delimiters, description, and relative reference. The second checks the procedure: clear inputs, bounded steps, useful output, and honest missing-data behavior. A format validator can assist the first pass. It cannot decide whether a manufacturer section supports a claim or whether the host selected the skill at the right time.
Your exercise is to create the skill or improve one demonstrated weakness in a disposable copy of the supplied version. Submit the file, focused reference, and two anticipated failure cases. Preserve earlier work. Explain why each proposed step belongs to this specific procedure and which output condition would make the result unacceptable. If you cannot describe failure, narrow the task before adding more instructions.
In the next lesson, we will run relevant, unrelated, and incomplete-input requests. That evaluation is what turns a plausible package into a tested reusable procedure. For now, the useful outcome is a small skill whose purpose and evidence contract can be understood without the old conversation. The structure supports reuse while leaving the engineering judgment visible for review.
Download transcript
