toolkit

Turn two API spec snapshot JSON files (before and after) into one self-contained HTML page that colour-codes added and removed endpoints and fields and lists the endpoints they affect. Use for requests like "API 뭐가 바뀌었는지 정리해줘", "이번 배포에서 계약이 어떻게 달라졌나", "클라이언트팀에 변경분 알려야 해".

Read a source tree statically to extract an API spec snapshot JSON, and turn it into one self-contained HTML catalogue page with search, filters and a schema tree. Supports Spring Boot and FastAPI. Use for requests like "이 레포 API 뭐뭐 있는지 뽑아줘", "엔드포인트 목록 정리해줘", "API 스펙 화면으로 보여줘".

Build up what you did as [problem - solution - result] entries in one place under your home directory, and render what has accumulated into a quarterly achievement dashboard HTML page. Entries accumulate in `~/.brag/` rather than in a project, so achievements spanning several repos and several employers gather in one place. Use for requests like "이번 분기 한 일 정리해줘", "성과 기록해줘", "brag 문서 만들어줘", "평가 자료 뽑아줘", "연봉협상 자료 만들어줘".

Build a single HTML page for reporting or sharing inside a company, out of `template.html`. Pick a preset for the purpose (analysis, finance, status, proposal), then delete or duplicate sections and fill them in; what comes out is one self-contained file. Use for requests like "보고서 만들어줘", "발표자료 만들어줘", "주간보고 정리해줘", "이 논의 HTML로 뽑아줘". Subject-agnostic.

Pick an open GitHub issue and close it — choose one that is not blocked, fix it, prove it by reverting, close it. Use for requests like "이슈 해결해줘", "열린 결함 처리해줘". For opening a new issue, use the `plan-issue` skill.

File a discovered defect or open decision as a GitHub issue — what does and does not become an issue, the six-section skeleton for the body, and the standard label assignment. Use for requests like "이슈 등록해줘", "이슈로 남겨줘", "백로그에 넣어줘", "이거 이슈감이야". For fixing and closing an issue that already exists, use the `issue-resolution` skill.

Turn one incident record into a single retrospective HTML page — a timeline, [cause - action - prevention] cards, and action items. With no timestamps the timeline section is left out rather than invented, and the output says it was left out. Use for requests like "장애 회고 써줘", "포스트모템 정리해줘", "사고 보고서 만들어줘", "이 장애 원인 정리해서 문서로".

Classify user, document, or code changes and update existing evidence-linked documents with independent review and resumable runs. Use for change intake, setup, or repeated document updates; behavior targets stop at implementation handoff. Excludes new knowledge bases and remote publication.

Independently review a knowledge-update packet against pinned source and the reader's task, returning a plan-bound decision. Use before applying a prepared document update; does not author or apply the proposal.

Write, restructure, or condense human-facing work documents for their audience and purpose. Use for FE/BE engineering documents, UI/UX design explanations, PO decision proposals, service specifications, and cross-functional handoffs. Excludes agent instructions and proofreading-only requests.

Write a PR body — the four required sections (What / Why / Verification / What the green run does not establish), the three conditional ones, and the rule that section names are English while their content is Korean. Use for requests like "PR 만들자", "PR 열어줘", "PR 본문 써줘", "pull request 올려줘".