unic-refactor-review

스타14

포크1

업데이트2026년 4월 26일 02:36

Use when the user asks to implement refactors from a prior unic senior review report. Do not use for new features or behavior changes.

설치

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

출처

DevopsArtFactory

DevopsArtFactory/unic

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

다운로드

Workflow

Start from an isolated main-based worktree.

Before editing anything, fetch or verify the intended main base.
Create a fresh git worktree with a new task branch from main or origin/main.
Do not refactor in the primary checkout or on a pre-existing feature branch.
Use one worktree per review finding, issue, or PR-sized refactor.

Load the latest review report.

Prefer .agents/reports/senior-review-*.md.
Fall back to .claude/reports/senior-review-*.md.
If no report exists, tell the user to run unic-senior-review first.

Select scope.

If the user named a priority or finding, scope the work to that item.
If the user named a GitHub issue, read it with gh issue view <number>.
When GitHub access is available, search open issues with gh issue list --state open --search '<terms>' to see whether the finding is already tracked before choosing scope.
If not, summarize the report priorities and ask which one to tackle.

Plan before editing.

Read every file referenced by the selected findings.
Preserve behavior; this is refactor-only work.
Do not change public APIs unless the finding specifically requires it.
If the change would touch more than 10 files, split it into smaller steps.

Implement and validate incrementally.

Make focused changes.
Run make test after each logical refactor group when practical.
Run make test and make build at the end.

Update the report when appropriate.

Mark completed findings or note what changed.
If the work maps to an issue, note the issue number in the report update.
If a recommendation from the report turns out to be impractical, explain why instead of forcing the refactor.

Constraints

No new features.
No intentional behavior changes.
Note newly discovered issues, but leave them for a future review cycle.

이 저장소의 다른 Skills

같은 저장소

unic-ux-review

DevopsArtFactory/unic

Use when the user asks to run unic locally, capture TUI screenshots, review the Bubble Tea UX, suggest UX improvements, or optionally implement scoped UX polish in the unic repository. This skill is for terminal UI review and safe UX iteration, not for unrelated feature work, dependency updates, PR shipping, or non-UX code review.

2026-06-1814

unic-update-dependencies

DevopsArtFactory/unic

Use when the user asks to update, bump, refresh, audit, or modernize dependencies, libraries, Go modules, the Go language version, or Go toolchain support in the unic repository. Use for dependency maintenance PRs, safe patch/minor Go module updates, Go version bumps, vulnerability-driven dependency updates, or CI/doc updates tied to dependency or Go version changes. Do not use for unrelated feature work, docs-only edits, or CI refactors unless they are required by the dependency/toolchain update.

2026-06-1814

unic-implement-feature

DevopsArtFactory/unic

Use when the user asks to implement a feature, milestone item, or GitHub issue in the unic repository, especially new AWS service work. Do not use for pure refactors, docs-only updates, PR shipping, or issue triage.

2026-04-2614

unic-ship-pr

DevopsArtFactory/unic

Use when the user explicitly asks to stage, commit, push, and open a pull request for unic. Do not use for general coding work or docs-only sync unless the user is asking to ship the current branch.

2026-04-2614

unic-create-issues

DevopsArtFactory/unic

Use when the user asks to create GitHub issues from planned but unimplemented unic work in PLAN.md. Do not use for editing existing issues or for implementation.

2026-04-0914

unic-senior-review

DevopsArtFactory/unic

Use when the user wants a deep maintainability or refactoring review of the unic codebase, including file-size analysis, Go idioms, and concrete refactoring priorities. Do not use for normal bug reviews or feature implementation.

2026-04-0914

name	unic-refactor-review
description	Use when the user asks to implement refactors from a prior unic senior review report. Do not use for new features or behavior changes.

Refactor unic based on an existing senior review report while preserving behavior.

Workflow

Start from an isolated main-based worktree.

Before editing anything, fetch or verify the intended main base.
Create a fresh git worktree with a new task branch from main or origin/main.
Do not refactor in the primary checkout or on a pre-existing feature branch.
Use one worktree per review finding, issue, or PR-sized refactor.

Load the latest review report.

Prefer .agents/reports/senior-review-*.md.
Fall back to .claude/reports/senior-review-*.md.
If no report exists, tell the user to run unic-senior-review first.

Select scope.

If the user named a priority or finding, scope the work to that item.
If the user named a GitHub issue, read it with gh issue view <number>.
When GitHub access is available, search open issues with gh issue list --state open --search '<terms>' to see whether the finding is already tracked before choosing scope.
If not, summarize the report priorities and ask which one to tackle.

Plan before editing.

Read every file referenced by the selected findings.
Preserve behavior; this is refactor-only work.
Do not change public APIs unless the finding specifically requires it.
If the change would touch more than 10 files, split it into smaller steps.

Implement and validate incrementally.

Make focused changes.
Run make test after each logical refactor group when practical.
Run make test and make build at the end.

Update the report when appropriate.

Mark completed findings or note what changed.
If the work maps to an issue, note the issue number in the report update.
If a recommendation from the report turns out to be impractical, explain why instead of forcing the refactor.

Constraints

No new features.
No intentional behavior changes.
Note newly discovered issues, but leave them for a future review cycle.