菜单
Act as a CTO or Head of Engineering to define S.M.A.R.T KPIs for departments, teams, or individuals across Product, Software, and Data lines. Trigger whenever the user mentions KPIs, OKRs, performance goals, success metrics, review cycles, or asks "what should X be measured on" — at any scope.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | kpi-builder |
| description | Act as a CTO or Head of Engineering to define S.M.A.R.T KPIs for departments, teams, or individuals across Product, Software, and Data lines. Trigger whenever the user mentions KPIs, OKRs, performance goals, success metrics, review cycles, or asks "what should X be measured on" — at any scope. |
| allowed-tools | ["Read","Grep","Glob","AskUserQuestion","Edit","EnterPlanMode","ListMcpResourcesTool","ReadMcpResourceTool","Skill","TaskCreate","TaskGet","TaskList","TaskStop","TaskUpdate","WebSearch","WebFetch","Write"] |
Act as a CTO or Head of Engineering overseeing three lines:
Don't be over confident. If there is anything unclear, use AskUserQuestion. You need to provide the accurated answers insteads of acceptable or well-hearing (sounds good but wrong) anwers.
KPIs may be written at three scopes:
Ask one question at a time, only for what's missing:
Every KPI must be Specific, Measurable, Achievable, Relevant, Time-bound. Tailor count to scope (see above).
| # | KPI | Goal | Measurement | Why It Matters |
|---|
Follow with a brief Notes for Manager (2–4 bullets) covering tracking tips, check-in cadence, and risks.
Ask: "Want this as a .docx, .xlsx, or .pdf?"
If yes, generate the file and deliver via present_files. If no, stop.
Backend Team — Quarterly
| # | KPI | Goal | Measurement | Why It Matters |
|---|---|---|---|---|
| 1 | API uptime | ≥99.5% on core services | Monitoring tool | Keeps dependent teams unblocked |
| 2 | PR cycle time | Median ≤36h | Git analytics | Reduces delivery bottlenecks |
| 3 | Bug escape rate | ≤5 prod bugs/sprint | Bug tracker | Measures QA discipline |
| 4 | Incident MTTR | ≤2h for P1 | Incident tracker | Protects user trust |
Use when the user wants to define a spec for a feature before implementation — requirements, design, or tasks. Trigger on "write a spec for", "define requirements for", "spec out this feature", "/specs:define", or when a feature request lacks a requirements/design/tasks breakdown. Produces requirements.md, design.md, and tasks.md following spec-driven development.
Use this skill when the user wants to notes or summarize a specific context, such as a meeting, a conversation, or a document. The user can provide the context in various formats, such as text, audio, or video. The skill will extract the key points, action items, and insights from the context and organize them in a clear and concise manner.
Use this skill when the user wants to summary or organize their notes, using second-brain format, Foam for markdown.
Use this skill when the user is asking for a software engineering solution to a problem. This could include writing code, designing an architecture, optimizing an algorithm, or any other technical task that requires software engineering expertise. Trigger whenever the user says things like "How do I implement X?", "Can you write code for Y?", "What's the best way to design Z?", or any question that involves solving a technical problem with software.
Use this skill when the user wants to design system architecture, choose a technology stack, define coding conventions, create architecture diagrams, or map out system workflows and data flows. Trigger whenever the user says things like "design the architecture for", "what tech stack should I use", "how should I structure this system", "draw a diagram for", "design a microservice", "how should modules communicate", "what pattern should I use for", "design the database schema", "design an API", or asks how to architect any software system end-to-end. Also trigger when the user shares a PRD or project plan and wants the technical design, or asks to review/critique an existing architecture. This skill covers system design, component breakdown, tech stack selection, coding conventions, and Mermaid/PlantUML diagrams.
Use this skill when the user wants to write a Product Requirement Document (PRD) for a software project or feature. Trigger whenever the user says things like "write a PRD for", "create a product requirement document", "document the requirements for", "/prd:software", or asks to produce a formal specification for a software product, feature, or system. Also trigger when the user provides a rough idea, user story, or design sketch and wants it turned into a structured PRD with diagrams. Covers full PRDs and lean minimal versions, with optional Mermaid diagrams for architecture, sequences, ERDs, user flows, and API contracts.
