Use Agent Skills to Scale Staff-Engineer Thinking Across Your Team

I recently saw that after moving from Meta to Cursor, Lauren Tan (former Staff Engineer at Meta) turned her personal workflow for understanding new codebases and unfamiliar technologies into a set of agent skills.

Highly recommended. If you're a senior or staff engineer, this approach helps your team use the same thinking framework when exploring problems with AI agents.

(Note: If you're new to agent skills, start with this article: What Are Agent Skills? What Problems Do They Solve?.)

Turn Thinking Into Process

For example, here is how Lauren Tan translates code-reading into an agent skill:

First, find the relevant code. Use Glob to locate directories and files, Grep to find key symbols, and Read to understand the actual implementation. Don't guess from names alone. Read the code. Follow this pattern:
Find the entry point: What triggers this behavior? User interaction, an API call, or a scheduled job? Identify where the flow begins.
Trace the flow: Start from the entry point and follow the call chain downward. Read each function. Understand how data moves and how it is transformed.
Identify key abstractions: Which types, interfaces, services, or classes are central? Read their definitions. Understand what they represent and why they exist.
Find boundaries: Where does this subsystem connect to other systems? What are the inputs and outputs?
Watch for non-obvious parts: What surprised you? What looks like legacy code? What would a newcomer likely misunderstand?
Keep exploring until you can describe the system end-to-end without hand-waving. If you hit uncertainty, say it explicitly: "I can't yet confirm how X connects to Y" is better than guessing.

How to Evaluate Abstraction and Complexity

Here are the questions she uses when looking at abstractions across layers:

Does each abstraction represent a real concept, or is it an unnecessary "just in case" indirection?
Are the abstraction boundaries in the right place? Do they actually separate things that change independently?
Is there accidental coupling where components share implementation details they shouldn't?
Is business logic tangled with framework configuration, or cleanly separated?

When assessing overall system complexity, she also asks:

Where is complexity concentrated? In places that truly require it (core logic, hard edge cases), or in avoidable places (boilerplate, extra indirection, configuration)?
Is there a simpler way to achieve the same result?
Does each component have a clear reason to exist, or are some leftovers from past designs?

If you want the full version, see Lauren Tan's original write-up (link).

Support ExplainThis

If you found this content helpful, please consider supporting our work with a one-time donation of any amount through this Buy Me a Coffee page.

Creating in-depth technical content takes significant time. Your support helps us continue producing high-quality educational content accessible to everyone.