菜单
Engineering leadership principles and decision-making framework. Use whenever working on engineering projects, sprint planning, architecture decisions, code reviews, incident response, or team discussions. Apply these principles proactively.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | engineering-leadership |
| description | Engineering leadership principles and decision-making framework. Use whenever working on engineering projects, sprint planning, architecture decisions, code reviews, incident response, or team discussions. Apply these principles proactively. |
This is the one real, worked example in this template. It is one person's engineering philosophy, written out in full. Read it for the depth a skill should have — then replace it with your own field and your own principles.
Distilled principles for how to approach every engineering project: sprint planning, PR reviews, architecture decisions, funnel analysis, incident retrospectives, data analysis, feature scoping, CI/CD setup, test strategy, and project kickoff. Apply them proactively — don't wait to be asked. If a proposed solution violates one of these principles, flag it.
01 · Data Before Decisions
Never analyse before validating the data source. Contaminated or incomplete instrumentation produces wrong conclusions regardless of analysis quality.
02 · Averages Lie — Segment Everything
High-level metrics hide the real problem. Always break down by method, geography, user type, and traffic source before drawing conclusions.
03 · Ruthless Prioritisation
Rank problems by failure rate or revenue impact. The highest-impact problem gets full attention — nothing else competes until it is resolved.
04 · Ship, Measure, Adjust — Daily
Short feedback loops beat big-bang delivery. Monitoring is part of Definition of Done, not a post-launch task.
05 · Focus Multiplies Effort
Ten people on one problem beat ten people on ten problems. The War Room model works because there is no coordination overhead.
06 · KISS — Keep It Simple
Complexity is a liability. Every unnecessary abstraction adds maintenance cost and cognitive load to the next engineer.
07 · YAGNI — You Aren't Gonna Need It
Build for today's requirements, not tomorrow's hypotheticals. Premature generalisation adds complexity with zero benefit.
08 · TDD — Test-Driven Development
Write the test first. The code is just making the test pass. TDD is a design practice, not a coverage metric.
09 · Quality Gates in CI/CD
Broken code never reaches the next environment. Every environment promotion must pass all gates — no manual overrides without documented approval.
| Gate | What it checks |
|---|---|
| 1 · Build & Syntax | Compiles, imports resolve, no syntax errors |
| 2 · Lint & Format | Style guide, no unused vars, no prod console.logs |
| 3 · Type Check | No type errors, no unannotated any |
| 4 · Unit Tests | All pass, ≥80% coverage, coverage can't decrease without sign-off |
| 5 · Integration Tests | Auth, payments, data writes end-to-end; contract tests |
| 6 · Security Scan | No critical CVEs, no secrets in code, OWASP top-10, least-privilege IAM |
| 7 · Staging Smoke Tests | App starts, key flows respond — gate 7 fail = no prod deploy |
09b · Ownership — Name on the System
Every system has a person (or team) accountable for it. No orphaned services, no "someone else will fix it."
10 · Build for Observability First
Define the success metric before building. Instrument failures, not just successes — survivorship bias in analytics is dangerous.
11 · UX Quality is Engineering Quality
User experience issues are product defects, not design preferences.
12 · Document and Distribute Learnings
Institutional knowledge must be explicit. Write retrospectives for methodology, not just outcomes — write for someone who was not in the room.
13 · AI-First by Default
The question is not "how can AI help here?" but "should a human be doing this at all?" Repetitive tasks, test generation, security scanning, and deployment validation are candidates for full agent ownership.
When reviewing a proposal or PR, check against:
When starting a project, confirm:
When analysing data, always:
When writing retrospectives, always include:
Apply WCAG 2 Level AA accessibility standards to design systems, UI components, and web pages — contrast math with a runnable validator, design-token patterns that make color accessible by construction, typography and focus-state rules, and a semantics checklist. Use when building or reviewing UI, choosing colors or type for a brand/design system, setting up design tokens, wiring accessibility checks into a build, or when the user mentions accessibility, a11y, WCAG, contrast, or screen readers.
Detect AI-sounding drift in written content and apply a surgical de-slop pass only where needed. Run on drafts before sending for review.
Read raw notes in inbox/, classify and label each one, draft what should be drafted in the author's voice, and open the results for review. Never publishes on its own.
Voice and drafting guide for all writing meant for other people: posts, articles, updates, messages. Use whenever drafting or editing for an audience. This file handles drafting; the voice itself lives in TASTE.md. If the two conflict, TASTE.md wins.
