菜单
Classify an incoming request by type and complexity before routing to a specialist agent. Use when a request needs to be categorized to determine which agent and pipeline to invoke.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Review code for correctness, security, performance, and maintainability using a systematic checklist. Use when the reviewer agent is asked to assess any code change or existing code.
Systematically investigate a bug through evidence-based root cause analysis. Use when the debugger agent is working a reproduction, isolation, or fix-proposal step.
Produce architecture decisions, system designs, and integration patterns. Use when a feature spans more than one subsystem or when a design decision must be documented before implementation starts.
Decompose a profiled request into a concrete, ordered list of agent tasks. Use after profiling any M, L, or compound request to produce the task list the planner emits.
Look up API, option, config, or usage details for any library declared in ./sources.txt by walking its local documentation tree. Use when the user asks how a documented feature works, requests an example, or asks for a version check.
| name | profiling |
| description | Classify an incoming request by type and complexity before routing to a specialist agent. Use when a request needs to be categorized to determine which agent and pipeline to invoke. |
Profiling classifies a request across three dimensions before any work begins. It is the first step in every non-trivial session and the entry point for any request that could go to more than one agent.
Invoke this skill when:
Do not invoke this skill for pure lookup requests that clearly target a single
library or API — route directly to doc-library instead.
| Type | Signal keywords / patterns |
|---|---|
lookup | "how does", "what option/version/API", "does X support Y" |
design | "architecture", "ADR", "pattern", "data model", "integrate" |
feature | "implement", "add", "build", "write", "create", "refactor" |
review | "review", "check my code", "is this right", "any issues" |
bug | "broken", "error", "exception", "crash", "not working" |
compound | Two or more types present in the same request |
When type is compound: list each sub-type in order of logical execution.
Standard sequences:
bug → feature → reviewdesign → feature → review (skip design for S)review → design → feature → review| Size | Definition |
|---|---|
S | Single file, self-contained, answer fits in one reply. |
M | Multi-file, one subsystem, clear bounded scope. |
L | Cross-subsystem or cross-library, requires design before code. |
XL | Greenfield, major refactor, or scope is not yet determined. |
When size is XL: do not profile fully. Ask one clarifying question to
bound the scope, then re-profile.
| Risk level | Triggers |
|---|---|
low | Read-only queries, internal tooling, isolated utility code. |
medium | User-facing features, external API integrations, data mutations. |
high | Auth, payment, PII, secrets handling, LLM prompt construction. |
When risk is high: the reviewer must review the design (if L) before
implementation starts, and must review the implementation before it is done.
Type: <type> | Size: <S/M/L/XL> | Risk: <low/medium/high>
Sub-types (if compound): <ordered list>
Clarifying question (if XL): <single question>
After profiling, hand the result to the task-breakdown skill to produce the
task list, or route directly to the target agent for S + lookup cases.