Feedback Before The Commit.
The video looks at a skill that helps a workshop attendee submit a solution as a pull request. It asks three feedback questions before touching git, so the PR doubles as the form facilitators read to shape the next workshop.
Asking whether Claude just commits a workshop attendee's solution and opens a pull request suggests an easy answer: it is a git task, full stop. The video says that is not quite right. The submit-solution skill is built so that the first step has nothing to do with git, and that ordering is what makes it a feedback task dressed as a git task.
What the skill is
A skill is a folder that Claude reads before it acts. This one is for a workshop attendee who is wrapping up the stock pilot exercise. Inside are five steps that always run in the same order: ask about the attendee's experience, show the diff, commit and push, open the pull request, and confirm. The SKILL.md file fixes that order, so Claude does not skip ahead to committing.
Three questions come first
Step one happens before any git command. Claude asks three questions:
- Which subagent approach did you use for cycle three: a callable agent, a spawned subagent, inline, or something else?
- What was the hardest part of the workshop?
- What is one thing you would change?
Only after those answers does Claude look at the diff.
What an empty diff means
The video points out that an empty diff does not mean the attendee is finished. It usually means they edited a different file, so Claude asks rather than assumes. A full diff does not mean the pull request opens yet either, because the feedback still has to be collected first.
One document, two sections
The PR body that Claude writes carries two things in one document. The first is the technical summary: the subagent approach, the eval score, the tools dropped and the skills enabled. The second is the workshop feedback, placed right below it.
That is what makes the task a feedback task. The same pull request that facilitators read for the code is the form they read for what to fix in the next workshop. If the questions are skipped, the commit still happens, but the second half of the document stays blank every time.
Key takeaways
- Submitting a workshop solution is not only a git task.
- The skill fixes five steps in order: ask, show the diff, commit and push, open the PR, confirm.
- Claude asks three questions before it runs any git command.
- An empty diff usually points to an edit in a different file, so Claude asks.
- The PR body holds a code summary and the attendee's feedback together.
- Facilitators use the PR as the form that shapes the next workshop.
Try it yourself
After you finish a coding exercise, paste this into Claude: you want to submit your solution as a pull request, and before it touches git it should ask what approach you used, what was hardest and what you would change. Then ask it to show the diff and write a PR description with two sections, your code summary and your feedback. Notice which questions come before the commit and which come after.
Chapters
Full transcript(auto-generated, with timestamps)
The naive framing: "it's a git task, right?"
[0:00]Someone assumed submitting a workshop solution is just a Git task, commit, push, open a PR. It isn't quite, so is submitting a solution actually a feedback task? A skill is a folder
Anatomy: five steps, fixed order
[0:10]Claude reads before it acts. This one is submit solution for a workshop attendee wrapping up the stock pilot exercise. Inside are five steps always in this order. Ask about their experience, show the diff, commit and push, open the PR, confirm. The skill MD fixes that order. Claude doesn't skip ahead to committing.
Mechanism: three questions, then git
[0:28]Step one comes before any Git command and three questions. Which sub-agent approach did they use for cycle three? Callable agent, spawn sub-agent, inline, or something else? What was the hardest part of the workshop? One thing they'd change. Only after that does Claude check the diff. An empty diff doesn't mean they're finished. It usually means they edited a different file, so Claude asks rather than assumes. A full diff doesn't mean the PR opens yet either. The feedback still has to be collected first. The PR body Claude writes carries
The PR body has two sections: code summary and feedback
[0:55]Two things in one document. The technical summary, sub-agent approach, eval score, tools dropped, skills enabled, and the workshop feedback right below it. That's what makes this a feedback task wearing a Git task's clothes. The same PR facilitators read for the code is the form they read for what to fix in the next workshop. Skip the questions and the commit still happens, but the second half of that document stays blank every time.
Carry-out
[1:17]Submitting a workshop solution isn't just a Git task. The skill has Claude ask what was hardest before it commits anything because the same PR that shows the code is the form that shapes the next workshop. Your turn. Paste this
Your turn
[1:30]Into Claude. I just finished a coding exercise and want to submit my solution as a pull request. Before you touch Git, ask me what approach I used, what was hardest, and what I'd change. Then show me the diff and write a PR description with two sections, my code summary and my feedback. Notice which questions come before the commit and which come after. Feedback before the commits. Lay 'em in
Outro
[1:50]For bear.
