القائمة
Use when creating, editing, triaging, or cleaning up GitHub issues - a mechanical pass that verifies the title is accurate and current, labels/assignees/milestone are correct, and the body is valid, well-formed markdown, all via the gh CLI. Does not judge content quality.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | issue-hygiene |
| description | Use when creating, editing, triaging, or cleaning up GitHub issues - a mechanical pass that verifies the title is accurate and current, labels/assignees/milestone are correct, and the body is valid, well-formed markdown, all via the gh CLI. Does not judge content quality. |
A mechanical hygiene pass over a GitHub issue: correct title, correct
labels and metadata, valid markdown body. This is the lint layer - it does
NOT judge whether the issue is well-reasoned or complete (that is
authoring-issues). Run it after drafting an issue, or when asked to tidy
or triage existing ones.
All edits go through the gh CLI. Verify current state before changing
anything, and change only what is wrong (minimal edits).
authoring-issues produces a draft.Title
area:,
[component]) - check sibling issues first; do not invent one.Labels and metadata
gh label list. NEVER apply a label
that does not exist unless explicitly asked to create one.Closes #N, Refs #N. Mark duplicates.Body markdown
- [ ] / - [x]); tables have
aligned header separators.#issue / @user references resolve.gh issue view <n> --json title,body,labels,assignees,milestone
gh label list # real labels before tagging
gh issue edit <n> --title "..." \
--add-label bug --add-label "area:api" \
--milestone "v1.2"
gh issue create --title "..." --body-file draft.md --label bug
Render-check the body (gh issue view <n> --web, or preview the markdown)
before declaring done.
authoring-issues,
not hygiene.Use when reviewing a completed implementation holistically - a finished branch, a completed plan step, or a diff before PR. Reviews every changed line against the implementation plan (if one exists) and high engineering standards across seven dimensions, verifies tests by deliberately breaking crucial code, and emits severity-classified findings with a PASS/FAIL verdict.
Use when performing a holistic code review of an implementation - routes to codex:rescue or falls back to a direct subagent, both running the house-style:holistic-review skill
ALWAYS use before any implementation work, review, or planning: designing, writing, editing, refactoring, debugging, reviewing, or generating source code, tests, scripts, config-as-code, or behavior-affecting files. This is a baseline engineering skill and should be invoked even when a more specific language, framework, testing, or database skill also applies.
Use when asked to write, draft, file, or open a GitHub issue - mandates exploring the relevant code to understand the whole problem space, reasoning any proposed solution, and structuring the issue with summary, what/why, references, nuances, open questions, and acceptance criteria. Adds professionalism and no-sensitive-info discipline for public repos.
Use when running Python, installing Python packages, creating virtualenvs, or executing Python CLI tools - mandates uv/uvx over direct python/pip/pipx/venv calls when uv is installed, and gives the drop-in command mappings
Use when the user provides a reference implementation (URL, repo path, branch, file) plus a verb like "use", "copy", "adapt", "port", "model after" - mandates fetching/reading the reference before designing, and lifting the structure rather than reimagining it.