name: lauren-poteto-rules description: Use when an engineering task requires diagnosis, runtime verification, correction of recurring agent failures, or coordination of delegated coding work.

Lauren Poteto Rules

Engineering instructions for Grok Bot, adapted from Lauren Tan's ideas on verification, agent environments, and durable engineering judgment.

Agent instructions

Use these rules for engineering investigation, implementation, review, and delegation. Follow the repository's instructions and the user's scope. Apply only the relevant parts: an explanation needs code evidence; a behavior change needs a running check; a typo needs a document check. Creating tooling or evaluating skills is conditional work, not a prerequisite for every task.

1. Pair with the human

Make the work understandable enough to review and maintain.

• For a non-trivial task, state the problem, material assumptions, and what would demonstrate success. Continue with routine choices already covered by the request.
• Explain consequential decisions using relevant code and observed behavior. Give the reviewer enough context to judge the result without reconstructing your session.
• Keep independent changes separable. When writing commits or pull requests, explain why behavior changed so history remains useful for investigation and reversal.
• Optimize for reviewed, working outcomes rather than code volume or pull-request count.

2. Earn trust with evidence

Close the loop between a claim and the running system.

• Before diagnosing a cause, inspect the affected implementation and trace the relevant calls or data flow. Cite the code and observations supporting your explanation. Mark an untested explanation as a hypothesis.
• For a bug, reproduce the reported behavior before fixing it, then repeat the same steps after the change. If reproduction is blocked, report the missing access, input, or environment and what remains uncertain.
• Exercise the interface users depend on: the UI, API, CLI, or device flow. A passing build alone does not prove runtime behavior.
• Match evidence to the claim. A screenshot can show appearance; interaction claims need an exercised sequence. Performance claims need comparable measurements, traces, or profiles.
• Check correctness and engineering quality separately. A passing flow does not establish that the implementation is maintainable or efficient.

3. Make verification repeatable

Give the next agent both a way to operate the app and a way to find the feature.

• Discover and reuse the repository's actual setup, run, test, and diagnostic tools. Never invent a verification command.
• Consult the feature map when available. It should connect a user-visible feature to its entry point, prerequisites, navigation steps, relevant code, and expected result. Confirm the affected entry against the running app.
• If agents repeatedly get lost, capture the verified route for that feature in existing project documentation. Avoid mapping the whole application for one small fix.
• When developing verification tooling, start locally or in another observable environment. Inspect its actions and failures before using it unattended.
• Turn recurring manual checks into reusable procedures when this fits the task. Record setup, inputs, expected outcomes, evidence locations, and cleanup needed. Keep affected procedures current when the product changes.

4. Treat the codebase and history as memory

Agents learn from the examples they find. Today's shortcut can become tomorrow's convention.

• Inspect nearby code and documented conventions before implementing. Use relevant history when the reason for a pattern is unclear.
• Validate a pattern before copying it. Frequency does not make an obsolete workaround correct.
• Fix the underlying cause within scope. If a workaround is necessary, explain its limitation and removal condition.
• Remove temporary scaffolding introduced by your work. Preserve useful explanations of non-obvious constraints; do not turn a one-off review remark into a permanent comment or universal rule.

5. Turn corrections into durable constraints

When the same mistake can recur, improve the environment that permits it.

Choose the smallest effective mechanism:

• Prefer enforceable constraints where feasible. Written rules and automated review remain fallible guidance.
• Verify that a new check rejects the bad case and permits a valid case.
• Record the general principle and when it applies. Omit the incident's names and history. Extend existing instructions rather than accumulating duplicates.
• Follow the target project's constraints. Lauren's project-specific bans on comments or useEffect do not establish universal bans.
• Keep broader architectural changes as a scoped follow-up when they exceed the task.

6. Keep the supported path healthy

Make the shortest route to an implementation follow the intended design.

• Use the canonical helper or module when it meets the need. If it lacks a capability, consider a scoped improvement before adding a competing implementation.
• If several patterns conflict, inspect their usage and constraints before selecting one.
• During maintenance, update obsolete examples and callers together. If existing debt cannot be removed yet, consider preventing new instances while tracking existing exceptions.
• In a new project, establish a minimal working example and enforce important boundaries before agents replicate the first implementation across features.

7. Evaluate rules and skills

Apply this when creating or changing agent instructions or verification workflows.

• Start with an observed failure and define the behavior that should improve. Skills should grow from evidence about how agents work.
• Use representative tasks and observable criteria: did the agent inspect relevant code, exercise the flow, and provide valid evidence? Include a routine task to detect unnecessary process. A dedicated evaluation framework is optional.
• Compare behavior before and after the change when practical. Inspect tool calls, edits, and artifacts, not the agent's confidence or a score alone.
• Keep expected answers out of the evaluated agent's task. Use fresh sessions and the intended model and environment where available.
• Inspect failures and refine the smallest relevant instruction or tool. Re-run affected cases after changes. If execution is unavailable, label the revision untested rather than claiming improvement.

8. Scale only what you can verify

Increase autonomy after the verification loop works reliably.

• Before expanding unattended work, demonstrate that one representative task can be investigated, implemented, exercised, and reviewed using available tools.
• When delegating, pass the repository and revision, scope, relevant instructions, verification procedure, and expected evidence. Make ownership explicit for parallel work.
• Inspect returned changes and evidence. Verify the integrated result when independent changes can interact; a worker's completion message alone is insufficient.
• Preserve the user's existing action boundaries. Successful verification does not grant additional permission.

Completion report

Finish with the result, checks actually performed, accessible evidence, and any material limits. Keep it proportional to the task. Distinguish observed results from hypotheses and worker-reported results from checks you performed yourself.

Lauren Poteto Rules

A portable engineering skill inspired by Lauren Tan's talks about working with coding agents.

It teaches an agent to inspect before diagnosing, verify behavior in the running product, turn repeated corrections into durable constraints, and increase autonomy only after the verification loop works.

What it changes

• Evidence before confidence. A diagnosis must come from relevant code and observed behavior.
• Run the product. Builds and type checks do not prove a user flow works.
• Make verification reusable. Record how to reach and exercise important features.
• Treat the codebase as memory. Agents copy existing patterns, including bad ones.
• Improve the environment. Prefer architecture, types, lint rules, and CI over repeated review comments.
• Evaluate agent instructions. Change skills in response to observed failures and test the resulting behavior.
• Scale trust gradually. Delegate more work only when results remain reviewable and reproducible.

Read the complete instructions in SKILL.md. See EXAMPLES.md for concrete failure modes and expected behavior.

Install

Grok Bot

Download SKILL.md, attach it to a Grok Bot conversation, and send:

Create a private skill named "Lauren Poteto Rules" from the attached SKILL.md.
Preserve its scope and instructions. Use it for engineering investigation,
implementation, review, and delegation.

After Grok Bot saves it, confirm that Lauren Poteto Rules appears under Marketplace → Your plugins → Manage plugins and skills → Private skills. Invoke it from the / menu when needed.

For a one-off task, attach SKILL.md and ask the Bot to follow it without saving a skill.

Grok CLI

Clone the repository into Grok's personal skills directory:

mkdir -p ~/.grok/skills
git clone https://github.com/unicodef1wn/lauren-poteto-rules.git \
  ~/.grok/skills/lauren-poteto-rules

Start a new session and invoke /lauren-poteto-rules. To share it only inside one project, place the folder at .grok/skills/lauren-poteto-rules in that repository.

Codex

Clone it into the user skills directory:

mkdir -p ~/.agents/skills
git clone https://github.com/unicodef1wn/lauren-poteto-rules.git \
  ~/.agents/skills/lauren-poteto-rules

Start a new Codex session and invoke $lauren-poteto-rules. For one repository, use .agents/skills/lauren-poteto-rules instead.

Claude Code

Clone it into Claude Code's personal skills directory:

mkdir -p ~/.claude/skills
git clone https://github.com/unicodef1wn/lauren-poteto-rules.git \
  ~/.claude/skills/lauren-poteto-rules

Invoke it with /lauren-poteto-rules. For a project installation, use .claude/skills/lauren-poteto-rules.

Cursor

Create a project rule with New Cursor Rule or Cursor Settings → Rules. Choose Agent Requested, use this description, and paste the body of SKILL.md:

Engineering workflow for evidence-based diagnosis, runtime verification,
durable constraints, and safe delegation.

Project rules live in .cursor/rules and can be committed with the codebase. For a simpler project-wide setup, add the instructions to the repository's root AGENTS.md.

Use it

Give the agent a bounded engineering task and the real project context:

Use Lauren Poteto Rules for this task.

Repository: <repository or working directory>
Task: <the behavior to investigate or change>
Expected result: <observable outcome>
Constraints: <scope or actions requiring approval>

A useful completion report states the result, the checks actually performed, the evidence, and anything still unverified.

Evaluate it

Run the same tasks in fresh sessions with and without the skill. Compare actions and artifacts:

• Did the agent inspect the relevant code before naming a cause?
• Did it reproduce the bug or clearly explain the blocker?
• Did it exercise the affected user flow?
• Can another engineer repeat the verification?
• Did the change stay within scope?
• Did a small task remain small?

Use several runs. Judge tool calls, diffs, and evidence rather than the agent's confidence.

Credits

The engineering principles are adapted from talks by Lauren Tan (@poteto). The wording, structure, installation guide, and examples are an independent community adaptation by unicodef1wn.

Inspired by the compact packaging of andrej-karpathy-skills. This is not an official Lauren Tan, xAI, Cursor, Anthropic, or OpenAI release.

License

MIT