ci-pipeline
Skill1 starsChanged 7 days agoMITView on GitHub
The Build Pipeline workflow - its jobs, the six required checks, the Summary comment, the monthly schedules, and how to fix a failing check without weakening it. Use when a check fails, when changing .github/workflows, or when explaining what CI does.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- Ionate-Technologies/indium-agentkittheir own version, first seen Oct 20, 2026
- Indium-AI-Labs/indium-agentkittheir own version, first seen Oct 11, 2026
- Jinbae10/skillstheir own version, first seen Jul 7, 2026
- viknesh20-20/claude-code-tool-kittheir own version, first seen May 2, 2026
- vndee/engineering-skillstheir own version, first seen Mar 22, 2026
Other versions5 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 5
- Indium-AI-Labs/indium-agentkit★ 18same name
- Ionate-Technologies/indium-agentkit★ 17same name
- viknesh20-20/claude-code-tool-kit★ 7same name
- vndee/engineering-skills★ 3same name
- Jinbae10/skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository40 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-a-use-caseSkill
- api-conventionsSkill
- branches-and-pull-requestsSkill
- cancellationSkill
- ci-for-your-solutionSkill
- clean-architecture-layersSkill
- configuration-and-environmentsSkill
- coverageSkill
- csharp-house-styleSkill
- data-access-ef-coreSkill
- database-migrationsSkill
- docker-and-composeSkill
- docs-and-voiceSkill
- errors-and-exceptionsSkill
- expose-a-use-caseSkill
- family-syncSkill
- health-checksSkill
- integration-testsSkill
- json-serializationSkill
- mapping-with-mapperlySkill
- mcp-inspectorSkill
- mediatorSkill
- optional-token-authSkill
- packages-and-dependenciesSkill
- pagingSkill
- presentation-integration-testsSkill
- releasesSkill
- sample-dataSkill
- security-findingsSkill
- serilogSkill
- telemetrySkill
- template-authoringSkill
- test-designSkill
- time-providerSkill
- unit-testsSkill
- validationSkill
- writing-a-skillSkill
- xml-docs-and-openapiSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 5 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
After those, Release Check and Publish only run on the monthly release (releases).
- Distinctive: line 29
Read the Summary comment first.
- Distinctive: line 39
Add a step that needs an account, a paid service or a secret to pass on a fresh copy.
- Distinctive: line 44
Every required check is green on the pull request, and the Summary comment shows no red rows.
“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CI pipeline
The rule
One workflow, .github/workflows/build-pipeline.yml, runs on every pull request, every push to main, two monthly schedules and on demand. Jobs run as a chain, and these six are required checks:
| Check | What it does | Fails when |
| Build | dotnet format --verify-no-changes, docker build of the runtime image, dotnet pack of the template, the report action's own tests | Style, a warning, a build error, or a template package over 1 MB |
| Test | Runs every test project inside the Dockerfile's test stage, reports results and coverage, then installs the packed template, generates a solution (its restore post action restores the .slnx), checks its format, tests it and checks it has .github/workflows/ci.yml, then does the same with --include-auth where the template has it | A failing test, coverage under 95%, or a template that doesn't generate, format and pass |
| Static Analysis (actions, csharp) | CodeQL security-and-quality on the workflows and the C# | A finding of medium severity or higher |
| Dependency Review | New or updated packages on a pull request | A high or critical vulnerability, or a licence other than MIT, Apache-2.0 or BSD |
| Container Scan | Starts the image and calls it, then Trivy scans the image and the Dockerfile and compose config | The smoke test fails, or a fixable high or critical finding |
| Summary | Posts one comment on the pull request with a row per check, built by .github/actions/pipeline-report | Any check above failed |
After those, Release Check and Publish only run on the monthly release (releases).
A copy made with GitHub's "Use this template" gets this workflow with no secrets or setup. Outside the LeanMeanCleanApps organisation it runs only the format check, build and tests: Static Analysis, Dependency Review, Container Scan, the template's pack and verify steps, Release Check and Publish all check github.repository_owner and skip, and the Summary shows them as not run. Skipped jobs count as passed for required checks, so a private copy goes green without Advanced Security. A solution made with dotnet new gets the much smaller template/ci.yml as .github/workflows/ci.yml instead. ci-for-your-solution covers both. Keep any new job that needs Advanced Security, a secret or the template folders behind the same owner check.
Steps
- Read the Summary comment first; it names the unhappy check and links to its details.
- Reproduce locally where you can (every command finds the
.slnxin the root on its own):dotnet format --verify-no-changes,dotnet build,dotnet test, the coverage command incoverage,docker build . --target run. - Fix the cause in the code. For security findings, see
security-findings. - Changing the workflow itself: keep each tool as an off-the-shelf action, keep the job names (they're the required check names), and keep everything working in someone else's copy of the template with no secrets or setup.
Don't
- Skip, disable or mark a test as skipped to get green.
- Lower
COVERAGE_THRESHOLD, raiseTEMPLATE_MAX_SIZE, or relax a severity to pass. - Rename a job without updating the repository's required checks.
- Add a step that needs an account, a paid service or a secret to pass on a fresh copy.
- Push an empty commit to re-run CI. Re-run the job from the Actions page.
Check
Every required check is green on the pull request, and the Summary comment shows no red rows.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.