菜单
Write warm, direct collaboration comments. Trigger: PR feedback, issue replies, reviews, Slack messages, or GitHub comments.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
user mentions pending, tech-debt, TODO, pendiente, deuda técnica, or asks about pending tasks. Normalizes Engram task tracking.
Trigger: judgment day, dual review, adversarial review, juzgar. Run blind dual review, fix confirmed issues, then re-judge.
MCP navigation, code discovery, symbol lookup, trace_flow, trace_callers, endpoints. Use navigation-agent MCP before reading workspace code.
Implement SDD tasks from specs and design. Trigger: orchestrator launches apply for one or more change tasks.
Archive a completed SDD change by syncing delta specs. Trigger: orchestrator launches archive after implementation and verification.
Create the SDD technical design and architecture approach. Trigger: orchestrator launches design for a change.
| name | comment-writer |
| description | Write warm, direct collaboration comments. Trigger: PR feedback, issue replies, reviews, Slack messages, or GitHub comments. |
| license | Apache-2.0 |
| metadata | {"author":"gentleman-programming","version":"1.0"} |
Load this skill whenever you write a comment that another human will read.
Use it for:
| Rule | Requirement |
|---|---|
| Be useful fast | Start with the actionable point. Do not recap the whole PR before feedback. |
| Be warm and direct | Sound like a thoughtful teammate, not a corporate bot. |
| Keep it short | Prefer 1 to 3 short paragraphs or a tight bullet list. |
| Explain why | Give the technical reason when asking for a change. |
| Avoid pile-ons | Comment on the highest-value issue, not every tiny preference. |
| Match thread language | Write in the thread/user language. If writing in Spanish, use Rioplatense Spanish/voseo: podés, tenés, fijate, dale. |
| No em dashes | Use commas, periods, or parentheses instead. |
<Direct observation or request>
<Why it matters, only if needed>
<Concrete next action>
Buenísimo el enfoque. Acá separaría este cambio en otro commit porque mezcla la validación con el wiring de UI.
Eso le baja carga al reviewer y hace que el rollback sea más claro si falla la integración.
Está bien encaminado y el scope se entiende rápido.
Dejo aprobado. Para el próximo PR, agregá el link al anterior y al siguiente así la cadena queda navegable.
Este PR supera el presupuesto de 400 líneas cambiadas, así que necesitamos dividirlo o justificar `size:exception`.
Mi sugerencia: primero foundation + tests, después integración, después docs. Así cada review tiene inicio y fin claros.
# Inspect a PR before writing review feedback
gh pr view <PR_NUMBER> --json title,body,additions,deletions,changedFiles