skills/em-context/SKILL.md
--- name: em-context description: Foundation skill for engineering managers. Use when setting up context about your team, org structure, management philosophy, and current priorities. All other EM skills read this first. Also use when creating or updating a direct report profile. Trigger phrases: "set my team context," "update my EM context," "here's my team setup," "my team is," "my org is," "add a report," "update report profile," "create a profile for." metadata: version: 1.3.0 --- # EM Co
npx skillsauth add manager-dot-dev/manager-skills skills/em-contextInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This is the foundation skill. Its purpose is to capture your team, org, and individual direct report context so every other skill can work with your specific situation rather than generic advice.
This skill is not meant to be the main thing you invoke every day. It is the shared memory layer for the other EM skills.
.agents/
├── em-context.md # Your team and org context
└── reports/
├── alice.md # One file per direct report
├── bob.md
└── carol.md
Team context: Create .agents/em-context.md with your team and org context. All EM skills read this first.
Direct report profiles: Create .agents/reports/[firstname].md for each direct report. Skills like 1on1s, feedback, and performance-reviews will look for this file when you mention a person by name.
If files don't exist, ask the user for the relevant context before proceeding.
When other skills learn durable new context, they should update these files automatically. Treat them as living memory, not static setup files.
If there is no .agents/em-context.md yet, do not keep giving generic advice forever. Ask for a minimal manager profile first, create the file, and then continue.
Minimum manager profile to collect:
If a specific person comes up and there is no .agents/reports/[name].md yet, ask for a minimal profile for that person first, create the file, and then continue.
Minimum direct report profile to collect:
Do not wait for a perfect profile. Save the minimum useful context first, then enrich it over time as new conversations reveal more.
All EM skills should use em-context as shared memory:
.agents/em-context.md first if it exists.agents/reports/[name].md.agents/em-context.md does not exist, collect the minimum manager profile and create it before giving detailed advice.agents/reports/[name].md does not exist, collect the minimum direct report profile and create it before giving detailed adviceOnly save information that is likely to remain useful across future conversations.
Good candidates for auto-save:
Do not save:
When in doubt, ask: "Will this still be useful and fair three months from now?"
# EM Context
## About Me
- Role: (e.g., Engineering Manager, Senior EM, Director of Engineering)
- Years as EM:
- Company/team size:
- Industry:
## My Team
- Team size:
- Team mission/charter:
- Key areas of ownership:
- Current tech stack (brief):
- Team tenure mix: (e.g., mostly senior, mixed, mostly junior)
- Remote/hybrid/in-person:
## Org Structure
- Who I report to:
- Peer teams:
- Key stakeholders:
- How engineering relates to product/design:
## Current Priorities
- Top 3 team goals this quarter:
- Known challenges or risks:
- Recent wins:
## My Management Style
- How I like to run 1:1s:
- Feedback style (direct, coaching-oriented, etc.):
- Decision-making approach:
- Anything I'm actively working on as a manager:
## Norms and Preferences
- How we communicate (Slack, email, etc.):
- Meeting cadences:
- Performance review cycle:
- Anything unusual about this team/org I should know:
Create one file per person at .agents/reports/[firstname].md:
# [Name]
## Role & Background
- Title:
- Level: (e.g., L4, Senior, Staff)
- Tenure on team:
- Background / how they joined:
## Strengths
- [What they're genuinely good at — specific, not generic]
## Growth Areas
- [What they're actively working on or should be]
## Working Style
- How they prefer to receive feedback:
- Communication style:
- What motivates them:
- What drains them:
- How they handle ambiguity:
## Goals
- Short-term (this quarter):
- Long-term (career):
## Current Projects
- [Project name]: [their role and status]
## 1:1 Notes
- Cadence:
- What works well in our 1:1s:
- Recurring themes or topics:
## Feedback History
- [Date]: [Brief note on feedback given — topic, not full transcript]
## Flags / Things to Watch
- [Anything to be aware of — risk of attrition, stress, interpersonal friction, etc.]
When another skill says "check em-context first," this means:
.agents/em-context.md if it exists.agents/reports/[name].md.agents/em-context.md does not exist, ask for a minimal manager profile and create it first.agents/reports/[name].md does not exist, ask for a minimal profile for that person and create it firsttesting
Score an Engineering Manager's coverage across all 12 cells of the EM Grid based on their calendar and Slack. Use this skill whenever someone wants to understand where they're spending their management energy, find blind spots, get a monthly self-reflection on their EM focus, or hear phrases like "score my EM grid", "where am I spending time as a manager", "what are my blind spots", "analyze my calendar as EM", "which EM areas am I neglecting", "how balanced is my management focus", or "check my EM grid coverage". Always pull live calendar data — never ask the user to describe their week manually.
development
Helps engineering managers write messages, announcements, and stakeholder updates that land well — produces a 3-Step Writing Framework (Prepare / Write Simply / Run a Garbage Collector), the Async Re-Explanation Trap (calling out missed messages), and the Compression/Decompression model for diagnosing why messages are misunderstood. Use when the user says "draft a message," "write an announcement," "communicate this change," "how do I word this," "message for my team," "write an update," or "how do I communicate X." Do NOT use for verbal feedback or difficult conversations (use `feedback` or `difficult-situations`).
development
Helps engineering managers build a functional PM–EM partnership and become more product-oriented — produces a 3-pattern PM–EM dynamic model (PM-Led / Engineering-Led / Fake Balanced), a true partnership definition, the "It's Important to Me" card for navigating disagreements, tips for getting engineers closer to customers and usage data (launch vs. landing, session recordings, customer conversations), and an explicit responsibilities exercise. Use when the user says "PM relationship," "PM drives me crazy," "product manager," "roadmap disagreement," "PM overrides me," "PM–EM partnership," "I want to be more product-oriented," or "how do I get engineers closer to customers." Do NOT use for general roadmap prioritization (use `roadmap-planning`) or when urgency is being manufactured by a PM (use `managing-urgency`).
testing
Helps engineering managers work effectively with Software Architects, Staff Engineers, and Principal Engineers — covers the EM's side of the relationship (responsiveness, proactive consultation, giving credit), how to advocate for architect time, pre-consultation preparation, and the two architecture team models (Centralized vs. Decentralized). Use when the user says "architect," "staff engineer," "principal engineer," "technical design review," "working with senior technical people," "getting architecture help," or "how do I get more architect time." Do NOT use for managing staff/principal engineers who report directly to you (use `managing-high-performers` or `delegation`).