See what shaped the result
When an agent gets something wrong, which file do I open?
When a draft uses the wrong fact or skips a useful step, where would you look first? You'll open the parts that shaped your first job so you can tell a fact problem from a method problem, or a role problem from a shared rule.
Today you are reading, not changing the organization.
Before changing the answer, find what shaped it.
Given a complaint, you can say where you'd look first and why.
A job description, a source note, and a method may all look similar. They do different jobs.
The Professor opens and explains the files. Your observations and judgments stay yours.
Is this one agent's problem, or a shared rule?
So far you've looked at the organization from the outside. In the orientation you saw the chart and the folder it lives in. In the first lesson you watched one job cross it and read what came back. You haven't opened the files that made that job go the way it did. This is the lesson where you do.
Here's the trap waiting for you when you open the folder: everything in it looks the same. Text in a file. A job description, the charter, a skill, a settings file, all just words on a page. That's what makes an organization feel like a black box. When everything looks identical, you can't say what's wrong, and you have no idea what you'd change.
Before you start
Bring the request, draft, and review from Lesson 1. If a result is missing, leave that part unfinished. You can still read the supplied files, but an example doesn't replace your missing run.
Prompt placeholder: start or resume Lesson 2. Add after the lesson-content pass.
Today you are reading, not changing the organization. The Professor opens and explains the files. Your observations and judgments stay yours.
Call in The Professor for this lesson, the same way you did in the orientation. New thread, type @, pick The Professor. On Codex, ask by name.
Start or resume this lesson
Call in The Professor (new thread, type @, pick it), then paste this. Not in your @ list?Call in The Professor (new thread, ask for it by name), then paste this. Not answering by name? Do step 6 of 0.3 Get your organization. Until then, paste it anyway: it asks for The Professor by name.
Use the native aibl-the-professor agent to start or resume Lesson 2. Read course/workforce/prompts/anw-l02.txt and course/workforce/lessons/anw-l02.md completely. Check my approved saved work, ask one question, and wait. Report missing files or native routes; do not install anything.
Seven parts, seven questions
An organization folder can look like a collection of text files. A job description, a source note, and a method may all look similar. They do different jobs.
Use the invitation from Lesson 1 to tell them apart:
| Part | What it does | In your first job |
|---|---|---|
| Agent profile WHO |
Describes an agent's responsibility and limits. | YGM owns the draft; Chief coordinates; Kansa reviews. |
| Skill HOW |
Describes a method for a kind of work. | The writing method helps turn approved notes into an invitation. |
| Context WITH WHAT |
Supplies information or instructions relevant to the job. | The request and workshop notes give the Writer its facts and gaps. |
| Command or start request WHEN you say so |
Starts work through a supported route. | The request that reached Chief, followed by the actual calls. |
| Gate WHEN it must stop and ask |
Holds an action for approval or refuses it. | The point where work must wait for you. A written rule and a tested restriction aren't the same evidence. |
| Schedule WHEN you're not there |
Starts approved work later. | This exercise doesn't ask you to schedule the invitation. |
| Work record WHAT HAPPENED |
Preserves what happened. | The work order, draft, review, and recorded decision. |
A tool is different from a skill. Reading a file is a capability; deciding which sources to read and how to check them is part of a method. A connector gives access to another service, subject to its permissions. You may see MCP used for a protocol connecting tools and resources. It isn't another agent or proof that access is approved.
Your law: one concept per card. This paragraph teaches tool versus skill, then connector, then MCP, right after a seven-row table. "Hook" arrives two sections later, the same way. Your page kept hook and MCP as "words you will recognize when you hear them" (dashed), not as taught concepts. Candidate: keep "a tool is different from a skill" here; move connector, MCP and hook to one short "Words you'll hear" box near the end.
Open the parts of your job
One step for each kind of part, in the same order as the table, then one step to use all seven.
1. Agent: read a profile
Open Chief's current native definition for your app, then the Writer's. Find what each owns, needs, and returns, and when it stops. Compare responsibilities without editing.
Say this to The Professor:
Open the Chief of Staff's file that my app actually uses and show it to me whole. Then open the Communications Writer's file beside it. Help me find what each owns and when it stops. Do not change either file.
2. Skill: read the methods
Follow the methods named by Chief and the Writer. Read the complete relevant method, not just its title. Which step would help prevent an unsupported date from becoming a confident claim?
Say this to The Professor:
Open the method the Chief of Staff's file points to, and the drafting skill named in my invitation run. Show each one whole. Separate a named method from evidence it was actually used. Ask me which step would help prevent an unsupported date from becoming a confident claim, then wait.
3. Context: read the context
Open the workshop notes and request beside the draft. Identify what supports a sentence and what remains unresolved. Read a shared rule in the charter or supplied template; reading the template is not adopting it.
Say this to The Professor:
Open the request and the two workshop notes beside the Communications Writer's draft. Then open the charter, or the supplied provisional template if no charter is adopted, and show me one shared rule. Reading a template does not adopt it. Ask me which note supports one sentence and what remains unresolved.
4. Command: find how work started
Inspect the request and agent calls that actually ran. A skill describes how to work; a start request sets work in motion. Don't assume a slash command exists because another app uses one.
Say this to The Professor:
Show me the exact request I gave my Chief of Staff for the invitation, its plan and my go where recorded, and each actual agent call after that. Tell me what each call asked for and what came back. Keep missing calls or returns marked missing. Do not run the job again.
5. Gate: inspect the limits
Find the written no-send rule, where the job waited, and any relevant configured restriction or existing safe test. If technical enforcement hasn't been demonstrated, say so. Don't send a message or attempt an outside action to test it.
Say this to The Professor:
Show me the written rule that says nothing gets sent, and the point in my run where the job waited for me. Then show me any setting that blocks a send, or an existing saved safe test where one was refused. If there isn't one, say so. Don't try to send anything or run a new outside-action test. Keep written rules, observed behavior and demonstrated restrictions separate.
6. Schedule: check for a schedule
Establish whether this course job has one. Leave unrelated schedules alone. A multi-step run doesn't prove something will run while you're away.
Say this to The Professor:
Tell me whether any schedule is switched on for this course job, using only the relevant available evidence. If you cannot establish that, say it is unknown. Don't change a schedule or inspect unrelated schedules.
7. Work record: trace the work
Follow the request to each returned result and stopping point. Where did a source fact matter? Where did a method matter? Keep a missing call or return marked as missing.
Say this to The Professor:
Follow my invitation run with me, from the request to the point where it stopped, using its public records only. Show me where a fact from the notes mattered, where the writing method mattered, and an actual agent return. If a call or a return is missing, say it's missing. Don't read private inspection responses or rerun the work.
8. Where to look: choose where to investigate
Ask The Professor for three complaints, one at a time: an old company name, an action outside the agreed boundary, and a skipped repeated step. Say what you would inspect first and why. This isn't permission to change files.
Say this to The Professor:
Give me these three complaints about an agent's work, one at a time: an old company name, an action outside the agreed boundary, and a skipped repeated step. For each one, I'll tell you which kind of part I'd look at first, and why. Wait for my answer before continuing. Don't answer for me or change files.
"Chief's current native definition for your app" (step 1), "different native definitions" and "the actual definition and configuration" (the profile section). A student calls this "the Chief of Staff's file." Also in the steps: "relevant configured restriction or existing safe test" (step 5). Candidate for step 5: "any setting that blocks it, or any saved test where it was refused."
Read one profile properly
The profile tells an app which agent to use and tells the agent its job. Supporting methods and settings may live in other files. An agent can have different native definitions for Claude Code and Codex without becoming two roles.
In the Chief of Staff's file for Claude Code, the top identifies its name and description, requests the parent model with inherit, lists tools, and sets memory: local. That memory is a scratch notebook for patterns, not evidence that a job happened.
Hunter's wording
In Tyler's supplied Claude Code Chief, the header identifies its name and description, requests the parent model with inherit, lists tools, and sets memory: local. That memory is a scratch notebook for patterns, not evidence that a job happened.
aibl-chief-of-staff is final; students see one file, aibl-chief-of-staff.md (the -lead copy is a terminal render for the bridge, not in the student package); the version to quote is PR #70's, sha 5c31a09b, which is now also the live student shelf. So Visual 5 needs one label fix, the file name on lines 1 and 2, and the quoted description, settings and headings already match.The Codex definition uses a different format. Its name and description identify the agent, and its instruction body carries the role. Don't search for the same five header lines or assume the Claude tool list applies. Read the actual definition and configuration in your app.
In either version, the description is the door sign: it says when this agent is the right choice. The body answers five useful questions:
What work does it own?
What does it read before acting?
How does it choose and carry out its next step?
What must it return, and where is work recorded?
What must it never do, and when must it ask you?
Chief can coordinate agents and record work. Its instructions keep specialist writing, research, and review with the appropriate agents. Inspect the available tools and actual permissions separately from those instructions.
The diagram will mark the identifying fields, role instructions, linked methods, and stopping rules in each app's file. Read those labels beside your own copy.
app-specific views of Tyler's current Chief definition. Show representative excerpts rather than squeezing the whole file into an unreadable image.
Read one agent file. The top, and the rest.The Chief of Staff's own file, labelled. The top lines name it and say when to call it; the rest says what it owns, what it reads, what it hands back, and when it must stop.
Every quote of the Chief of Staff's file on this page has to match the final file. Your Visual 5 (v3, this morning) shows one file with nine numbered markers: four lines at the top, five sections below. Hunter's text now says the Claude Code top has five settings (name, description, model, tools, memory) and that Codex uses a different format. His placeholder asks for a view per app, with short excerpts. So Visual 5 needs a redraw; it is shown here so you can read the page with a picture.
Lesson 6 returns to this profile for a different reason: understanding Chief's decisions. Today you're learning how the file is built. Personalizing it comes later.
One agent's, or shared?
A profile governs one role. A skill may be used by several roles. A source note may be relevant to one job or many. The charter describes shared rules. Records belong to the job that produced them.
This matters when you change something later. A correction in a shared method can affect several agents; a correction to one job's facts has a narrower purpose. Neither takes effect merely because you saved it somewhere. The relevant version must reach the next run.
You may see a hook, which is code triggered at a defined point in a workflow. A hook can perform a check, but its name alone doesn't tell you what it prevents. Read what it does and what the evidence shows.
A skill is a method an agent follows while doing a job. A command is how you start one. In this practice you start a job by calling in your Chief of Staff and saying what you want. Don't look for a slash command that isn't installed.
When something goes wrong, ask first: is this one agent's problem, or a shared rule?
Choose the right first question
In a fictional centre, an old brief says the room holds 40 people. An approved note dated 3 May says it holds 24. If the draft uses 40, first check which source it received. Renaming the Writer won't fix the source.
If the correct note reached the Writer but several drafts still invent numbers, inspect the method and actual work for a missing source check. That's a different investigation.
| What you notice | Where to look first |
|---|---|
| An old or unsupported fact | The source and what the run received. |
| A repeated step is skipped | The complete method and evidence it was followed. |
| The wrong agent gets the job | Chief's work order and the selected role's description. |
| An action crosses a boundary | The rule, actual permissions, and relevant tested controls. |
| You keep typing the same start request | The command: what start can you reuse? |
| A job didn't run later | Whether it had an enabled, approved schedule. |
| You can't tell what happened | The calls, returned work, and saved records. |
Naming the category starts an investigation. It doesn't prove the cause. If you're unsure, compare one fact with one method instruction and explain which would change if the underlying information changed.
Before you finish
On this page: "Chief" 12 times, "YGM" once, "Kansa" once. Goes with the naming ruling for you and Hunter.
Previous: Give your organization a first job · Next: Put reusable instructions in the right place
Hunter's five checks
- You can identify the seven parts in your workbench, or explain which are absent.
- You can read the actual Chief definition for your app and distinguish identity, role instructions, and settings.
- You can trace a fact, a method, and an agent's return in the first job, leaving unobserved steps unknown.
- Given a complaint, you can say where you'd look first and why.
- Your first job and original starting picture remain unchanged. Any saved observations are separate additions made with your approval.