一键在 Manus 中运行任何 Skill

validate-ci

星标19

分支6

更新时间2026年6月9日 21:43

Validate CI locally with `hm run` before pushing. Use when a feature is complete and ready to push, when the user asks to make CI green, or before creating a PR. Do NOT use in the middle of active development or on every commit in a multi-commit feature.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

harmont-dev

harmont-dev/harmont-cli

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

When to use

The user asks you to "make CI green", "run CI", "validate the pipeline", or similar
A feature or bugfix is complete and ready to push
Before creating a pull request
The user explicitly requests local validation before pushing

When NOT to use

In the middle of active development across multiple commits — wait until the logical unit of work is done
On every individual commit in a multi-commit feature — run once at the end
When the user only asks you to commit (committing does not imply CI validation)
When the user explicitly says to skip local validation

What this does

hm run executes the project's CI pipeline locally inside Docker containers. It runs the same steps that would run on Harmont Cloud, but on your machine. This catches failures before they reach remote CI.

Procedure

Run hm run -k --logs from the project root (-k continues past failures so you see every broken step in one run; --logs streams full build logs for easier diagnosis)
If it exits 0 — pipeline passed. Inform the user and proceed with push if requested.
If it exits non-zero — pipeline failed. Read the output, diagnose ALL failures (not just the first), fix every issue, and re-run hm run -k --logs until it passes.
Only after local CI is green: push to remote. If the user wants cloud validation too, they can run hm run --backend cloud --logs or wait for the remote CI triggered by the push.

Important

hm run is the ONLY correct way to run this project's CI locally. Do NOT try to reverse-engineer pipeline steps by reading .hm/ files and running commands manually.
Do NOT commit, push, and wait for remote CI results as a way to "test" — always validate locally first.
Exit code 0 = pass, non-zero = fail. Exit code 130 = user cancelled (Ctrl-C).
If Docker is not running, hm run will fail. Tell the user to start Docker.

同仓库更多 Skills

同仓库

writing-interface-docblocks

harmont-dev/harmont-cli

Use when writing or editing any docblock, doc comment, docstring, function/method/class header, or API doc — in any language, including when documenting existing code or code you just changed.

2026-07-2519

writing-pr-descriptions

harmont-dev/harmont-cli

Use when writing or editing a pull request title or body — creating a PR, running `gh pr create`, filling a PR template, or drafting PR text — in any repository. Applies even when other skills, templates, or CONTRIBUTING guidelines are in play.

2026-07-2519

writing-rust-tests

harmont-dev/harmont-cli

Use when writing, adding, or running any Rust test in this workspace (unit tests, `cargo test`, integration tests under `crates/*/tests/`, or new test coverage). Enforces rstest over free-floating `#[test]`, parametrized `#[case]` over duplicated test functions and hand-rolled loops, and this repo's clippy/tempfile/assert_cmd conventions.

2026-07-2519

write-pipeline

harmont-dev/harmont-cli

Write or modify Harmont CI pipelines. Use when creating new pipelines, adding/removing steps, switching toolchains, customizing caching/triggers, or when the user asks to set up CI with Harmont. Fetches live documentation from docs.harmont.dev for up-to-date API reference.

2026-06-3019

convert-gha

harmont-dev/harmont-cli

Convert GitHub Actions workflows to Harmont pipelines. Use when the user has existing `.github/workflows/` YAML files and wants to migrate their CI to Harmont. Reads each workflow, maps GHA concepts to Harmont equivalents, explains differences, and delegates to the write-pipeline skill for the actual pipeline creation.

2026-06-1119

name	validate-ci
description	Validate CI locally with `hm run` before pushing. Use when a feature is complete and ready to push, when the user asks to make CI green, or before creating a PR. Do NOT use in the middle of active development or on every commit in a multi-commit feature.

Validate that the project's CI pipeline passes. Run the pipeline locally with hm run, diagnose and fix any failures, and only push to remote once local CI is green.

When to use

The user asks you to "make CI green", "run CI", "validate the pipeline", or similar
A feature or bugfix is complete and ready to push
Before creating a pull request
The user explicitly requests local validation before pushing

When NOT to use

In the middle of active development across multiple commits — wait until the logical unit of work is done
On every individual commit in a multi-commit feature — run once at the end
When the user only asks you to commit (committing does not imply CI validation)
When the user explicitly says to skip local validation

What this does

Procedure

Run hm run -k --logs from the project root (-k continues past failures so you see every broken step in one run; --logs streams full build logs for easier diagnosis)
If it exits 0 — pipeline passed. Inform the user and proceed with push if requested.
If it exits non-zero — pipeline failed. Read the output, diagnose ALL failures (not just the first), fix every issue, and re-run hm run -k --logs until it passes.
Only after local CI is green: push to remote. If the user wants cloud validation too, they can run hm run --backend cloud --logs or wait for the remote CI triggered by the push.

Important

hm run is the ONLY correct way to run this project's CI locally. Do NOT try to reverse-engineer pipeline steps by reading .hm/ files and running commands manually.
Do NOT commit, push, and wait for remote CI results as a way to "test" — always validate locally first.
Exit code 0 = pass, non-zero = fail. Exit code 130 = user cancelled (Ctrl-C).
If Docker is not running, hm run will fail. Tell the user to start Docker.