/grill-me
I use an interview with recommended choices to settle blocking decisions.
Working with AI agents
A Chief of Agents is the person responsible for work done by AI agents.

Try each decision in a checkout project.
Choose the problem, assign the work, set boundaries, and review the result.
Work through the method with diagrams, examples, and practical decisions.
See how I use each skill, then copy a prompt to install it.
Describe what you're building and where you're stuck. Get a workflow, a lesson, and skills to use.
Read or download the source materials behind this guide.
Start at the beginning or choose the part you need.
An agent removed a broken interface. The checks passed because the feature was gone. The example shows what the user lost.
Start with a clear goal. Prove one journey, then leave a kit that lets the next agent continue.
Let the agent interview you. Settle the decisions that would change the work before it starts.
The checkout goal is agreed. The payment provider is undecided and changes the integration. What should the agent do first?
Write down who the product serves, what it must do, and where its limits are.
Connect one user action to a real result. A finished screen alone is not a working feature.
Prove one small journey all the way through before repeating it across the product.
Give the next person or agent enough context to continue without reading the whole chat.
The takeover kit
The product, boundaries, and end-to-end outcomes.
Decisions, dependencies, and a clear test for done.
The next task and where to begin.
The exact code version, proof, and unfinished work.
The conversation can end. Save the decisions, code, and proof where the next agent can read them.
Agree on the product goal. Build the first complete journey. Save what works.
Divide the jobs. Share progress. Check the result independently.
An agent can work longer on its own when it knows the goal, limits, and stopping point.
The human continuously supervises the work.
A written goal, task board, proof, and stopping point guide the work.
Give one lead responsibility for the result. Let builders do the work and separate reviewers check it.
Three agents finished their pieces of onboarding. Who should check that a new user can complete the whole journey?
Repeat a check for one job. Coordinate specialists when several jobs must come together.
Check and improve one result until it passes.
Give specialists separate jobs, then combine their checked results.
A straight path finishes once. A loop improves a result. A network brings specialists together.
Set the limits before you leave, then return to a reviewable result.
Agree on what can continue, what must stop, and which decisions need you.
No secret exposure. No overwriting project history. No merge, live database change, or publication without the owner.
You’re away. The builder needs a product decision, but an independent test job is ready. How should the run continue?
Choose the shape your work needs. More moving parts mean more coordination.
Dependent steps that finish once
SequenceA result that needs checking and improving
LoopSpecialists working in parallel
GraphFollow this 5–6 hour example. Safe work continues; a blocked job waits; the final decision stays with you.
Step through the run. Pause one job to see what keeps moving.
Goal · Allowed actions · Limits · Test for done
5–6 HOURS AFKReview the completed work and its evidence. You should not have to supervise every step.
Follow the change from your laptop to a real customer. Each checkpoint answers a different question.
Take the change through checks, review, merge, deployment, and a live test.
An API key is a password for a service. Files, terminal output, and process details can all expose it.
Name the key you need. Never include its value.
Names onlyUse separate data and permissions so testing a failure cannot hurt customers.
A command on your laptop can still contact a live system. Check its target before it makes a call.
Make the database ready before releasing code that depends on it. Keep previously applied changes intact.
A second reviewer checks what changed and whether the intended user journey still works.
The provider reported over ten times our highest estimate. Tests were making live calls that automated checks never saw.
One test run made 238 live requests. Automated checks had no service key, so they missed the leak.
Local tests show unexpected provider usage. Automated checks stay green because they have no service key. Where should the fix go?
Deleting a broken feature can make tests pass. The test must prove the user can still do the intended task.
Save useful lessons, and turn important ones into checks.
Use past lessons to get oriented. Current code and approved rules decide what is true now.
After a serious failure, add a check or rule that catches it next time.
A local command accidentally reached production. You’ve written down the lesson. What prevents a repeat on a new agent run?
Reuse good habits. Match the tools to the task. Keep control of the final decision.
A skill is a saved set of instructions. Use it to repeat a good habit without explaining it every time.
Fix root causes.
Do not hide symptoms or remove the intended feature.Prove it works.
Use observable evidence at the layer the user experiences.Make good behavior reusable.
Skills package interviews, handoffs, memory, and autonomous runs.Spend stronger reasoning on difficult or risky work. Use faster models for routine tasks.
Builders and reviewers use separate model assignments. Keep one lead throughout a long unattended run.
This is the Chief of Agents role: choose the problem, assign the work, set boundaries, and judge the result. Agents prepare it. You decide when it reaches the real world.
The work keeps moving. Your judgment is the final gate.
Keep approval of these decisions. Delegate everything else.
The team has checked the work and prepared a release. Which arrangement keeps you at the right bottleneck?
The Chief of Agents Toolkit
Find a skill for the job. See how I use it. Add it to your agent.
Browse the full toolkit or choose a task.
89 skills and 1 review agent
Try a shorter name, a task like “debug,” or another category.
A skill is a saved set of instructions. Start with these three habits, then add tools when the work calls for them.
Set the direction before work starts.
I use an interview with recommended choices to settle blocking decisions.
I challenge a plan’s assumptions before committing to it.
I rethink the system around the requirement instead of bolting on another layer.
I define the core rules before choosing the implementation.
I name the real states and transitions a workflow needs.
I explore the goal, constraints, and direction before creating.
I turn an unfamiliar task into a procedure with checks.
I turn an agreed requirement into concrete steps.
I compare architecture options and record the decision, trade-offs, and consequences.
I turn a feature idea into a product requirements document through an interview and codebase exploration.
Turn the plan into working software.
I break broad work into small outcomes I can prove.
I work through the plan in bounded batches with checkpoints.
I assign separate jobs and review the results before combining them.
I write a failing behavior test before the fix when a regression test is useful.
I make retries safe so a repeated operation does not duplicate work.
I put validation and responsibility at the layer that owns them.
I give interface builders a guide to the actual component APIs.
I reuse my design preferences in interface-building briefs.
I remove needless generated-code clutter from a change.
Find the cause and fix it.
I reproduce the failure and find its cause before changing code.
I investigate failures that cross code, environment, and services.
I repair the cause while preserving the feature the user needs.
Check the work before calling it done.
I drive the real interface and capture proof of the user journey.
I exercise complete web journeys and record failures.
I require fresh evidence before the agent says it is done.
I check the result at the layer a person actually experiences.
I review the proposed code changes for bugs before merging.
I combine separate bug, security, and structure reviews into one verdict.
I review the actual change before it lands.
I hand a coherent change and its evidence to a separate reviewer.
I check review feedback before applying it.
I scan the proposed work for secret leaks and unsafe access paths.
I limit a security review to the change under consideration.
I investigate a suspected vulnerability using concrete code evidence.
I map assets, access boundaries, and possible attacks.
I use broader security inspection when the task calls for it.
I connect validated weaknesses into a possible attack route.
I use a supporting security pass when relevant.
I check what a change could break elsewhere and test the risky assumptions.
I use this review agent to remove redundant comments and find code that needs clearer names or structure.
Keep the next agent ready to continue.
Includes two downloadable Chief of Agents skills.
I let already-authorized reversible work continue, while protected decisions wait.
I compress prose in worker reports while keeping code and evidence exact.
I keep summaries short, direct, and decision-oriented.
I explain how the actual code and system fit together.
I write durable engineering explanations with clear evidence.
I remove filler and vague language while preserving meaning.
Coordinate agents with short reports that keep decisions and evidence visible.
I check which skill fits the task before acting; some workflows load this automatically.
I ask the agent to explain its last answer in plain language.
I keep the next action clear, break work into short steps, and cut distracting tangents.
Take finished work through release.
I verify the work and prepare a clear branch closeout.
I coordinate release after the required owner decisions are ready.
I observe the deployed system for regressions.
I resolve the target and protect risky operations.
I document the system from what actually exists.
I update release records to match what actually shipped.
Make decks, designs, and documents.
I build, render, and check slide decks.
I build reusable presentation systems.
I follow a safe read and edit workflow for a supplied design file.
I retrieve the design structure and assets from the reference.
I check the final PDF as well as the editable source.
I inspect the rendered interface for visual and layout problems.
I clarify the audience and design direction before building.
A task-specific skill for generating or editing visuals.
A task-specific browser testing tool in the historical research.
A task-specific skill for checking official OpenAI documentation.
Shape the interface and refine the details.
Set the audience, brand, and purpose before choosing a layout.
Check whether the hierarchy makes the idea easy to understand.
Check readability and access to each interaction.
Choose interface patterns and keep them consistent.
Refine spacing, alignment, and composition.
Challenge the visual and interaction choices.
Refine the details before sharing the interface.
Use motion to explain a change in state.
Connect diagrams and transitions with purposeful motion.
Give different roles and states a clear visual distinction.
Start with what a person needs to understand and do.
Build a coherent visual system for the interface.
Make each choice and its result clear.
Record definitions and source context so a team can reuse them.
Build and publish a working website.
Make useful feedback feel satisfying.
Separate ideas and give each control a clear place.
Refine typography, control sizing, and feedback.
Write direct prompts and consistent button labels.
Compare different approaches before choosing a layout.
Tune type sizes, weights, and line lengths.
Matches a project description to a workflow, a starting lesson, and skills from the available lessons.
I shape the visual direction, typography, and layout around the project.
I find what makes animations stutter and make them run smoothly.
Away from keyboard. Here, a bounded unattended run with a written contract and a human gate at the end.
A model-driven worker that reads context, uses tools, makes changes, and reports results within assigned permissions.
Product requirements document: the product contract, boundaries, outcomes, and governing decisions.
One end-to-end outcome that touches every technical layer required to make it work.
The first narrow, complete user journey, built to expose integration problems early.
The documents and verified state a fresh person or agent needs to continue a slice.
A separate Git working directory that lets workers use different branches without overwriting one another.
Persisted information that aligns workers on scope, progress, evidence, status, and budget.
An observable condition that defines when the task or slice is complete.
Tests, review findings, screenshots, logs, and verified state used to evaluate a completion claim.
Continuous integration: automated checks against the proposed change before merge.
Continuous deployment or delivery. In the example, an approved merge triggers automatic deployment.
A database change that adds structure or permissions without removing behavior existing code still needs.
A protected action that requires approval from an authorized person.
The saved project: code, documents, and a record of changes that a fresh agent can read.
Combine an approved code change with the main version of the project.
A proposal to combine a code change, with its discussion, checks, and review.
A network address that points back to this computer, rather than a remote system.
A secret value that lets an application use a service. Treat it like a password.
A reusable instruction file that teaches an agent a particular habit or procedure.
The presentation and its walkthrough, with internal details removed.
Describe your project. Find a workflow, a first step, and the skills to use.