一键导入
allium-cli-ci-and-quality-gates
Use when defining or applying CI-quality command gates for a folder of .allium specs. Assumes allium is already available.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when defining or applying CI-quality command gates for a folder of .allium specs. Assumes allium is already available.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use for practical command recipes when agents operate Allium CLI commands on a folder of .allium specs.
Use when running deeper semantic and process-level analysis on a folder of .allium specs after allium check has passed.
Use when validating a folder of .allium specs with allium check. Resolves the folder to an entrypoint file, runs validation, interprets diagnostics, and defines the repair loop.
Use as a concise reference for Allium CLI commands when working on a folder of .allium specs. Assumes the CLI is already available and entrypoint resolution is required.
Use when an Allium CLI command fails on a folder of .allium specs. Classifies diagnostics, performs minimal repairs, and reruns the correct command against the resolved entrypoint.
Use when extracting or inspecting the structured domain model from a folder of .allium specs using allium model.
| name | allium-cli-ci-and-quality-gates |
| description | Use when defining or applying CI-quality command gates for a folder of .allium specs. Assumes allium is already available. |
Use this skill when the user wants automated quality gates, pre-merge checks, or repeatable validation commands for a folder of .allium specs.
Define reliable folder-level CLI gates that resolve an entrypoint file and run the appropriate Allium commands without performing installation or environment setup.
This skill is invoked against a folder containing one or more .allium files. Do not pass the folder itself to allium commands. Allium CLI commands operate on spec files, so first resolve the effective entrypoint file.
Treat the user's folder argument as SPEC_DIR. If no folder is provided, use the current working directory only after confirming it contains .allium files.
SPEC_DIR="${SPEC_DIR:-.}"
find "$SPEC_DIR" -type f -name '*.allium' | sort
If no .allium files are found, stop and report that the folder does not contain Allium specs.
Use this order:
SPEC_DIR/index.allium exists, use it.SPEC_DIR/allium/index.allium exists, use it..allium file exists under SPEC_DIR, use that file..allium files exist and no clear entrypoint exists, inspect imports/references and choose the file that appears to aggregate the others.Use ENTRYPOINT for commands that need the whole model. Use a leaf file only for narrow syntax debugging with allium parse, and return to the entrypoint for validation.
ENTRYPOINT="$SPEC_DIR/index.allium"
allium check "$ENTRYPOINT"
allium check "$SPEC_DIR"
allium analyse "$SPEC_DIR"
allium model "$SPEC_DIR"
allium plan "$SPEC_DIR"
Passing a directory produces misleading failures and does not validate the spec set.
Every spec folder that has a stable entrypoint should pass:
allium check "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
This is the minimum pre-merge gate for spec changes.
Use these when the project wants artifacts for review, documentation, or test planning:
mkdir -p artifacts
allium model "$ENTRYPOINT" > artifacts/allium-model.json
allium plan "$ENTRYPOINT" > artifacts/allium-test-plan.txt
These should not replace check and analyse.
Use for fast feedback on every spec edit.
allium check "$ENTRYPOINT"
Use before PRs or implementation from specs.
allium check "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
Use before generating tests or implementation plans.
allium check "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
allium plan "$ENTRYPOINT"
Use when CI should preserve domain model and test-obligation outputs.
mkdir -p artifacts
allium check "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
allium model "$ENTRYPOINT" > artifacts/allium-model.json
allium plan "$ENTRYPOINT" > artifacts/allium-test-plan.txt
If a repository has multiple independent spec folders or bounded contexts, run gates per entrypoint.
Example:
for ENTRYPOINT in specs/allium/*/index.allium; do
echo "Checking $ENTRYPOINT"
allium check "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
done
Do not assume one root entrypoint unless the repository convention says so.
Quality gates should stop at the first failed prerequisite.
Correct order:
allium check "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
allium plan "$ENTRYPOINT"
Incorrect order:
allium plan "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
allium check "$ENTRYPOINT"
Use this as a repository script body when asked to create or review a gate. Adjust paths to repo conventions.
#!/usr/bin/env bash
set -euo pipefail
SPEC_DIR="${1:-specs/allium}"
if [[ -f "$SPEC_DIR/index.allium" ]]; then
ENTRYPOINT="$SPEC_DIR/index.allium"
elif [[ -f "$SPEC_DIR/allium/index.allium" ]]; then
ENTRYPOINT="$SPEC_DIR/allium/index.allium"
else
mapfile -t SPECS < <(find "$SPEC_DIR" -type f -name '*.allium' | sort)
if [[ "${#SPECS[@]}" -eq 1 ]]; then
ENTRYPOINT="${SPECS[0]}"
else
echo "Could not resolve a unique Allium entrypoint under $SPEC_DIR" >&2
printf '%s
' "${SPECS[@]}" >&2
exit 2
fi
fi
echo "Allium spec folder: $SPEC_DIR"
echo "Allium entrypoint: $ENTRYPOINT"
allium check "$ENTRYPOINT"
allium analyse "$ENTRYPOINT"
For CI logs:
specs/allium/ instead of specs/allium/index.allium.plan even when analyse failed.Before accepting a CI gate, verify:
check runs before analyse.analyse runs before plan.When reporting command results, include:
Do not claim a spec is valid unless the relevant command completed successfully against the resolved entrypoint.
allium-cli-project-conventions for repo-specific paths.allium-cli-agent-runbooks for manual command equivalents.allium-cli-output-interpretation for CI result summaries.