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.