Theme

Font

Size

Text width

Line spacing

Controls accent

0 of 0 0%
MODULE 4.2

Evolve and deliver your first skill

Apply the bicycle method and assemble a verifiable work package.

At the end: Deliver a skill, test cases, QA, and an improvement history.

6 topics
75 min estimation with hands-on practice
6 commented exercises
1 final check
1

Increase autonomy based on evidence

Track Review everything Show Monitor boundaries
Supervision can decrease; the criteria and the ability to stop remain.

What it is

The bicycle method represents supervision that changes as you learn. In the first runs, monitor everything. After you observe stability, review samples and maintain controls over actions with higher impact.

Why learn

Trusting more doesn’t mean removing all protection. A skill that produces a draft can operate with little supervision; publishing, sending, or editing records involves different consequences. The autonomy level depends on risk and the evidence.

Key concepts

Step-by-step follow-upreview.
Full reviewevaluate all output.
Samplinglook at a representative portion.
Permanent boundariescontinue even after maturity.
COMMENTED EXAMPLE · 4.2.1
Phase 1: track three different cases.
Phase 2: review each final delivery.
Phase 3: sample low-impact outputs.
Always: review blockers and behavior changes.

✓ Do it like this

Increase supervision when input or the environment changes.

✗ Avoid this mistake

Treat some good runs as unlimited authorization.

Practice before revealing

A stable skill starts using a new publishing tool. What changes?

View commented response

Capacity and risk changed. Reassess permissions, test cases, and supervision. The draft’s stability doesn’t prove publication safety.

2

Give feedback that identifies the smallest correction

Observed Expected Minimal correction Test
Good feedback reduces uncertainty and preserves work that’s already been validated.

What it is

Effective feedback names the observed result, the expected result, the impact, and the proposed change. Also include what worked and should be preserved. This reduces the risk that rewriting unnecessarily breaks good parts.

Why learn

“It’s bad” pushes the agent to guess. “The total is correct, but there’s a missing period in the header” pinpoints the defect. The correction is to add and test the period, not to replace the entire calculation pipeline.

Key concepts

Observedwhat happened.
Expectedcontract was violated.
Impactwhy it matters.
Protectionrule and minimum test.
COMMENTED EXAMPLE · 4.2.2
Worked: totals by channel are correct.
Failed: the period doesn’t appear before the summary.
Impact: the reader doesn’t know which week it refers to.
Adjustment: require the period in the header and verify both dates.

From concept to action

  1. Observed: identify the initial condition.
  2. Expected: apply the described decision.
  3. Minimal correction: check the effect in the example.
  4. Test: record the output evidence.

✓ Do it like this

Cite the file, section, or a concrete example.

✗ Avoid this mistake

Ask “make everything better again” when there’s a localized defect.

Practice before revealing

Turn “the text doesn’t sound like me” into usable feedback.

View commented response

“You used long sentences and three superlatives that don’t appear in my examples. Preserve the facts, shorten those sentences, and use the two approved texts as references for tone.”

3

Turn the failure into a regression test

Real failure Minimal case Correction Complete suite
An improvement is only demonstrated when the problem is gone and the rest of the relevant items keep passing.

What it is

After fixing, save a case that would have detected the failure before. This test goes into the next evaluation. Also run the previous cases to ensure the new protection didn’t make valid inputs impossible.

Why learn

Fixing an execution is local; the test preserves the learning. For example, if a privacy rule started hiding all numbers, the regression should reveal that it also removed essential data that was previously public.

Key concepts

Minimal casereproduces the problem.
New test rejects the old failure.
Previous suiteprotects what was working.
Final result includes both checks.
COMMENTED EXAMPLE · 4.2.3
Failure: report without a period.
Case: CSV with different dates.
Test: header includes the earliest and latest date.
Regression: total and channels remain correct.

✓ Do it like this

See the test fail before trusting it protects the scenario.

✗ Avoid this mistake

Accumulate rules that are never exercised.

Practice before revealing

Empty input now gives a clear error, but the valid case stopped working. Did the fix finish?

View commented response

No. You fixed one case and introduced a regression. Adjust the condition and rerun both tests.

4

Version the recipe and preserve the reversal

Current version Small change Tests New version or reversal
Versioning turns attempts into a recoverable story.

What it is

Save skill changes in version control or in identified copies, with a short history of the reason. Record the version used in each experiment to distinguish improvement from instruction changes due to environment changes.

Why learn

A useful history lets you go back to the previous version when a fix worsens the result. It’s not enough to save “final,” “final2,” and “now-works.” Identify what changed and the evidence that justified the decision.

Key concepts

Version identifies a recognizable state.
Changelog reason for the change.
Diff concrete change.
Rollbackreturn to a known state.
COMMENTED EXAMPLE · 4.2.4
Project version: 1.0.0
Correction patch: 1.0.1
New feature: 1.1.1
Convention for this project: minor preserves the patch.
Always record reason and tests in the history.

✓ Do it like this

Use the versioning convention documented by the project.

✗ Avoid this mistake

Confusing a local convention with the universal semver rule.

Practice before revealing

What information should accompany “I adjusted the description”?

View commented response

The trigger that failed, the changed text, and the positive and negative requests that were reassessed. That way someone can understand why the change exists.

5

Conclude the project: weekly report

Install the example Generate report Test failures Deliver evidence
The project ends in verifiable files, not in a promise of automation.

What it is

Assemble the skill, the synthetic CSV, the generator, negative cases, and execution evidence. The kit provides a functional starting point; your job is to run it, explain the result, and adapt a small rule with a corresponding test.

Why learn

The final project proves the full cycle: contract, implementation, verification, and improvement. Reading the SKILL.md is only one part. You need to open the artifacts, check the account, and observe how the skill reacts to an invalid input.

Key concepts

Delivery 1SKILL.md delimited.
Delivery 2 report and calculated data.
Delivery 3 test evidence.
Delivery 4 justified change and regression.
COMMENTED EXAMPLE · 4.2.5
python3 scripts/gerar_relatorio.py dados/vendas.csv \
  --outdir saidas/rodada-01
python3 scripts/testar_relatorio.py
# Then ask Codex to run it via the skill
# and compare it with the script’s result.

From concept to action

  1. Install the example: identify the initial condition.
  2. Generate report: apply the described decision.
  3. Test failures: check the effect in the example.
  4. Deliver evidence: record the output evidence.

✓ Do it like this

Compare direct execution with skill-guided execution.

✗ Avoid this mistake

Claim the Codex trigger was tested just because the Python passed.

Practice before revealing

Add a per-line value limit, document it, and create a case that exceeds it.

View commented response

An acceptable solution defines the limit, rejects the exceeding value with a clear message, and keeps the R$ 500 case approved. This limit is a choice of the exercise, not a universal commercial rule.

6

Review your skills portfolio

Inventory Test boundaries Fix the necessary Reevaluate
Maintenance closes the six steps and sets up the next improvement cycle.

What it is

A healthy library contains tasks with clear boundaries, examples, and maintainable upkeep. Review similar skills, competing triggers, and obsolete rules. Consolidate duplicates when there’s evidence they represent the same process.

Why learn

The final skill isn’t writing more instructions: it’s maintaining a system where each procedure can be found, executed, and evaluated. Redo the review when the work changes, not only when the text seems outdated.

Key concepts

Inventory what exists and what it’s for.
Conflict two skills compete for the same task.
Maintenance owner and reason for update.
Evidence cases and recent results.
COMMENTED EXAMPLE · 4.2.6
Final review
[ ] Approved output and clear contract
[ ] A piece of work and tested triggers
[ ] Freedom calibrated per step
[ ] QA with evidence
[ ] Configuration assessed
[ ] Feedback became a test

✓ Do it like this

Prioritize the skill that causes the most observable rework.

✗ Avoid this mistake

Increase instructions for each incident without removing contradictions.

Practice before revealing

Explain your skill to another person in 60 seconds: input, output, boundary, and evidence.

View commented response

If the person can locate the folder, run the example, recognize a failure, and review the QA, the package is teachable. The next step is to test it with new, properly prepared real inputs.

CHECK WITHOUT BLOCKING

Check your understanding

What change closes the learning cycle?

What you take from this module

Deliver a skill, test cases, QA, and improvement history.

  • Increase autonomy according to the evidence.
  • Give feedback that identifies the smallest correction.
  • Turn the failure into a regression test.
  • Version the recipe and preserve the reversal.
  • Complete the project: weekly report.
  • Review your skill portfolio.

Next action: save the exercise in your learning lab and record what still needs review.

Module reference: the provided transcript and course sources and technical notes.