القائمة
Quality-check repository GitHub issues and issue comments. Use when creating, updating, reviewing, or validating issue titles, bodies, replies, or thread notes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create, align, or review production-quality Python Flet applications across package and module architecture, presentation state, Flet controls, async lifecycle, persistence and I/O boundaries, uv dependency management, Ruff, strict mypy, pytest, 100% branch and statement coverage, GitHub Actions, Flet packaging, security, and developer documentation. Use for new Flet projects, large UI refactors, quality-baseline adoption, CI setup, release readiness, or reviews of pyproject.toml, uv.lock, src/tests layout, and Flet application code. Pair with software-documentation-maintenance for document ownership and with security-check for dependencies, secrets, and CI supply chain decisions.
Select a reviewed APM CLI version, then set up, pin, deploy, audit, and update APM-managed agent dependencies safely. Use when creating or editing apm.yml or apm.lock.yaml, choosing or installing APM, adding an Agent Skill, plugin, or MCP dependency, validating a pinned deployment, or preparing a cooldown-aware update proposal.
Review or create a BepInEx Mono mod for C# project and module structure, plugin identity, game compatibility, dependency boundaries, GitHub CI and release automation, packaging, release metadata, and verification. Use when implementing, reviewing, preparing a release for, or diagnosing quality gaps in a BepInEx 5 Mono plugin or its build and release workflow.
Maintain a canonical developer changelog and versioned release history. Use when adding or correcting Keep a Changelog entries, prerelease history, compatibility context, or release-source material; not for user-facing release notes or publishing.
Review or draft repository commit messages for Conventional Commits format, accurate change summaries, breaking-change footers, and required attribution trailers. Use before creating, amending, or validating a commit.
Set up and use an isolated Git worktree for repository implementation tasks. Use unless the user explicitly requests another workspace arrangement.
| name | issue-quality-check |
| description | Quality-check repository GitHub issues and issue comments. Use when creating, updating, reviewing, or validating issue titles, bodies, replies, or thread notes. |
> [!WARNING]
> This issue was created with assistance from LLMs.
Use this comment alert instead for replies:
> [!WARNING]
> This comment was created with assistance from LLMs.
Omit an alert only when assistance was not significant.
Summary, Details, Acceptance Criteria, Verification, Notes, Findings, or Next Steps. For bugs, state expected and actual behavior and known useful reproduction steps. Cross-link durable follow-up origin context when it helps triage.prose-quality-check for nuanced explanatory prose and security-check for security- or supply-chain-sensitive content.Add Update Note or Discussion Note only when the task requests process or decision notes. Place Request addressed: ... after the required alert and before the note heading; label inferences, avoid secrets and private paths, and keep normal replies direct.
When using gh, write Markdown to a temporary file and pass --body-file; use confirmed identifiers or placeholders such as <issue-number>. Verify stored issue bodies with gh issue view --json body and stored replies when possible, correct quoting, then remove temporary files.