receiving-code-review

Estrelas2

Forks1

Atualizado6 de junho de 2026 às 14:31

Use when acting on code-review feedback, especially when a comment seems unclear or wrong. Requires verifying each point technically before changing anything, so you fix real issues and push back on mistaken ones instead of agreeing performatively.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

sarmakska

sarmakska/slipstream

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	receiving-code-review
description	Use when acting on code-review feedback, especially when a comment seems unclear or wrong. Requires verifying each point technically before changing anything, so you fix real issues and push back on mistaken ones instead of agreeing performatively.
slipstream	{"category":"context","requires":[],"tags":["review","quality","rigour"]}

Overview

Review feedback is input, not instruction. Acting on every comment without thought ships the reviewer's mistakes alongside your own and trains you to stop thinking. This skill keeps the bar high: treat each comment as a claim to verify, fix what is genuinely wrong, and disagree with reasons where the comment is mistaken. Agreement should be earned, not reflexive.

Steps

Read each comment as a claim, not a command. Restate what it is actually asserting.
Verify it against the code. Reproduce the concern, read the relevant lines, or write a quick test. Decide whether it is right, partly right, or wrong.
For valid points, fix the underlying issue, not just the symptom the reviewer happened to spot. Re-run the checks after each fix.
For mistaken points, reply with the specific reason and evidence rather than silently complying or silently ignoring. A correct disagreement is a service to the reviewer.
When uncertain, ask a sharpening question rather than guessing at intent. Resolve the ambiguity before editing.

Verify

Every comment is resolved with either a fix backed by a passing check or a reasoned reply. No change was made purely to look agreeable, and the suite is green after the fixes.

Mais deste repositório

mesmo repositório

dispatching-parallel-agents

sarmakska/slipstream

Use when several pieces of work are genuinely independent and can run at once, to fan them out across parallel agents instead of doing them in sequence. Cuts wall-clock time and keeps each strand in its own clean context.

2026-06-172

executing-plans

sarmakska/slipstream

Use when a written plan exists and you are about to build it in the current session, to work it task by task with a checkpoint after each. Keeps execution honest against the plan instead of drifting into a freehand build.

2026-06-172

using-git-worktrees

sarmakska/slipstream

Use when work needs its own isolated checkout — parallel strands that would fight over files, or a risky change you want quarantined from the main tree. Gives each strand a real working directory on its own branch without re-cloning.

2026-06-172

using-slipstream

sarmakska/slipstream

Use whenever the user says "use slipstream", "use superpowers", or starts any task in a project that has slipstream. A hard, always-on discipline that forces scoped reads over whole-file reads to save tokens, recalls memory before acting, and records what is durable every turn so memory grows constantly.

2026-06-062

frontend-design-system

sarmakska/slipstream

Use when a site needs to look designed rather than defaulted, before building sections: establish a cohesive design system of type scale, spacing, colour, radius and shadow tokens so every component shares one premium visual language.

2026-06-062

frontend-hero-section

sarmakska/slipstream

Use when building the top of a landing page, to produce a high-impact hero with confident display type, a clear single call to action and balanced composition, the kind of opening a polished marketing site leads with.

2026-06-062

name	receiving-code-review
description	Use when acting on code-review feedback, especially when a comment seems unclear or wrong. Requires verifying each point technically before changing anything, so you fix real issues and push back on mistaken ones instead of agreeing performatively.
slipstream	{"category":"context","requires":[],"tags":["review","quality","rigour"]}

Overview

Steps

Read each comment as a claim, not a command. Restate what it is actually asserting.
Verify it against the code. Reproduce the concern, read the relevant lines, or write a quick test. Decide whether it is right, partly right, or wrong.
For valid points, fix the underlying issue, not just the symptom the reviewer happened to spot. Re-run the checks after each fix.
For mistaken points, reply with the specific reason and evidence rather than silently complying or silently ignoring. A correct disagreement is a service to the reviewer.
When uncertain, ask a sharpening question rather than guessing at intent. Resolve the ambiguity before editing.

Verify

Every comment is resolved with either a fix backed by a passing check or a reasoned reply. No change was made purely to look agreeable, and the suite is green after the fixes.