Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
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.
Step 3: Run all checks
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 3b: Heavy path — parallel check fan-out (optional)
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.
Step 4: Generate compliance report
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.
Step 5: Apply fixes (if requested)
If --fix flag is set or user confirms:
Run each failing configure command with --fix
Report what was fixed and what requires manual intervention
--fix never runs inside the workflow. Several components mutate the same
files; parallel fixers would race. Apply the fixPlan sequentially.
Step 6: Update standards tracking
Create or update .project-standards.yaml with the current standards version, project type, timestamp, and component versions. For template, see REFERENCE.md.
Agentic Optimizations
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
Override project type (frontend, infrastructure, python)
Exit Codes (for CI)
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.
Workflow harness (template)
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.
See Also
/configure:select - Interactively select which components to configure
/configure:status - Quick read-only status overview
components.yaml - The authoritative component roster (per-component /configure:X skills are listed there, not here)
