메뉴
Discover and run the project's local formatting, linting, static analysis, test, and build checks before handoff.
Create, update, or review Agent Skill directories and SKILL.md files for valid frontmatter, structure, portability, progressive disclosure, and validation readiness.
Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
Update project-facing documentation after a user-visible behavior, configuration, operation, or workflow change.
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Add logs, metrics, traces, profiling, or operational notes for meaningful workflows without unsupported performance claims.
Design stable APIs, module contracts, schemas, component boundaries, command interfaces, or other public integration surfaces that are predictable, documented, and hard to misuse.
| name | run-local-quality-gate |
| description | Discover and run the project's local formatting, linting, static analysis, test, and build checks before handoff. |
| metadata | {"version":"1.1.0"} |
Use this skill when work is ready for validation or when the user asks to run the project's local quality checks. Discover and use the commands already defined by the project rather than inventing a new toolchain.
Inspect the repository for documented or configured checks, such as:
Prefer documented aggregate commands when they exist.
Use a sequence that gives fast feedback and avoids hiding failures. A typical order is:
If a project documents a different required order, follow the project order. Prefer non-interactive commands and avoid flags that would open pagers, watchers, editors, or prompts unless the user explicitly requests an interactive workflow.
Only run auto-fix commands that are established in the project. After auto-fixes, inspect the resulting changes and ensure they are related to the task. Do not run broad cleanup commands when a narrower project-approved command validates the touched area.
Do not use ad hoc flags to bypass the project's configured rules in the final validation run.
When a step fails:
If a failure is unrelated or cannot be fixed within scope, report it clearly with the command and relevant output.
Before handoff, run the broadest practical project-approved quality gate. If the full gate is expensive or unavailable, run the strongest available subset and state the limitation.
Record the commands that passed, failed, or were skipped. Include enough detail for the next maintainer to reproduce the result.
