菜单
Run all infrastructure standards checks and fixes. Use when onboarding a new project, doing a full compliance audit, or batch-fixing with --fix.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/laurigates/claude-plugins --skill configure-all命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Install, configure and troubleshoot MCP servers. Use when adding/enabling servers, editing .mcp.json, fixing OAuth, or when a server runs stale code after an upstream fix.
FinOps snapshot — org billing, workflow stats, cache usage. Use when you want a high-level view of CI spending or workflow health before diving deeper.
GitHub Actions billing, workflow efficiency, and waste analysis at org or repo level. Use when investigating CI/CD costs, wasted runs, or optimizing triggers.
| created | "2025-12-16T00:00:00.000Z" |
| modified | "2026-08-08T00:00:00.000Z" |
| reviewed | "2026-08-08T00:00:00.000Z" |
| description | Run all infrastructure standards checks and fixes. Use when onboarding a new project, doing a full compliance audit, or batch-fixing with --fix. |
| allowed-tools | Glob, Grep, Read, Write, Edit, Bash, AskUserQuestion, TodoWrite, SlashCommand, Agent |
| args | [--check-only] [--fix] [--type <frontend|infrastructure|python>] |
| argument-hint | [--check-only] [--fix] [--type <frontend|infrastructure|python>] |
| name | configure-all |
Run all infrastructure standards compliance checks.
| Use this skill when... | Use another approach when... |
|---|---|
| Performing comprehensive infrastructure audit | Checking single component (use specific /configure:X skill) |
| Setting up new project with all standards | Project already has all standards configured |
| CI/CD compliance validation | Need detailed status only (use /configure:status) |
| Running initial configuration | Interactive component selection needed (use /configure:select) |
Batch-fixing all compliance issues with --fix | Manual review of each component preferred |
find . -maxdepth 1 -name \'.project-standards.yaml\'find . -maxdepth 1 \( -name 'package.json' -o -name 'pyproject.toml' -o -name 'Cargo.toml' -o -name '*.tf' \)find . -maxdepth 1 -type d \( -name 'terraform' -o -name 'helm' -o -name 'argocd' \)find . -maxdepth 1 -name '.project-standards.yaml' -exec grep -m1 "^standards_version:" {} +Parse from command arguments:
--check-only: Report status without offering fixes (CI/CD mode)--fix: Apply all fixes automatically without prompting--type <type>: Override auto-detected project type (frontend, infrastructure, python)Execute this comprehensive infrastructure standards compliance check:
.project-standards.yaml if it existsterraform/, helm/, argocd/, or *.tf filespackage.json with vue/react dependenciespyproject.tomlrequirements.txt--type override if providedThe component roster lives in components.yaml — the single source of truth. Never hand-maintain a component list here; run the lister:
bash "${CLAUDE_SKILL_DIR}/scripts/list-components.sh"
Each COMPONENT=<name> DOMAIN=<domain> HAS_SCRIPT=<bool> TYPES=<types> line is
one component skill. If the lister reports STATUS=ERROR, stop and surface the
ISSUES: block — the manifest and the skills on disk have drifted.
For each listed component whose TYPES includes the detected project type
(TYPES=all always applies), invoke it in check-only mode using the
SlashCommand tool — e.g. COMPONENT=configure-tests runs:
/configure:tests --check-only
Skip components whose TYPES excludes the detected project type, and report
them as SKIP. For finer applicability judgment (e.g. Skaffold only when a
k8s/ dir exists), see REFERENCE.md.
Collect results from each check.
Step 3 is a sequential pass and stays the default. When the applicable set is
large, the same work can be split across one read-only check agent per roster
row using the bundled harness — see
## Workflow harness (template) below and
workflows/configure-all-check.workflow.js.
Take this path only when all of the following hold:
| Condition | Why |
|---|---|
| 15 or more applicable components | Below ~15, the sequential path is cheaper than 15 agent preambles. This floor is enforced in the harness, which aborts under it. |
| The run is a check, not a fix | --fix never enters the workflow — see Step 5 |
The lister returned STATUS=OK | An empty or errored roster aborts the harness; there is no fan-out width to read |
Two things the harness needs that this skill's frontmatter now grants:
Agent in allowed-tools — without it the skill cannot dispatch at all.SlashCommand in each check agent's own toolset — without it the agent
re-derives a component check from scratch instead of invoking
/configure:<component> --check-only, which is the whole point.The applicability filter is not delegated. types === 'all' || types.split(',').includes(projectType) is manifest data the lister already
emits, so no agent decides it. Finer judgements the manifest cannot express
(Skaffold only when a k8s/ dir exists — see REFERENCE.md) are
resolved here, before dispatch, and passed in as ambiguous.
The synthesis stage is a barrier: the fix plan must see every component at
once, because no single check agent can know that pre-commit and linting both
write .pre-commit-config.yaml.
Print a summary table with each component's status (PASS/WARN/FAIL), overall counts, and a list of issues to fix. For report format template, see REFERENCE.md.
If --fix flag is set or user confirms:
--fix--fix never runs inside the workflow. Several components mutate the same
files; parallel fixers would race. Apply the fixPlan sequentially.
Create or update .project-standards.yaml with the current standards version, project type, timestamp, and component versions. For template, see REFERENCE.md.
| Context | Command |
|---|---|
| Quick compliance check (all components) | /configure:all --check-only |
| Auto-fix all issues | /configure:all --fix |
| Check standards file validity | test -f .project-standards.yaml && cat .project-standards.yaml | head -10 |
| List project type indicators | find . -maxdepth 1 \( -name 'package.json' -o -name 'pyproject.toml' -o -name 'Cargo.toml' \) -exec basename {} \; |
| Count missing components | grep -c "status: missing" compliance-report.txt 2>/dev/null |
| Flag | Description |
|---|---|
--check-only | Report status without offering fixes |
--fix | Apply all fixes automatically |
--type <type> | Override project type (frontend, infrastructure, python) |
| Code | Meaning |
|---|---|
| 0 | All checks passed |
| 1 | Warnings found (non-blocking) |
| 2 | Failures found (blocking) |
A workflow returns a value, not a process status, so exitCode cannot come from
the harness. When the Step 3b path is taken, this skill maps the returned
report.overall onto the table above: PASS → 0, WARN → 1, FAIL → 2.
workflows/configure-all-check.workflow.js ships beside this skill. It is a
TEMPLATE to adapt, not a script to run verbatim. Read it, then rewrite it for
the work in front of you.
Adapt freely: the check and synthesis agent prompts, the wave width, the
ambiguous handling, the schema's optional fields, and the shape of the
fixPlan entries your project's remediation actually needs.
Preserve across any adaptation: (a) the loop bound comes from
scripts/list-components.sh's COMPONENT= rows passed in as args.roster,
never from a prose "for each component" — and the applicability filter stays the
pure types === 'all' || types.split(',').includes(projectType) expression, so
no agent classifies a manifest field; (b) CHECK_SCHEMA's closed
PASS|WARN|FAIL|ERROR status enum, plus the files array that makes contention
detectable, so a vague verdict is structurally impossible and a null return
becomes an explicit ERROR row rather than a silent pass; (c) the Synthesize
stage is a barrier — the fix plan must see every component at once, because
contention over a shared file (pre-commit and linting both write
.pre-commit-config.yaml) is invisible to any single check agent. Two
consequences of (c) that are also non-negotiable: the checks are read-only,
and --fix is applied outside the workflow, sequentially.
Skip the harness when: fewer than ~15 components are applicable, or the run
is a single-component check, or the lister reported STATUS=ERROR — that is a
linear pass and the harness is pure overhead. The steps above remain the
authoritative description of what each stage must produce; the harness only
fixes how the work is split.
This supersedes the former hardcoded four-teammate split (linting / security /
testing / CI). That table partitioned a roster it did not read, so it drifted
every time components.yaml changed; the harness derives its partition from the
lister instead.
/configure:select - Interactively select which components to configure/configure:status - Quick read-only status overview/configure:X skills are listed there, not here)