FlyPython
English
Sign inStart a challenge
English中文

Hands-on with GitHub Copilot · Challenge 05

Lesson 5: Take the workflow to your own project

Checkpoint l0510 ptsself-reported — code from verify.pyGitHub Copilot in VS Code

The tool generalizes: task contract, instructions files, bounded agent work, diff review — run the same loop with Copilot on a repository you actually own.

Six agent-tool courses share this challenge. GitHub Copilot in VS Code-specific steps are still being written — until they land and pass review, this page defers its canonical to the primary course's copy.

Doing this with your agent? One sentence starts the whole course:

Read https://flypython.com/skills/flypython/SKILL.md and start the FlyPython course `hands-on-with-github-copilot`.

Lesson 5: Take the workflow to your own project

Objective

You apply the whole loop — contract, instructions files, bounded agent work, diff review, written verification — to a script or repository you actually own, and record what happened.

Why this lesson exists

A course folder is a safe sandbox; your own codebase is not. The point of the last four lessons was never the report tool — it was a repeatable way to drive an agent that keeps you in charge of what ships. This checkpoint exists to prove the transfer happened. It is self-attested: only you know whether the loop actually ran.

The lesson

Pick a real script you own — one with a bug you have been putting off, or a behavior you want but have not written. Then run the same five moves:

  1. Contract. Write the task contract first: inputs, outputs, error cases, and “done means <command> exits 0”. One short paragraph, every sentence testable.
  2. Rules that persist. Open the repository in VS Code and put the project-wide rules in .github/copilot-instructions.md (or the repository’s existing AGENTS.md) — the verification command, the dependency policy. Put folder-specific rules in an applyTo instructions file. Confirm in a new session’s References that they load. If the repository is shared, these files are reviewed like code: your teammates’ Copilot sessions will read them too.
  3. Bounded work. One chat session, Agent role, Manual permissions, one contract line per turn. Read every changed file before the next prompt; read every command before approving it; commit each green step.
  4. Verify. Run the verification command yourself, then do the review the suite cannot do — walk one real input end-to-end and check the output by hand.
  5. Record. Write the three lines: verified / not verified / known limits.

If the loop fought you — the task was too small to need a contract, or too vague to test — that is a finding too. Write down where the shape did not fit; that judgment is the actual skill.

Exercise

If your project has more than one boundary worth pinning, draft the next contract line now — you will want it when you open the next session.

Checkpoint

This checkpoint is self-attested. When you can answer the questions below, claim it with python verify.py --attest l05:

  1. What was your contract’s “done means” command?
  2. Which diff or command did you push back on?
  3. What is on your “not verified” list that a stranger would assume was covered?

Expected evidence

Your contract paragraph, the instructions file you wrote, and the three-line verification record. These are yours — they are the proof the workflow transferred.

Hints

Stuck? Open one at a time.

Hint 1 — What this checkpoint tests

Self-attested: you confirm you applied the loop to your own project. The evidence is your contract, your instructions file, your reviewed commits, and your verification record — not a code we can check.

Hint 2 — Carry the shape, not the code

What transfers is the loop: contract first, one bounded change at a time, every turn's diff read before the next prompt, verification written down.

Hint 3 — When you are done

Your own project has a contract, one bounded change you can explain, and a verified/not-verified/known-limits record — or a documented reason the loop did not fit.

Submit

Done? Record it.

Use the 8-character code printed by python verify.py. For a self-reported checkpoint, answer the lesson questions first, then run python verify.py --attest l05.

Youbrowser

Submit the claim code

Your agentauto-submit

Let the agent solve and submit

Hand it this checkpoint (copy button on hover) — it solves, verifies, and submits on its own:

Work on the FlyPython challenge "Hands-on with GitHub Copilot" (course id course-github-copilot), checkpoint l05.
Machine-readable brief: https://flypython.com/api/challenges/hands-on-with-github-copilot
Open the course folder and read TASK.md first — it is the contract.
Rules: smallest change, no new dependencies, never edit tests/ or solution/.
Check starter/ with python verify.py; ask me the lesson questions before using --attest ID for any self-reported checkpoint.
Target: solve only checkpoint l05, and submit it as soon as it passes.

With a token from your agent page (env FLYPYTHON_TOKEN), it records the result directly:

curl -X POST https://flypython.com/api/claims \
  -H "Authorization: Bearer $FLYPYTHON_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"claims":[{"course":"hands-on-with-github-copilot","checkpoint":"l05","code":"<8-char code>"}]}'

Or install the full FlyPython agent skill once and skip the paste.

Files

The starter and verifier

Solving runs on your machine — your agent fetches the course files itself via /api/challenges/hands-on-with-github-copilot/files; you download nothing by hand. Prefer reading the source? Browse the folder on GitHub ↗