jungho-git/codex-work-report

Codex Work Report

• Use references/log-sources.md when the report must be based on historical Codex logs.
• Keep new guidance, snippets, and future edits aligned with that file.

---

Scope

Use this skill when the deliverable is a .md report about Codex work results.

Typical requests:

• "Codex 작업 결과를 md 보고서로 만들어줘"
• "오늘 작업 로그 보고서 생성"
• "방금 작업한 내용 보고서로 정리"
• "이전 Codex 세션 결과를 분석해서 보고서 생성"
• "보고서 v2/v3 생성", "보고서 최신화", "중복 제거"

Do not use this skill for Notion publishing by itself. If the user asks for Notion, create or update the Markdown report first, then use the Notion skill only for the publishing step.

---

Workflow

1. Resolve the report scope

• Identify the target scope before collecting evidence:
  • current turn or current session
  • date range
  • project path
  • previous report path
  • specific rollout/session/log file
• If the user does not specify a destination:
  • use the requested project's .docs/reports/ directory when working inside a project
  • use %CODEX_HOME%/.docs/reports/ when reporting on Codex itself
  • use Downloads only when the user asks for a download-folder deliverable
• If the user asks for a new version, create a new filename with v2, v3, or the requested version.
• If the user asks for "최신화", "중복 제거", or "수정", read the existing report first and update that file.

2. Gather evidence

• Use fs-mcp first for file listing, reads, writes, metadata checks, and structured search.
• Prefer evidence in this order:
  • report artifact or changed file content
  • command output and test results
  • git diff/status when available
  • completion-hook summaries in logs/notify.log
  • session JSONL in sessions/YYYY/MM/DD/*.jsonl
  • rollout summaries in memories/rollout_summaries/*.md
  • runtime/system clues in logs/codex-tui.log, states/session-context, .playwright-mcp, or .sandbox when relevant
• Exclude auth files, secrets, token payloads, cookies, caches, generated binaries, and unrelated temporary files.
• Do not paste raw full logs into the report unless explicitly requested. Extract facts.

3. Classify facts

Separate facts into these buckets:

• 작업 범위: original request, project, target files, requested report version
• 작업 결과: implemented changes, generated files, updated report sections
• 변경 파일: files actually created or edited
• 검증: commands run, parser checks, file existence checks, format checks
• 문제: failed checks, blockers, skipped checks, residual risk
• 후속 작업: next concrete steps, ordered by dependency or priority

Mark each item as one of:

• 확인됨: direct artifact, command output, file read, or git evidence exists
• 추론: derived from multiple evidence points
• 미검증: plausible but not backed by a check

4. Write the Markdown report

Default structure:

# Codex 작업 결과 보고서

- 작성일: YYYY-MM-DD
- 범위: ...
- 기준 로그: ...

## 1. 요약

## 2. 작업 결과

## 3. 변경 파일

## 4. 검증 결과

## 5. 이슈 및 리스크

## 6. 후속 작업

## 7. 근거

Content rules:

• Write in Korean unless the user asks otherwise.
• Use concise technical prose, not chat transcript style.
• Lead with the conclusion.
• Include only files actually changed under 변경 파일.
• Include failed, skipped, or risky checks under 이슈 및 리스크.
• Preserve exact command names and paths with inline code.
• Use fenced code blocks with language tags only for tree or command-output excerpts.
• Keep one tree or blueprint unless the user explicitly asks to compare alternatives.
• When a report includes a proposed tree, make clear whether it is current structure, target blueprint, or actual applied structure.
• Remove duplicated sections during updates.
• Do not invent test results, file changes, dates, or completed work.

5. Verify the report

After writing or updating the .md file:

• re-read the report file
• confirm the requested title/version and destination path
• confirm required sections exist
• confirm Markdown fences open and close correctly
• confirm changed-file list matches the evidence
• confirm every check in 검증 결과 was actually run or mark it as not run
• report any remaining uncertainty in the final response

---

Report Update Rules

When updating an existing report:

• preserve the user's chosen title and destination unless they request a new version
• merge repeated sections instead of appending duplicates
• replace obsolete tree blueprints with one latest blueprint
• keep historical findings only when still useful; label old findings as superseded if retained
• update 작성일 or add 최종 업데이트
• verify the file after the edit

---

Historical Log Rules

For historical Codex logs:

• start from logs/notify.log to identify completed turns and final summaries
• use sessions/YYYY/MM/DD/*.jsonl only for missing details, tool calls, or command evidence
• use memories/rollout_summaries/*.md for compact prior-task summaries
• use codex-tui.log for runtime failures, MCP startup issues, and system-level errors
• quote only short, necessary excerpts
• sanitize secrets and omit raw auth/token/cookie content

Read references/log-sources.md before broad historical analysis.