Menu
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.
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.
Basé sur la classification professionnelle SOC
| name | unic-create-issues |
| description | 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. |
Create GitHub issues for planned unic work that does not already have issue
coverage.
PLAN.md to identify planned milestones and unimplemented work.gh issue list --state all --limit 100.gh issue view <number>
before deciding a PLAN item is uncovered.gh issue create.feat: <description> (M<X>.<Y>)enhancementReport the created issues with URLs and note any PLAN items you intentionally left alone because matching issues already existed.
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.
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.
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.
Use when the user asks to implement refactors from a prior unic senior review report. Do not use for new features or behavior changes.
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.
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.