一键导入
observability
Use at the end of each task loop to emit a trace record for auditability, debugging, and future CI-based agent evaluation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use at the end of each task loop to emit a trace record for auditability, debugging, and future CI-based agent evaluation.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use for general product implementation work that is not primarily backend architecture, pure integration wiring, or screenshot-driven design-to-code.
Use when the main deliverable is maintainable documentation such as repository rules, onboarding guides, runbooks, ADRs, or architecture notes.
Use on first entry to a new repository to run environment scanning and ask targeted boundary questions before implementation.
Use after writing or modifying code to enforce the mandatory write → test → fix → repeat validation cycle.
Use before committing to a design or plan to force assumption-surfacing. The agent challenges your design, questions edge cases, and flags gaps — you patch vague decisions. Prevents the failure mode where a design "feels explained" but contains hidden flaws that only appear during implementation.
Use to establish and maintain a shared domain glossary (UBIQUITOUS_LANGUAGE.md). Creates a single source of term definitions that all agents, prompts, and documents must use — preventing semantic drift and repeated re-explanation across sessions.
| name | observability |
| description | Use at the end of each task loop to emit a trace record for auditability, debugging, and future CI-based agent evaluation. |
Use this skill to produce trace records that capture what the agent did, why, and with what outcome. Trace records support post-hoc debugging, quality evaluation, and future CI-based automated review.
Produce a trace record at the end of every completed task, after the deliverable is emitted and self-reflection is done. This is a mandatory step — see docs/agent-playbook.md → Mandatory steps (step 14: Trace).
| Scale | Trace depth | Storage |
|---|---|---|
| Small | Minimal — inline in task completion summary | No separate file |
| Medium | Standard — structured trace using the standard schema | Inline block or .agent-trace/ file |
| Large | Full — structured trace file with per-role breakdown | .agent-trace/ file |
By default, trace files go in .agent-trace/ at the repository root. If the directory does not exist, create it on first use.
Filename convention:
YYYY-MM-DD-<short-task-slug>.yaml<taskId>-<role>.trace.yamlWhen CI integration is active, prefer the .trace.yaml form so automated review workflows can discover the files directly.
Embed directly in the task completion summary:
**Trace**: scale=Small | roles=[application-implementer] | files=[path/to/file.ts] | validation=pass | decisions=none
Use the same field names whether the trace is emitted inline or written to .agent-trace/.
task: "<one-sentence objective>"
date: "YYYY-MM-DD"
scale: Medium
trust_level: "<supervised | semi-auto | autonomous>"
roles_invoked:
- <role-name>
skills_loaded:
- <skill-name>
files_changed:
- <file-path>
decisions_made:
- "<DECISIONS.md entry reference>"
validation_outcome: "<pass | fail | not-run>"
reflection_summary:
correctness: "<pass | fail>"
consistency: "<pass | fail>"
adherence: "<pass | fail>"
completeness: "<pass | fail>"
isolation_status: "<clean | violation | relaxed>"
risks_accepted:
- "<risk description, or empty>"
Extends the standard trace with per-role step breakdown:
task: "<one-sentence objective>"
date: "YYYY-MM-DD"
scale: Large
trust_level: "<supervised | semi-auto | autonomous>"
steps:
- role: "<role-name>"
action: "<plan | critique | implement | review | document>"
decisions_made:
- "<DECISIONS.md entry reference>"
files_changed:
- "<file-path>"
reflection_summary:
correctness: "<pass | fail>"
consistency: "<pass | fail>"
adherence: "<pass | fail>"
completeness: "<pass | fail>"
handoff_target: "<next role, or 'user'>"
- role: "<next role>"
action: "..."
# ...
validation_outcome: "<pass | fail | not-run>"
risks_accepted:
- "<risk description, or empty>"
checkpoint_gates_hit:
- gate: "<gate name>"
action: "<approved | auto-proceeded | blocked>"
isolation_status: "<clean | violation | relaxed>"
| Field | Required | Description |
|---|---|---|
task | Yes | One-sentence task description |
date | Yes | ISO date |
scale | Yes | Small / Medium / Large |
trust_level | Standard+ | Active trust level for this task |
roles_invoked | Standard+ | List of roles that participated |
skills_loaded | Standard+ | Skills loaded or emulated for this task |
files_changed | Yes | Files modified during the task |
decisions_made | Yes | References to DECISIONS.md entries (empty list if none) |
validation_outcome | Yes | pass / fail / not-run |
reflection_summary | Standard+ | Self-reflection rubric results |
isolation_status | Standard+ | clean / violation / relaxed — context isolation compliance |
risks_accepted | Standard+ | Risks acknowledged but not mitigated |
steps | Full only | Per-role breakdown |
checkpoint_gates_hit | Full only | Which gates were triggered and their outcome |
duration or timing estimates — agents cannot measure wall-clock time accurately.Trace files in .agent-trace/ can be consumed by CI pipelines for automated quality scoring. The trace format is intentionally simple YAML to allow easy parsing without specialized tooling.
For CI consumption, use a two-part filename:
<taskId>-<role>.trace.yaml
Examples: feat-auth-001-feature-planner.trace.yaml, feat-auth-001-risk-reviewer.trace.yaml
The YYYY-MM-DD-<short-task-slug>.yaml naming from the storage convention above is for human-readable archives. When CI integration is active, prefer the taskId-role naming to enable per-role trace collection.
.agent-trace/*.trace.yaml from the working tree or build artifacts.task, scale, validation_outcome, decisions_made) are present.validation_outcome: fail → severity-highreflection_summary failures (≥ 2 of 4 dimensions) → severity-mediumdecisions_made when scale ≥ Medium → severity-low (possible missing documentation)| Exit code | Meaning |
|---|---|
0 | All traces pass — no severity-high findings |
1 | At least one severity-high finding |
2 | Parse error — a trace file is malformed or missing required fields |
The CI step should produce a machine-readable summary:
review_date: "YYYY-MM-DD"
traces_analyzed: <count>
findings:
- trace_file: "<filename>"
severity: "<high | medium | low>"
reason: "<one-line description>"
exit_code: <0 | 1 | 2>
Before marking trace emission as complete, verify:
task, scale, validation_outcome, decisions_made).agent-trace/ for Medium/Large tasksisolation_status accurately reflects context isolation compliance