incident-writer

Stars12

Forks1

UpdatedJuly 22, 2026 at 06:38

Creates and manages incident reports for jiun.dev/status with consistent formatting. Generates frontmatter, timeline, and body sections based on severity. Use for "인시던트 작성", "장애 보고서", "incident report", "status 작성", "장애 기록" requests.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

jiunbae

jiunbae/agent-skills

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	incident-writer
description	Creates and manages incident reports for jiun.dev/status with consistent formatting. Generates frontmatter, timeline, and body sections based on severity. Use for "인시던트 작성", "장애 보고서", "incident report", "status 작성", "장애 기록" requests.
allowed-tools	Read, Bash, Grep, Glob, Write, Edit, AskUserQuestion, WebSearch

Incident Writer

Creates standardized incident reports for the jiun.dev status page.

Report Location

src/content/incidents/{date}-{slug}.md

Naming convention: YYYY-MM-DD-short-description.md (e.g., 2026-03-20-tokka-email-orbstack-outage.md)

Frontmatter Schema

title: "서비스명 장애/작업 제목"       # Required
date: 2026-01-01T00:00:00+09:00       # Required: incident start time (KST)
resolvedDate: 2026-01-01T02:00:00+09:00  # Optional: resolution time
severity: major                         # critical | major | minor | maintenance
status: resolved                        # investigating | identified | monitoring | resolved | scheduled
affectedServices:                       # Array of service names
  - ServiceName
published: true                         # Set false for drafts
timeline:                               # Chronological entries
  - time: 2026-01-01T00:00:00+09:00
    status: investigating
    message: "Description of what happened."

Format by Severity

maintenance / minor → Format A (간결)

## 사고 개요
한두 문장 요약.

## 영향 범위
| 항목 | 내용 |
|---|---|
| 영향 서비스 | ... |
| 작업/장애 시간 | ... |
| 영향받은 사용자 | ... |
| 데이터 손실 | 없음 / 설명 |

## 작업 내용
- 수행한 작업 목록

major / critical → Format B (전체 post-mortem)

## 사고 개요
장애 요약: 무엇이, 언제, 얼마나 영향을 미쳤는지.

## 영향 범위
| 항목 | 내용 |
|---|---|
| 영향 서비스 | 서비스명 (구체적 기능) |
| 장애 시간 | ~N시간 (HH:MM ~ HH:MM KST) |
| 영향받은 사용자 | 범위 설명 |
| 데이터 손실 | 없음 / 설명 |

## 근본 원인 (Root Cause)

### 직접 원인
- 기술적 직접 원인

### 근본 원인
1. 원인 체인 (왜 → 왜 → 왜)

## 조치 내역

### 즉시 조치
1. 복구를 위한 즉각 조치

### 후속 조치 (Action Items)
- [x] 완료된 조치
- [ ] 미완료 조치

## 재발 방지 (Prevention)

### 1. 방지 대책 (적용 완료/예정)
구체적 설명

## 교훈 (Lessons Learned)

1. **핵심 교훈.** 상세 설명.

Workflow

Ask the user for: what happened, which services, when, severity
Determine format (A or B) based on severity
Generate the frontmatter with timeline entries
Write the markdown body with appropriate sections
Verify the file can be built: npx astro build 2>&1 | tail -5

Timeline Status Flow

Typical status progression in timeline entries:

Outage: investigating → identified → monitoring → resolved
Maintenance: scheduled → monitoring → resolved
Ongoing: investigating → identified (no resolved yet)

Existing Services

Check current incidents for service names used:

grep -h "affectedServices" -A5 src/content/incidents/*.md | grep "  - " | sort -u

Example Template Reference

See src/content/incidents/_example.md for the canonical template with all sections.

OG Image

OG images are auto-generated at /og/status/{slug}.png — no manual action needed. The description includes [SEVERITY] status — affected services.

More from this repository

same repository

rpf

jiunbae/agent-skills

Runs an explicit pointer-document-driven review, plan, work, and feedback loop with multiple agents, scheduling independent review, verification, and implementation work concurrently and pipelining revision-fenced read-only preparation between cycles until the living plan or policy converges or 128 cycles are reached. Safe for concurrent runs from different tools against one pointer. Use only when the user explicitly invokes `$rpf`; never trigger implicitly for ordinary review, planning, implementation, commit, or deployment requests.

2026-07-3112

air-workbench

jiunbae/agent-skills

Open AIR Workbench to discover local Agent Skills, visualize and round-trip a Skill workflow as AIR (Agent Intermediate Representation), review a native Codex or Claude plan, inspect observable execution evidence, or promote a reviewed plan or trace into a Skill draft. Use only when the user explicitly asks for AIR Workbench, the legacy Workflow Studio, Skill-to-graph or graph-to-Skill conversion, visual workflow editing, plan approval, observable tracing, or plan/trace promotion. Do not trigger for ordinary Skill execution, general planning, or routine Codex/Claude requests.

2026-07-3012

korean-editor

jiunbae/agent-skills

기존 한국어 초안을 의미·사실·수치·인용·문서 구조와 작성자의 목소리를 보존하며 자연스럽게 퇴고한다. 사용자가 한국어 글의 윤문, 퇴고, 교정, 번역투 완화, 기계적이거나 AI 같은 문체 완화, 간결화, 톤 정리를 명시적으로 요청할 때 사용한다. 빈 문서에서 새 글을 쓰는 요청, 번역·요약·사실 확장, 코드 수정에는 사용하지 않는다. PR·Linear·Slack·Notion 문서는 해당 문서의 내용을 작성하는 일반 요청이 아니라 문체 편집을 명시적으로 요청한 경우에만 사용한다.

2026-07-2912

managing-vault-secrets

jiunbae/agent-skills

Retrieves and stores credentials in the user's self-hosted Vaultwarden via the `bw` CLI. Use whenever a task needs a credential the environment does not already provide — npm/PyPI publish tokens, API keys, DB passwords, registry logins — and before ever telling the user a credential is missing. Triggers on "vault 조회", "API 키 가져와", "비밀번호 저장", "secret 등록", "토큰 어디", "npm token", "publish token", "배포 토큰", "credentials", "401 unauthorized".

2026-07-2812

hello-agent

jiunbae/agent-skills

Synthetic AIR example with no private session content

2026-07-2812

background-implementer

jiunbae/agent-skills

Run bounded parallel implementation with isolated workers (native worktrees or Codex), respect a dependency DAG, and verify each worker's diff before integrating. Use only when the user explicitly requests background, parallel, or multi-agent implementation, such as "백그라운드 구현", "bg impl", or "병렬 구현". Do not trigger for ordinary implementation or code-writing requests.

2026-07-2312

name	incident-writer
description	Creates and manages incident reports for jiun.dev/status with consistent formatting. Generates frontmatter, timeline, and body sections based on severity. Use for "인시던트 작성", "장애 보고서", "incident report", "status 작성", "장애 기록" requests.
allowed-tools	Read, Bash, Grep, Glob, Write, Edit, AskUserQuestion, WebSearch

Incident Writer

Creates standardized incident reports for the jiun.dev status page.

Report Location

src/content/incidents/{date}-{slug}.md

Naming convention: YYYY-MM-DD-short-description.md (e.g., 2026-03-20-tokka-email-orbstack-outage.md)

Frontmatter Schema

title: "서비스명 장애/작업 제목"       # Required
date: 2026-01-01T00:00:00+09:00       # Required: incident start time (KST)
resolvedDate: 2026-01-01T02:00:00+09:00  # Optional: resolution time
severity: major                         # critical | major | minor | maintenance
status: resolved                        # investigating | identified | monitoring | resolved | scheduled
affectedServices:                       # Array of service names
  - ServiceName
published: true                         # Set false for drafts
timeline:                               # Chronological entries
  - time: 2026-01-01T00:00:00+09:00
    status: investigating
    message: "Description of what happened."

Format by Severity

maintenance / minor → Format A (간결)

## 사고 개요
한두 문장 요약.

## 영향 범위
| 항목 | 내용 |
|---|---|
| 영향 서비스 | ... |
| 작업/장애 시간 | ... |
| 영향받은 사용자 | ... |
| 데이터 손실 | 없음 / 설명 |

## 작업 내용
- 수행한 작업 목록

major / critical → Format B (전체 post-mortem)

## 사고 개요
장애 요약: 무엇이, 언제, 얼마나 영향을 미쳤는지.

## 영향 범위
| 항목 | 내용 |
|---|---|
| 영향 서비스 | 서비스명 (구체적 기능) |
| 장애 시간 | ~N시간 (HH:MM ~ HH:MM KST) |
| 영향받은 사용자 | 범위 설명 |
| 데이터 손실 | 없음 / 설명 |

## 근본 원인 (Root Cause)

### 직접 원인
- 기술적 직접 원인

### 근본 원인
1. 원인 체인 (왜 → 왜 → 왜)

## 조치 내역

### 즉시 조치
1. 복구를 위한 즉각 조치

### 후속 조치 (Action Items)
- [x] 완료된 조치
- [ ] 미완료 조치

## 재발 방지 (Prevention)

### 1. 방지 대책 (적용 완료/예정)
구체적 설명

## 교훈 (Lessons Learned)

1. **핵심 교훈.** 상세 설명.

Workflow

Ask the user for: what happened, which services, when, severity
Determine format (A or B) based on severity
Generate the frontmatter with timeline entries
Write the markdown body with appropriate sections
Verify the file can be built: npx astro build 2>&1 | tail -5

Timeline Status Flow

Typical status progression in timeline entries:

Outage: investigating → identified → monitoring → resolved
Maintenance: scheduled → monitoring → resolved
Ongoing: investigating → identified (no resolved yet)

Existing Services

Check current incidents for service names used:

grep -h "affectedServices" -A5 src/content/incidents/*.md | grep "  - " | sort -u

Example Template Reference

See src/content/incidents/_example.md for the canonical template with all sections.

OG Image

OG images are auto-generated at /og/status/{slug}.png — no manual action needed. The description includes [SEVERITY] status — affected services.