unic-refactor-review

Étoiles14

Forks1

Mis à jour26 avril 2026 à 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.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

DevopsArtFactory

DevopsArtFactory/unic

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

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.

Plus depuis ce dépôt

même dépôt

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.