S Skillteca
Receber por email
Explorar Categorias Coleções Newsletter
← Voltar para o catálogo

receiving-code-review

Design e Frontend Autor: adriannoes

Use when receiving code review feedback, before implementing suggestions — requires technical rigor and verification, not performative agreement

39estrelas
Atualizado há 4 meses
Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add adriannoes/awesome-vibe-coding

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/receiving-code-review-adriannoes/svg)](https://www.skillteca.com.br/skills/receiving-code-review-adriannoes)
#ai

Skills relacionadas

Ver todas de Design e Frontend →

frontend-design

153.1k 2

Cria interfaces frontend distintas e de nível de produção com alta qualidade de design, gerando código criativo e polido e design de UI que evita a estética genérica de IA. Use para construir componentes web, páginas e aplicações, ou para estilizar/embelezar UIs web.

Design e Frontend #ai #css por anthropics

mcp-builder

153.1k

Guia para criar servidores MCP (Model Context Protocol) de alta qualidade que permitem que LLMs interajam com serviços externos por meio de ferramentas bem projetadas. Use ao construir servidores MCP para integrar APIs ou serviços externos, seja em Python (FastMCP) ou Node/TypeScript (MCP SDK).

Design e Frontend #api #llm por anthropics

webapp-testing

153.1k

Kit de ferramentas para interagir e testar aplicações web locais usando Playwright. Suporta a verificação de funcionalidades de frontend, depuração de comportamento da UI, captura de screenshots do navegador e visualização de logs do navegador.

Design e Frontend #test por anthropics

web-artifacts-builder

153.1k

Conjunto de ferramentas para criar artefatos HTML elaborados e multi-componentes para claude.ai, utilizando tecnologias web frontend modernas (React, Tailwind CSS, shadcn/ui). Use para artefatos complexos que exigem gerenciamento de estado, roteamento ou componentes shadcn/ui, não para artefatos HTML/JSX simples de arquivo único.

Design e Frontend #ai #css por anthropics

Alerta por categoria

Receba novas skills de Design e Frontend toda segunda

1 email curto, só com as skills novas de Design e Frontend. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Receiving Code Review

Source: obra/superpowers (MIT)

Overview

Code review requires technical evaluation, not emotional performance.

Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort.

The Response Pattern

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask)
3. VERIFY: Check against codebase reality
4. EVALUATE: Technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each

Forbidden Responses

NEVER:

  • "You're absolutely right!"
  • "Great point!" / "Excellent feedback!"
  • "Let me implement that now" (before verification)

INSTEAD:

  • Restate the technical requirement
  • Ask clarifying questions
  • Push back with technical reasoning if wrong
  • Just start working (actions > words)

Handling Unclear Feedback

IF any item is unclear:
  STOP - do not implement anything yet
  ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

Implementation Order

FOR multi-item feedback:
  1. Clarify anything unclear FIRST
  2. Then implement: blocking issues → simple fixes → complex fixes
  3. Test each fix individually
  4. Verify no regressions

When To Push Back

  • Suggestion breaks existing functionality
  • Reviewer lacks full context
  • Violates YAGNI (unused feature)
  • Technically incorrect for this stack
  • Conflicts with architectural decisions

How to push back: Use technical reasoning, not defensiveness. Reference working tests/code.

Acknowledging Correct Feedback

When feedback IS correct:

✅ "Fixed. [Brief description of what changed]"
✅ "Good catch — [specific issue]. Fixed in [location]."
✅ [Just fix it and show in the code]

❌ "You're absolutely right!"
❌ "Thanks for catching that!"

Why no thanks: Actions speak. Just fix it.

The Bottom Line

External feedback = suggestions to evaluate, not orders to follow.

Verify. Question. Then implement. No performative agreement. Technical rigor always.

Compartilhar X LinkedIn