Lesson Content

Project and tool commands are powerful because they can connect a chat to real work. Commands such as /init, /mcp, /local, /cloud, /worktree, and /review can affect instructions, tool access, execution location, or review mode. Skills can also appear in command lists, and some surfaces allow explicit skill invocation with $.

/init is not a magic quality button. Its job is to create or help create project instructions, often an AGENTS.md-style scaffold in Codex workflows. Good instructions tell the assistant where the project lives, which files are protected, how to run tests, what coding style to follow, and when approval is required.

/mcp is about connected tools. MCP servers can expose external tools, data, or actions. A student should ask: Is this tool read-only or can it write? What account does it connect to? Does it expose private data? Does the task actually require it?

Local, cloud, and worktree commands are about where work happens. Local work may touch the current machine or project. Cloud work may run away from the local machine. A worktree can isolate code changes in a separate checkout. These choices matter for safety, file access, cost, and testing.

Review mode is for evaluating changes. It should focus on findings, regressions, missing tests, and risk. It is different from asking the assistant to rewrite everything. A strong student learns to ask for review before merging or deploying, not only after something breaks.

Professional Use Case: A WordPress site owner wants Codex to update a plugin. Before coding, they use project instructions to define "do not edit outside plugin folders," checks connected tools, keeps work in a separate worktree, and uses review mode before installation.

Student task: Write a project safety brief for a pretend website plugin. Include five rules: project path, files not to edit, test command, build rule, and approval rule. Then write which command category would help with each rule: init/instructions, MCP/tools, local/cloud/worktree location, or review.

?You are not writing code in this task. You are writing the guardrails a coding assistant should follow. Example approval rule: "Ask before deleting folders, changing database schema, or installing a new dependency." Sample clarification prompt: "Rewrite this safety brief so a coding assistant cannot confuse testing, building, and deployment."

Starter scenario: "I have a WordPress plugin in one folder and a separate theme in another. I want help updating only the plugin and running local tests before any build."

Starter clarification prompt: "Turn this into project instructions with protected folders, allowed test commands, and a rule that no release ZIP should be created unless I ask."

Troubleshooting: If a tool command shows no connected tools, do not invent tool access. If a local/cloud/worktree command is confusing, stop and ask the assistant to explain where files would be edited before proceeding. If review mode returns only praise, ask for concrete findings, file references, test gaps, and residual risk.

Quality Rubric:

• The safety brief protects scope and data.
• The student separates instruction setup from tool access.
• The student understands that location commands can change where work is performed.