AGENT SKILL

inline-review

Find and address inline code-review comments left in the code, marked with the `rev:` prefix (e.g. `// rev:`, `# rev:`, `-- rev:`). These are a manual code review done inline instead of on GitHub — each comment is a question, suggestion, concern, or change request about the nearby code. Use this skill whenever the user asks you to address, handle, resolve, go through, or respond to their inline review comments, rev comments, or `rev:` comments — even when phrased tersely, like "address my rev comments", "handle the reviews", "go through the rev: notes", "I left some inline comments", "respond to my review", or just "address these" right after leaving such comments. Trigger whenever the request references `rev:` comments in the code.

使用场景代码审查
License 许可
MIT
所属仓库
esond/skills
最近更新
2026-11-07
Stars
★ 0
Forks
0

01 前言 Front Matter

name
inline-review
description
Find and address inline code-review comments left in the code, marked with the `rev:` prefix (e.g. `// rev:`, `# rev:`, `-- rev:`). These are a manual code review done inline instead of on GitHub — each comment is a question, suggestion, concern, or change request about the nearby code. Use this skill whenever the user asks you to address, handle, resolve, go through, or respond to their inline review comments, rev comments, or `rev:` comments — even when phrased tersely, like "address my rev comments", "handle the reviews", "go through the rev: notes", "I left some inline comments", "respond to my review", or just "address these" right after leaving such comments. Trigger whenever the request references `rev:` comments in the code.

02 资源文件 1

03 SKILL.md 正文

inline-review

The user has left inline review comments in the code, each prefixed with rev: after the language's comment delimiter (// rev:, # rev:, -- rev:, /* rev: ... */, etc.). Treat them like a GitHub code review that happened inline: each one is a question, suggestion, concern, or change request about the code near it.

Step 1 — Find every rev: comment

Search the codebase (or the files/paths the user pointed at) for the rev: marker. Use a delimiter-agnostic search so no comment style is missed:

rg -n "rev:" --glob '!**/node_modules/**'

Collect every hit with its file, line, and full comment text. If none are found, say so and stop — don't invent work.

Step 2 — Address each comment

Read the surrounding code so you understand what each comment is really asking, then handle it on its own terms:

  • A question → answer it. If the answer implies a code change, make it.
  • A suggestion or change request → make the change.
  • A concern → investigate; fix it if real, or explain why it's fine.
  • Ambiguous or you disagree → don't silently comply or silently skip. Say what you'd do and why, and ask if it's a real judgment call.

Make the changes surgically — only what each comment asks for, matching the surrounding style. Don't address adjacent code that has no rev: comment.

Step 3 — Remove the comments you've addressed

Delete each rev: comment once its point is handled, so the marker means "outstanding" and the code isn't left littered with them. Leave a rev: comment in place only if you're explicitly deferring it or waiting on the user's answer — and call out which ones you left and why.

Step 4 — Report back

Give a short per-comment rundown: what each one asked and how you handled it (changed X, answered Y, deferred Z). Keep it tight — one line per comment is usually enough.

Things not to do

  • Don't run tests, commit, or open a PR unless asked — this skill just addresses the comments.
  • Don't refactor or "improve" code that no rev: comment mentions.
  • Don't remove a rev: comment you haven't actually addressed.

04 同仓库更多 Skills

esond
esond/skills

work-item-voice

Write or edit the user's issues in their own voice, in any work tracker — Jira, Linear, GitHub Issues, Azure DevOps. Covers features (new behavior), tasks (work that needs doing), and bugs (behavior that does not match expectation). Load this whenever the deliverable is an issue body, whether they say "file a bug", "write a ticket", "draft a story", "create an issue for this", "turn this into a Jira", "write this up in Linear", or paste a thread and ask for an issue out of it. Load it too whenever text goes into an issue that already exists — "record this in the issue", "add what we found to the ticket", "note this on the card", "update the one about refunds", or naming an issue by its key and asking for a fact to go in it — and when writing or updating one is a step inside a larger task. Features get behavior-driven framing with no implementation prescribed, and bugs get expected versus actual. Not for a comment on an issue, which is a conversation turn.

★ 0
esond
esond/skills

conversational-voice

Write the user's side of a conversation with another person, in the user's own voice: Slack messages and replies, DMs, email, PR and code-review comments, Linear or Jira comments, and any other turn in an exchange that goes out under the user's name. Load this whenever the deliverable is a message a human will read as written by the user, whether they say "draft a Slack message", "reply to this", "how should I word this", "tell the team", "ask them about X", "send a note to", or just paste a thread and ask what to say back. Load it too when tightening, shortening, or sanity-checking a message they already wrote, and when a message is one step of a larger task. The register is direct and informal, the way they'd talk to a friend or acquaintance, with the answer up front for a reader who skims. Not for something the user authors rather than sends — an issue body, a PR description, a commit message — even though a person reads those too.

邮件与沟通
★ 0
esond
esond/skills

sync-core-repo-docs

Create or audit a repo's three core doc files — README.md, the agent instructions file (AGENTS.md or CLAUDE.md), and REVIEW.md — in that dependency order. If a file is missing, generate it from the codebase; if it exists, audit it against the current code and apply targeted fixes after confirmation. README.md gets a developer from clone to running the project; AGENTS.md captures coding guidance for the agent (delegating to /init or claude-md-improver); REVIEW.md holds guidance for code reviewers, human or automated, without duplicating AGENTS.md. Target files with --readme, --claude, and --review, or run all three. Use whenever the user wants to set up, bootstrap, scaffold, refresh, audit, update, or sync a repo's docs, or says things like "create a README", "is my README still accurate", "write a CLAUDE.md", "write an AGENTS.md", "audit our docs", or "get this repo ready for contributors" — even when only one file is named. Prefer it over claude-md-improver when README or REVIEW are also in scope.

开发工程师
★ 0
esond
esond/skills

sync-core-docs

Create or audit a repo's README.md, AGENTS.md/CLAUDE.md, and REVIEW.md docs.

★ 0
esond
esond/skills

righting-software-system-design

Opt-in, collaborative system-design workflow based on Juval Löwy's iDesign methodology in *Righting Software*. Conducts a multi-phase interview (framing → use cases → volatility analysis → components → call-chain validation → report) that surfaces unknown-unknowns and produces a written recommendation at `decompositions/{system-name}/report.md`. **Run only when the user explicitly invites this workflow** — not for general architecture questions, lightweight design conversations, or quick "where should X live?" questions. Valid triggers: the user names the skill directly, references *Righting Software* / Juval Löwy / iDesign / "The Method" / volatility-based decomposition and asks to run a full session, asks for a "deep" or "structured" or "Löwy-style" system design session, or accepts a prior suggestion to run it. Wait for an explicit yes before entering Phase 0. The skill is interrogative — a back-and-forth interview that challenges each volatility candidate and proposes ones the user hasn't considered.

设计师视觉设计Skill与智能体开发
★ 0
esond
esond/skills

reorganize-branch-commits

Reorganize the commits on a non-default git branch into a clean, logical history by rewriting the branch — `git reset` + re-commit by default, `git rebase -i` when commit boundaries already align. Propose groupings based on the actual work done (features, refactors, tests, fixes, docs), get explicit user approval, back the branch up, then rewrite history. Use this skill whenever the user wants to tidy up, clean up, reorganize, restructure, squash, or curate commits on a feature branch — even if they phrase it as "my branch is a mess", "squash this down", "combine these commits", "fix up the commit log before I open a PR", or "make the commits presentable for review". Trigger proactively when the user is about to open or push a PR and the branch has scrappy/WIP/"fix" commits to collapse. Refuses to operate on default or release-shaped branches (main, master, develop, trunk, production, release, or the repo default) — a feature-branch-only tool.

★ 0