본문으로 건너뛰기
cccskills
무료GitHub에 공개

prose-review

Review newly added comments, docstrings, and changelog entries so future readers can understand the current code. Revise development history, redundant explanations, and unclear shorthand while preserving constraints that the code cannot explain on its own.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Check that added comments, docstrings, and changelog entries document the code rather than narrate the change that produced it

설치 방법 보기

이럴 때 유용합니다

  • Review comments before committing
  • Check prose added across a branch
  • Clarify function documentation for future readers
  • Remove development-process details from changelogs

포함된 파일(1)

  • SKILL.md4.5 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Review the prose this work adds — comments, docstrings, changelog entries — against the "Writing for Future Readers" section of AGENTS.md, which is the authority. This skill is the operational check.

The reader you are writing for has never seen this change. They open the file months from now and see only the code as it stands. Detail that feels important while making a change — what the code used to do, why an alternative was rejected, that the fix was verified — is invisible context to them, and often actively misleading.

Scope

ArgumentDiff to review
stagedgit diff --cached -U0
branch (default)git diff $(git merge-base main HEAD) -U0
<path>git diff $(git merge-base main HEAD) -U0 -- <path>

The branch and <path> scopes diff against the merge base, so they cover committed and uncommitted work — prose written moments ago still needs review.

Review added lines only (^\+): comments, docstrings, and any changelog/*.md content. Untouched prose is out of scope. Read the surrounding code for each hit — the judgment depends on what the code already shows.

The Test

For each added line, ask: does this describe the code as it now stands, or does it narrate the change that produced it?

Rewrite or delete anything that:

  • Describes what the code used to do, or contrasts old behavior with new
  • Argues the change is correct, or records that it was tested or verified
  • Names an alternative that was considered and rejected
  • Only restates what the adjacent code already shows
  • Uses shorthand that made sense mid-task but won't to someone reading cold

Rationale survives only when its absence would puzzle a future reader — a constraint or non-obvious decision the code itself cannot express. Keep those, and prefer stating the constraint over recounting the discovery.

Calibration

Do not pattern-match on words like "previously", "instead of", "no longer", or "used to". They appear constantly in correct prose. Judge the sentence's subject: the code, or the change.

Legitimate — all describe current behavior:

# This queue is the queue used to push frames to the pipeline.
# ...discarded rather than flushed, since it's no longer wanted.
# ...at arg-parse time so users get a clear message instead of a downstream crash.

Violations, and their fixes:

# We used to buffer here, but that broke interruptions, so now we flush.
# → Flush immediately; buffering here delays interruption handling.

# Changed from a list to a deque for O(1) pops.
# → delete; the code shows the deque

# Note: verified this against the Deepgram sandbox.
# → delete

# Tried a lock here first, but it deadlocked with the task manager.
# → Reentrant by design: the task manager may re-enter during cancellation.
"""Replay buffered word events, replacing the old single-slot matcher."""
# → """Replay buffered word events now that a new slot may match them."""

Changelog Exception

Changelog entries and PR descriptions are release notes for users, so contrasting old and new user-visible behavior belongs there — /changelog models this deliberately. What does not belong is development-process detail: rejected approaches, review back-and-forth, verification narrative, or refactoring described from the inside.

Remediation

Fix the prose directly, then land the correction at the cheapest point:

SituationFix
Nothing committed yetJust edit the files
Committed, not pushed, one commitEdit, then git commit --amend --no-edit
Committed, not pushed, several commitsEdit, commit the fixes, then /squash-commits
Commit message wording, not pushedgit commit --amend -m for the tip; /squash-commits across the branch (interactive rebase is unavailable)
Pushed, no PR yetFix as above, then force-push with --force-with-lease
Changelog file, any timeEdit and commit normally — no history rewrite
PR description, any timegh pr edit <pr_number> --body
PR already under reviewFollow-up commit; do not rewrite pushed history

Report

List each violation as file:line, the offending text, and what it became. If the prose is clean, say so explicitly — callers rely on knowing the check ran.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

changelog

무료

Create changelog files for significant changes in a pull request, a proposed code change. Describe effects users will notice and organize entries by PR number and change type, such as features or fixes.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Writing changelog entries for a pull request
  • Separating new features from bug fixes
  • Explaining changes in user-facing language
pipecat-ai/pipecat1.7만2026년 10월 18일 업데이트

cleanup

무료

Review and improve code changes on the current branch using Pipecat conventions. Refine names and structure, add type hints and documentation, check example patterns, and make conservative performance improvements while preserving compatibility.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Cleaning up branch changes before review
  • Adding missing type hints and documentation
  • Checking Pipecat service and example patterns
pipecat-ai/pipecat1.7만2026년 10월 18일 업데이트

Review GitHub pull requests with specialized agents that check for clear bugs and violations of project instructions in CLAUDE.md. Validate bug findings before posting focused comments on the affected lines, with fix suggestions where appropriate.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reviewing a pull request for clear bugs
  • Checking changes against CLAUDE.md rules
  • Posting validated findings on affected lines
pipecat-ai/pipecat1.7만2026년 10월 18일 업데이트

docstring

무료

Add or improve Google-style docstrings, the explanations embedded in Python code, for modules and classes. Document constructor arguments, public methods, configuration fields, and enum values while preserving existing documentation that already meets the project’s conventions.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Document a Python module
  • Explain constructor arguments and public methods
  • Describe configuration fields and enum values
pipecat-ai/pipecat1.7만2026년 10월 18일 업데이트

Draft or update GitHub pull request descriptions using the actual changes and related context. Explain the problem, changed behavior, and review concerns in plain language, including breaking changes and explicit issue-closing references when applicable.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Draft a description for a new pull request
  • Rewrite a description to reflect the final implementation
  • Explain behavior changes and review concerns
pipecat-ai/pipecat1.7만2026년 10월 18일 업데이트

pr-submit

무료

Submit current work as a GitHub pull request, handling relevant uncommitted changes and reviewing prose before pushing. After creating the PR, run companion skills to generate changelog files, update the description, and return its URL.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Submitting current work as a GitHub pull request
  • Creating a branch and commits for uncommitted changes
  • Reviewing prose and adding a changelog before handoff
pipecat-ai/pipecat1.7만2026년 10월 18일 업데이트

pipecat-ai의 스킬 모두 보기

이 스킬의 문제 신고