원클릭으로 Manus에서 모든 스킬 실행

code-review-guidelines

스타1

포크0

업데이트2026년 2월 17일 16:36

Code review best practices including review checklist, comment types, severity levels, feedback patterns, and PR size guidelines. Auto-loaded during code review.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

hypeJunction

hypeJunction/ai-assistant-starter

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Code Review Guidelines

Core Principles

Be constructive — Focus on improvement, not criticism
Be specific — Point to exact lines, suggest alternatives
Be thorough — Check functionality, readability, security
Be collaborative — Discussion, not gatekeeping

Review Checklist

Functionality

Does the code do what it's supposed to do?
Are edge cases handled?
Are error conditions handled gracefully?
Does it break existing functionality?

Code Quality

Is the code readable and self-documenting?
Are names descriptive?
Is there unnecessary duplication?
Does it follow project patterns?

Security

Is user input validated?
Any SQL injection / XSS vulnerabilities?
Are secrets properly handled?
Are permissions checked?

Testing

Sufficient test coverage?
Tests cover edge cases?
Tests are readable and maintainable?

Performance

Any obvious performance issues?
Efficient database queries?
Memory leaks?

Comment Labels

Label	Meaning	Blocks PR?
`[blocking]`	Must address before merge	Yes
`[suggestion]`	Recommended improvement	No
`[nit]`	Minor style issue	No
`[question]`	Seeking clarification	No
`[praise]`	Positive feedback	No

Giving Feedback

Be specific:

**[suggestion]** The variable `d` on line 45 is unclear. Consider
renaming to `dateOfBirth` to indicate what date this represents.

Explain why:

**[blocking]** Using `any` here defeats type safety. This function
receives user input, so we need proper types.

Suggest alternatives:

**[suggestion]** This loop is O(n²). Consider using a Map for O(n).

Give praise:

**[praise]** Great implementation of retry logic with exponential backoff.

PR Size Guidelines

Lines Changed	Assessment
< 100	Excellent
100-400	Good
400-800	Consider splitting
> 800	Should split

Anti-Patterns to Avoid

Rubber-stamping — Approving without reading
Nitpicking — Blocking on minor style issues
Bikeshedding — Debating trivial naming choices
Personal attacks — Criticizing the person, not the code

이 저장소의 다른 Skills

같은 저장소

finish

hypeJunction/ai-assistant-starter

End-of-session routine. Ensures test coverage, performs self-review, runs validation, and commits cleanly. Use when finishing a unit of work.

2026-03-161

implement

hypeJunction/ai-assistant-starter

Full feature implementation workflow with explore, plan, code, test, validate, and commit phases. Use for new features, enhancements, or significant code changes.

2026-03-161

iterate-pr

hypeJunction/ai-assistant-starter

Iterate on an open PR until CI passes and all review feedback is addressed. Fetches status, categorizes findings by severity, applies fixes, and loops until clean.

2026-03-161

plan

hypeJunction/ai-assistant-starter

Create a detailed implementation plan without writing code. Read-only analysis and planning with user approval gate. Use before implementing features or making significant changes.

2026-03-161

security-review

hypeJunction/ai-assistant-starter

Systematic security audit with confidence-based reporting. Analyzes attack surfaces, checks against OWASP categories, and reports only confirmed or likely vulnerabilities. Use for pre-merge security review or periodic audits.

2026-03-161

validate

hypeJunction/ai-assistant-starter

Run validation checks to ensure code quality, security, and correctness. Supports quick (scoped), full (CI pipeline), fix (auto-correct), and CI mirror modes.

2026-03-161

name	code-review-guidelines
description	Code review best practices including review checklist, comment types, severity levels, feedback patterns, and PR size guidelines. Auto-loaded during code review.
category	protocol
user-invocable	false

Code Review Guidelines

Core Principles

Be constructive — Focus on improvement, not criticism
Be specific — Point to exact lines, suggest alternatives
Be thorough — Check functionality, readability, security
Be collaborative — Discussion, not gatekeeping

Review Checklist

Functionality

Does the code do what it's supposed to do?
Are edge cases handled?
Are error conditions handled gracefully?
Does it break existing functionality?

Code Quality

Is the code readable and self-documenting?
Are names descriptive?
Is there unnecessary duplication?
Does it follow project patterns?

Security

Is user input validated?
Any SQL injection / XSS vulnerabilities?
Are secrets properly handled?
Are permissions checked?

Testing

Sufficient test coverage?
Tests cover edge cases?
Tests are readable and maintainable?

Performance

Any obvious performance issues?
Efficient database queries?
Memory leaks?

Comment Labels

Label	Meaning	Blocks PR?
`[blocking]`	Must address before merge	Yes
`[suggestion]`	Recommended improvement	No
`[nit]`	Minor style issue	No
`[question]`	Seeking clarification	No
`[praise]`	Positive feedback	No

Giving Feedback

Be specific:

**[suggestion]** The variable `d` on line 45 is unclear. Consider
renaming to `dateOfBirth` to indicate what date this represents.

Explain why:

**[blocking]** Using `any` here defeats type safety. This function
receives user input, so we need proper types.

Suggest alternatives:

**[suggestion]** This loop is O(n²). Consider using a Map for O(n).

Give praise:

**[praise]** Great implementation of retry logic with exponential backoff.

PR Size Guidelines

Lines Changed	Assessment
< 100	Excellent
100-400	Good
400-800	Consider splitting
> 800	Should split

Anti-Patterns to Avoid

Rubber-stamping — Approving without reading
Nitpicking — Blocking on minor style issues
Bikeshedding — Debating trivial naming choices
Personal attacks — Criticizing the person, not the code