如何編寫 AI 智能體每次工作階段開始時載入的設定檔

Sterling Chin, an applied AI engineer and senior developer advocate at Postman, credits a capable model, but almost none of what made his agent useful was model selection. Most of it is files the session loads before he types anything. His agent, Marvin, is custom commands and markdown on Claude Code. Chin read Marvin's own description aloud: no fancy framework, just markdowns, files, bash scripts, and stubbornness. The CLI is the engine. The file around it is the part you can actually edit.

That startup file is a system prompt: who the assistant is, what it should and should not do, which tools it may use, and how to format answers. Chin treats Claude Code's project instructions file as that prompt. It holds his work context and the people he talks to, including his boss, Quintin, so a new session does not have to guess. A long file is billed as input on every call, so I would keep it to facts the next session will get wrong without.

This is a sketch I would start from. It is not Marvin's file, and it is not something Postman ships.

# Session manual (sketch)

## Who you are
Assistant for <name>, <role>.
People: <name>, <role>. If a name is not listed, ask. Do not invent a role.

## Priorities
Helpful first, personality second.
On a decision, brainstorm. Do not agree by default.
Work only inside: <confluence space url>, <kanban board url>.

## Tools you may use
Start command: work email, work calendar, state file.
Tickets and docs: only the links above.

## Never
Do not search the whole ticket system.
Do not edit a deck, ticket, or message from a guessed role.
Do not send on my behalf unless I named the recipient and the channel.

## Report back
After a chunk of work: what changed, what you assumed, what I should check.
Write a short checkpoint the next session can read.

What do you put under identity and priorities?

Chin wrote behavior into the file, then rewrote it when the behavior drifted. Marvin was built to be sardonic, direct, and unwilling to play yes-man, because Chin wanted a brainstorming partner. The agent then over-indexed on sarcasm. Chin added a line he still points at: helpful first, personality second. Marvin wrote that line into its own description. I would put the correction in the file the same day you notice the drift. A verbal "too much" in one chat dies with the window.

The failure that looks like competence is a missing fact. Before a Postman meetup Chin runs in the San Francisco area, Agents and APIs, he told Marvin that Heidi and James were doing security. They are security guards at Postman. Marvin read a speaking slot, updated the slide deck, and did the follow-through for a premise that was wrong. Chin called it a junior mistake and said a good junior would not make it twice. He explained their roles and Marvin redid the work. My rule would go further: a name the agent will act on gets a role next to it in the file, because a chat aside is not a record.

Which tools do you name, and which do you leave out?

The first Marvin failed on a vague order. Chin told it to fetch his Jira tickets. Marvin had no way to know which ones. Atlassian held thousands, including tickets Chin only watches. He stopped handing it a search space. He pasted the full link to his Confluence space, the DevRel workspace he works from, and his Kanban board.

That choice is context engineering: you decide what enters the window, and you decide what stays out. A link is a boundary. "All my tickets" is how you poison the session with the wrong thousand rows. Chin designs around a known budget. In his demo Marvin adds the day's session, writes a checkpoint, and Chin can then clear or compress the context, because, as he put it, "you know you've only got 200,000" (tokens, in his case). Checkpointing pays off for cost and for focus even with larger windows.

His slash start command runs bash that pulls work email, the calendar, and a state file of where the work stands. slash end closes the day. slash update writes the chunk he just finished. Days are sessions. An end-of-week report compresses the last five sessions. Repeated workflows sit in a skills directory as markdown procedures, separate from the startup file, following advice he got from mentors to automate anything you do twice.

A startup script that always pulls the same sources is a fixed path. Robotic process automation is that previous generation: deterministic, and brittle when the layout or the case changes. The manual is where you say the script may run, and where the agent must stop. Chin's secondhand account of a security review was a scoping answer: Claude Code was already approved, Marvin was not doing anything above and beyond, and it stayed in a clearly defined space. Write that space down. "Approved" is not a tool list.

When the next session inherits a stale handoff, repair the state file before you add tasks. Keep your agent's context current walks that repair.

What must the report include?

Chin likes the return a coworker would give: a short account of what changed, not a dump of the work. His content subagent carries absolute rules, including a style rule to replace em dashes with commas, periods, or colons. The agent flagged a draft line as borderline on the contrastive-pattern rule Chin hates, and he sent it back. That flag belongs in the report format. Say what you changed, what you assumed, and what the human should read.

Hold the numbers loosely. Chin says Marvin now runs 90 plus percent of his day, and after the first week Marvin's own weekly report listed 190-something line items. The first is his estimate and the second is the agent counting itself. If the report is how you decide the agent is paying off, an agent counting its own output is the weak link. Ask the file to show assumptions. Then check them.

Marvin runs primarily on Claude Code, and Chin says it can also run on Codex or Gemini CLI. The engine can change; I would expect the startup file to be the part worth carrying over. I would not wait on the engine. I would write the file, then see what the first real session gets wrong.

Checklist

• Load one file every session: who it is, which people and roles, priorities, allowed links, refusals, report format.
• Replace "get my tickets" with the space URL and the board URL you actually use.
• When a correction sticks (tone, a wrong role, a forbidden action), edit the file that day.
• Checkpoint against a token budget you can name. Chin planned around 200,000.
• Read the report for assumptions. Do not treat the agent's count of its own work as the result.

The longer explainer, with the episode clips, is on Chain of Thought. It draws on this episode.

Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one.

Drafted with AI assistance from the episode transcripts.