3 build prompts · 5 checks · run them in order and your second brain gains its first skills and its first command
Every prompt from the closing demo lives here, consolidated and cleaned up. Each one says what it is for and what your repo should look like when it lands. Open a terminal in your second brain repo, type claude, and paste them in order. Rephrasing in your own words works just as well; both roads end at the same repo. If a result does not match, ask Claude what it did differently, fix that step, and keep going.
Your first skill: a procedure Claude reaches for on its own whenever your request matches its description. The stakeholders file and the meeting note go in first, because a skill with nothing to read can only prove that it triggers, never that it works.
create a stakeholders file with two example stakeholders, each with a name, a role, and one open item. then add a meeting note for thursday's steering committee in a meetings folder
now build a skill called meeting-brief in the skills folder. the job: whenever i ask you to prep me or get me ready for a meeting, find that meeting's file in the meetings folder, read the stakeholders file so you know who is attending and what their roles are, and fill out a one page brief covering the purpose, the attendees, open questions, and the decisions we need. save the finished brief in the deliverables folder under briefs, with the date and meeting name in the filename
What you should see: A stakeholders file, a meetings folder holding thursday's note, and .claude/skills/meeting-brief/SKILL.md. Open the skill file: a name and description in the frontmatter at the top, the procedure in the body below. The description is the part Claude sees every session; the body loads only on use.
A command runs only when you type its name, so it stays fully in your control. That is the dividing line to feel while you build this: skills fire on relevance, commands fire on demand.
now something different: a slash command, not a skill. call it weekly-log. when i type /weekly-log with a date, summarize everything that changed in this repo over the past 7 days using git history and file dates, and write the summary to a logs folder with the date in the filename, kept under one page
What you should see: .claude/commands/weekly-log.md: a short instruction file, with $ARGUMENTS marking where your typed date lands.
doc-helper exists to fail. Claude picks skills by matching your request against their one line descriptions, so a vague description never gets picked. You are planting the proof now; the checks below harvest it.
create one more skill called doc-helper and give it a deliberately lazy description, just "helper for documents", with a body that just says "help with documents"
What you should see: A second skill folder that looks perfectly healthy. The checks will show why it is useless.
Fresh matters because skill discovery happens at session start. Close Claude Code, open it again inside your repo, and run these in order; the last two tell a story.
Discovery reads the folders at startup, so this doubles as a check that everything landed in the right place.
what skills and commands do you have here?
What you should see: An inventory naming meeting-brief, doc-helper, and the /weekly-log command. Anything missing means it landed in the wrong folder; ask Claude where it put the file.
You never say the word meeting-brief. The description has to do the matching.
put together a brief for thursday's steering committee
What you should see: The skill fires unnamed, reads both source files, and a one page brief lands in deliverables/briefs with the date and meeting in the filename. Purpose, attendees, open questions, decisions: all four sections filled from your material.
Type it with today's actual date in place of the placeholder. Nothing happens until you type the name, and that is the point being proven.
/weekly-log 2026-08-17
What you should see: A one page summary in the logs folder covering the week's changes, which by now includes everything this pack built.
This request is exactly what doc-helper was supposedly for. Watch what does not happen.
help me with a document
What you should see: Claude asks what you want or muddles through generically, and doc-helper never fires, because "helper for documents" matches nothing specific enough to act on. A skill with a vague description is a dish nobody can order.
Same skill body, same name, new description. If your research folder is empty, drop one rough messy note in it first so there is something to clean. Run the second prompt in a fresh session after the rewrite.
rewrite doc-helper's description: it turns rough notes in the research folder into a clean one page summary, and it should trigger whenever i ask to clean up, tidy, or summarize my notes
clean up my notes from this morning
What you should see: This time the skill fires and a clean summary appears. The body never changed. The description was the entire difference, which is why the description deserves more care than any other line in a skill.
Back to the Module 02 lesson, or straight to the quiz.