ワンクリックで
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