菜单
Use before embedded NFR budgeting when the target system, workload, measurement surfaces, resource headroom, or normal operating baseline are not yet characterized. Do not use for generic implementation work with known target budgets.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | embedded-target-characterization |
| description | Use before embedded NFR budgeting when the target system, workload, measurement surfaces, resource headroom, or normal operating baseline are not yet characterized. Do not use for generic implementation work with known target budgets. |
| metadata | {"short-description":"Embedded target characterization"} |
Use this skill to learn the real embedded, edge, or target-local system before setting production NFR budgets.
It answers one question:
What target facts, baselines, measurement surfaces, unavailable signals, and safety constraints must budget work rely on?
Use this skill when:
target_profiles/<target>.yaml is missing, placeholder-heavy, stale, or copied from a templateembedded-project-constitution exists but target-specific evidence is missingDo not use it for pure docs/schema work, generic cloud/backend NFRs, or target work whose current characterization and baselines already exist.
For broader target-learning efforts that also need hardware capability mapping, workload mapping, bottleneck/margin analysis, and architecture constraints, use embedded-system-familiarization first.
templates/target-characterization.md.target_profiles/<target>.yaml.templates/target-characterization-report.schema.json when a JSON report is useful.embedded-operating-envelope-discovery when normal/degraded/failure boundaries are unknownembedded-nfr-calibration when budgets must be derived from target evidenceembedded-nfr-design once target context is known or explicitly provisionalProduce or update:
docs/targets/<target>/target-characterization.mdtarget_profiles/<target>.yamlbaselines/resource/<target>/idle.jsonbaselines/resource/<target>/nominal_workload.jsonreports/target-characterization/<target>.jsonUse when finishing a branch or PR after verification and review, including merge, PR publication, keep, discard, cleanup, local sync, and reporting merge or PR URLs with current git state.
Use when handling received code-review feedback on a PR or diff, including requested changes, inline comments, approvals, non-blocking notes, and disputed suggestions. Separates accepted fixes, refutations, deferrals, clarification needs, and merge handoff.
Use when preparing a focused code-review request for a PR or diff after implementation evidence exists, especially to package scope, reviewer focus, PR URL, verification, known risks, and deferred work without deciding final submit readiness.
Use before every submission to decide whether required checks, artifacts, and branch evidence are complete enough to submit.
Use when work is complex, long-running, multi-step, cross-boundary, likely to span multiple PRs/sessions, or needs handoff-ready planning under plans/.
Use when adding or changing Agent-facing workflows, generated prompts, collect plans, executable handoff artifacts, CLI workflows, controller/target-local workflow chains, or validation artifacts consumed by downstream reports. Do not use for ordinary code changes without an Agent-facing workflow or generated instruction surface.