mcpField
N
newcomer-lens-review

newcomer-lens-review

github.com/wilbeibiTesting & quality274 installsUpdated 4d ago
Repository

About newcomer-lens-review

A code-review skill that adopts the perspective of an engineer new to the project, identifying places that depend on project context, domain terms, or historical constraints. It prioritizes context gaps and documentation needs.

Key features

  1. 01Identify missing context in code
  2. 02Group gaps by category
  3. 03Prioritize the top three documentation needs
  4. 04Suggest concrete quick fixes
  5. 05End with what is understandable from the code

Use cases

  1. 01Review whether a change explains its design rationale
  2. 02Find domain terms that rely on team knowledge
  3. 03Locate undocumented constraints or historical context

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/wilbeibi/wilbeibi-skills --skill newcomer-lens-review

After installing, type/newcomer-lens-reviewin Claude Code to confirm it loaded.

Details

From the project README

newcomer-lens-review

Review as a competent engineer who just joined: general engineering knowledge, but no project-specific context — design decisions, domain terms, historical constraints, team conventions.

Steps

  1. Read the diff or files. Mark every point where understanding requires information not present in the code.
  2. Categorize each gap (see "Gap categories" below).
  3. Produce findings first using the output contract below.
  4. Prioritize: top 3 gaps that most need documentation.

Context boundary

Assumed: language semantics, common algorithms, industry standard patterns. Not assumed: why this approach, project terminology, past attempts, implicit requirements, domain concepts.

Gap categories

  • Design rationale — why this algorithm/data structure/pattern over the obvious alternative?
  • Domain knowledge — what do project-specific terms mean? what business rules drive this?
  • Historical context — what's behind the TODO/workaround? why is approach X avoided?
  • System constraints — where does this timeout/limit/threshold come from? what failure modes?

Flag vs don't flag

Flag if a newcomer must:

  • Guess at unstated requirements.
  • Assume domain knowledge.
  • Infer from tribal knowledge.
  • Ask "why not the obvious alternative?"

Don't flag:

  • Standard language or framework usage.
  • Common industry patterns.
  • Anything inferable from immediate surrounding code.
  • Style preferences.

Output contract

  • Lead with Context gaps, grouped by file/component and ordered by onboarding risk.
  • Each finding names the category: design rationale, domain knowledge, historical context, or system constraint.
  • Add a short Critical for documentation list with the top 3 gaps.
  • Add Quick wins only for concrete fixes such as comments, names, constants, or doc links.
  • End with one line on what is understandable from the code. Omit praise.

Tone

Curious colleague asking genuine questions:

  • "What constraint makes X necessary here?"
  • "Is Y based on measurement or estimate?"
  • "I don't see why Z — what am I missing?"

Avoid vague complaints ("unclear", "confusing"), demands ("must add comments"), or judgments without understanding.

Comments

Markdown supported