M05-L05 — Challenge: build the constraints skill
Deliver a reusable constraints procedure with evidence that its boundaries work. This module challenge combines project guidance, skill packaging, exact-source reading, and fresh-session evaluation. Use CP04 in a new exercise folder; preserve your earlier working version.
Review the skill's purpose and input contract before changing it. It should derive constraints for an identified board or component from primary material. It should neither perform unrelated firmware edits nor invent information that the source lacks. Keep global project expectations in AGENTS.md and detailed hardware facts in the hardware reference.
Improve one demonstrated weakness from M05-L04. A weak trigger needs a more precise description. An unsupported table row needs a clearer evidence-review step and a missing-data example. A broken reference needs a corrected path. Do not redesign everything at once, because that makes it hard to explain why behavior changed.
Run the relevant request using product 5477 and BME280 sources, first explicitly if discovery needs diagnosis, then implicitly. Follow it with unrelated and incomplete-input cases in fresh tasks. Record the actual host, skill version, prompt, source scope, selection evidence, output, and verdict. The negative case must not mention the skill.
Inspect the final constraints table independently. Every factual value needs a source location. Units and conditions must survive extraction. Board-level and chip-level claims need clear identities. Inferences should be labeled, and unknowns should explain what evidence is missing and what decision remains affected.
Prepare a short handoff: where the skill lives, how to invoke it in the tested host, which cases passed or remain open, and what should be rerun after a relevant tool or source change. Do not describe a format lint as a behavior test. Do not describe document extraction as physical validation.
The challenge passes with a usable package and an evidence-backed evaluation, not merely a large folder. The five-question module quiz checks the concepts behind that work. Aim for four correct answers, retry after reading explanations, and keep practical artifacts separate from quiz progress. Chapter 16 later applies this pattern to firmware review.
Resources and completion
Use the Sensor Monitor CP04 download and its README.md; project paths in this lesson are relative to that root. Read Chapter 10–11 for the full lab and explanatory review answers. Figure IDs: SS11-02, SS11-03, SS11-05, 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.
For the incomplete case, reuse M05-L04’s refined different-board scenario. Keep that course scenario distinct from the shorter request in candidate05; changing the prompt and the skill together would confound the comparison.
Recording transcript
This challenge brings together project guidance, source discipline, skill packaging, and behavior testing. You will deliver a reusable constraints procedure and explain why its boundaries are useful. Start with a new checkpoint-four exercise copy and preserve your previous version. The aim is a small supported improvement, not a complete redesign of everything you wrote in the module.
Review the skill's purpose before editing. It derives constraints for an identified board or component from primary technical material. It needs exact identity, relevant source sections, units and conditions, and explicit missing information. It should not turn an extraction request into unrelated firmware edits, purchases, or physical operations. Those boundaries keep the output aligned with the actual task.
Check the division of responsibility. AGENTS dot md holds recurring project expectations. The hardware reference holds current sourced facts. The skill holds the extraction procedure. The dependency record preserves target and tool pins. If the same detailed fact has been copied into all four places, consider whether a link would make the context easier to maintain. Avoid creating a new contradiction while trying to improve reuse.
Choose one weakness demonstrated by your previous tests. Perhaps the relevant request did not select the skill. Perhaps a spelling correction triggered a constraints table. Perhaps incomplete source material produced an invented pin. Perhaps the supporting reference path was broken. Each case suggests a different repair. Start with the observed failure rather than adding a long list of generic instructions.
For a broad trigger, refine the description around the actual input and task. Deriving interface or operating constraints from supplied primary documents is specific. Helping with anything embedded is not. After the edit, the positive case must still be able to select the skill, and the unrelated case should remain ordinary prose work. A description that prevents all activation is not a useful solution.
For an unsupported row, improve the procedure's source review. Require each factual value to be checked against its cited section. Add an example where the exact pin mapping is absent and must remain unresolved. Explain that the next step is to obtain the applicable board reference, not to supply a familiar value from another variant. Keep uncertainty actionable rather than merely apologetic.
For a broken reference, correct the relative path and open the file from the skill's location. The focused reference should add something that helps the procedure, such as source identity, units, conditions, and missing-data examples. A large unrelated document does not make the skill more capable. It can make the relevant steps harder to find and maintain.
Once the change is clear, run the relevant case again. Use the product five four seven seven and BME280 source path in the hardware reference. Explicit invocation can diagnose discovery, but the implicit case must also be evaluated separately. Preserve the exact prompt, source scope, skill version, host version, and available selection evidence. Do not replace the actual output with the table you expected.
Review the constraints table row by row. Identify the object each claim describes: chip, breakout, or host board. Check the value, unit, and source section. Look for conditions that were lost during extraction. Then inspect the consequence. The consequence should explain what the fact means for this project, and any inference should be labeled so a reviewer can examine the reasoning.
Run the unrelated case in a fresh task without mentioning the skill. The spelling correction should stay a spelling correction. Then run the incomplete-input case for a different board from the documented example, with no exact variant or schematic supplied. Use the exact course prompt and its description-only source boundary. Missing identity and source evidence should remain explicit. These cases test useful restraint as well as capability. A skill that produces an impressive answer by guessing has not met the evidence contract.
Compare the new records with the previous ones. Explain what changed and which observation supports the improvement. Keep the failed attempt when it motivated the repair. If an account or tool limit prevents the rerun, record the open gate and preserve the complete package. A planned evaluation is useful preparation, but it must not be promoted to an observed pass.
Prepare a concise handoff. Name the skill's location, how it was invoked in the tested host, which cases passed, which remain open, and what should be rerun after a relevant change. Link to the actual case records. The next session should be able to inspect the current procedure and continue from the unresolved question without recovering your old conversation.
Name one remaining physical unknown. A sourced constraints table can establish what a manufacturer document says about the selected example. It does not establish the revision of a board you have not inspected, the position of a jumper, successful wiring, or actual measurement accuracy. Physical hardware remains optional for the core course, and its evidence belongs in a separate clearly labeled activity.
Your submission contains the final skill, focused reference, any bounded instruction correction, the four actual case records, and the handoff. Use the rubric in the answer key after your own attempt. Strong evidence matters more than reproducing exact wording. A package with valid metadata but no behavior record is incomplete for this challenge, while an honest blocked record tells us precisely what remains to be done.
Take a moment to consider transfer. The same structure can support a bounded firmware review, a test-evidence summary, or a log-triage procedure. Start with the inputs and output, then define what would make a result wrong. Choose relevant, unrelated, and incomplete cases. If you cannot state failure conditions, the procedure is probably too broad to package confidently.
Finish with the module quiz and read the explanations for missed questions. The recommended target is four out of five with unlimited retry. Quiz progress remains separate from the practical evidence. You now have a repeatable way to turn an engineering procedure into a maintained skill while keeping sources, uncertainty, and observed behavior visible. Chapter Sixteen will use that pattern for the second required skill, firmware review.
Download transcript
