Opens by assigning the agent a persona and an output length limit.
Documents
The file, explained
What makes it useful
Begins with a role description and a set of core mandates, then covers tone, project structure, commands, testing and a planning procedure. Contains no code blocks.
Quoted passages are verbatim. Open one to see it in the source.
01 / Behavioral framing
A stated persona and background
The first line assigns the agent a role and a specialism, naming distributed systems, database engines and scalable platforms. It is the only file in the directory that opens this way.
Source excerpt starting at line 1.
1You are an experienced developer working on the temporal project. Your task is to fix a bug or implement a new feature while adhering to the project's best practices and development guidelines. Your background is in distributed systems, database engines, and scalable platforms.
02 / From this file
Rules on how much to say
A Tone and Style section sets a target of fewer than three lines of text per response excluding tool use and code, and rules out preambles, postambles and conversational filler by example. Clarity is named as the exception where an explanation is genuinely needed.
Source excerpt starting at line 19.
19- **No Chitchat:** Avoid conversational filler, preambles ("Okay, I will now..."), or postambles ("I have finished the changes..."). Get straight to the action or answer.
03 / From this file
A planning procedure with named trade-off categories
Planning is broken into seven steps, ending with four trade-off dimensions to discuss (performance, scalability, complexity, security) and a requirement to reason about failure modes, given as crash behavior and a tenfold load increase.
04 / House vocabulary
A comment convention for deferred design
Future design considerations are recorded with a specific prefixed comment form that carries the author's name, giving deferred thinking a greppable marker.
Source excerpt starting at line 63.
63- Leave `CONSIDER(name):` comments for future design considerations
05 / Hard prohibitions
Comments are not a channel to the user
The comments rule ends by prohibiting the agent from addressing the user or describing its changes through code comments, and from editing comments that are separate from the code being changed.
Source excerpt starting at line 9.
9- **Comments:** Add code comments sparingly. Focus on *why* something is done, especially for complex logic, rather than *what* is done. Only add high-value comments if necessary for clarity or if requested by the user. Do not edit comments that are separate from the code you are changing. *NEVER* talk to the user or describe your changes through comments.
06 / From this file
Test conventions with the enforcing linter named
Several testing rules carry the tool that enforces them: a linter forbids sleeping in tests in favour of an eventually helper, and a testify linter enforces the float comparison and error assertion forms.
Put it to work
Borrow this for your repo
01If your agents narrate their work in code comments, prohibit it explicitly. It is a common default.
02Give deferred design decisions a greppable comment marker with an owner.
03Name the linter that enforces a rule so the agent can predict the failure before CI.
04Set an expected response length if agent verbosity is a problem for your team.
Temporal's file tells an agent how the codebase works. It cannot tell it which bug three customers hit this week. Modem keeps that context current and attaches it to the work.
