write-ops-log

Publishes tagged incident records to Echo and links canonical URLs to pull requests.

3.2k|266|Updated Mar 22, 2024
One-click install
npx skills add https://github.com/marin-community/marin --skill write-ops-log
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: write-ops-log
Source: https://github.com/marin-community/marin/tree/main/.agents/skills/write-ops-log
Command: npx skills add https://github.com/marin-community/marin --skill write-ops-log

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Incident knowledge often gets lost in chat threads or scattered debug logs, forcing engineers to re-diagnose the same failures. This Skill standardizes how incident records are written to the Echo knowledge base so future engineers can quickly decide what to check or do next.

Core Features & Use Cases

  • Search-before-write deduplication: Invokes the consult-echo search sequence to find and edit existing entries covering the same incident instead of creating duplicates.
  • Structured OKF incident format: Drafts wiki-note documents with TL;DR, response steps, cause, resolution, and artifact links, using lowercase kebab-case tags including incident, debugging, and ops.
  • Canonical URL linking: Creates or edits entries via the Echo CLI and adds the returned canonical URL to the associated pull request or issue.
  • Use Case: After resolving a training pipeline outage, an engineer drafts a concise incident record, publishes it with uv run infra/echo/cli.py wiki add, and pastes the Echo URL into the fix PR.

Quick Start

Ask the assistant to write an ops log entry for the incident you just investigated and link the Echo URL to your pull request.

Frequently Asked Questions about write-ops-log

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write an incident postmortem for my infrastructure team?

Draft an OKF wiki-note with a TL;DR, response procedure, cause and resolution, and artifact links, then publish it with the Echo CLI using wiki add. Keep only facts that help a future engineer decide what to check next, and link raw evidence rather than pasting logs.

How do I avoid creating duplicate incident records?

Run the search-before-write sequence first: search Echo with natural language, fetch likely matches with get, and grep for the exact error or run identifier. Edit the existing entry when it covers the same incident; create a new one only for a genuinely different incident.

What tags should an incident record include?

Always include incident and debugging, add ops for infrastructure work, then append the subsystem, severity, and resolution tags. Use lowercase kebab-case and no more than 20 tags total.

Should incident details go in the repository or in Echo?

Publish the incident record to Echo, not as a repository debug-log file. Promote recurring procedures and guardrails to the relevant OPS.md, and update docs only when behavior or configuration guidance belongs with the repository.

What if the root cause of an incident is unknown?

Record the root cause as unknown rather than filling the gap with speculation. Preserve exact error strings and canonical evidence URLs so future investigators can continue the diagnosis.