— No reviews yet
0 installs
17 views
0.0% view→install
Install
$ agentstack add skill-zeyuzhangzyz-open-source-hardening-skills-oss-ci ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Are you the author of Oss Ci? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claimAbout
OSS CI
Create the smallest GitHub Actions workflow that blocks broken pull requests and keeps maintenance friction low.
Context: $ARGUMENTS
Input Contract
- Primary input: existing local verification commands from the repository,
OSS_TEST_STRATEGY.md, and any lint/type-check commands added by/oss-refactor. - Default: if commands are ambiguous, choose the narrowest trustworthy lint + test pair that already works locally.
Output Contract
Produce:
- A workflow in
.github/workflows/(create or update, do not duplicate existing intent). OSS_CI.mdsummarizing:
- workflow triggers
- jobs and commands
- cache strategy
- failure policy
- known follow-ups
The workflow must satisfy all of the following:
- Trigger on
pushandpull_request - Run lint plus test
- Use dependency caching when the ecosystem supports it
- Fail the workflow on errors
- Require no secrets or external services
Non-goals
- Do not add deployment, release, or publish automation in this step.
- Do not build a matrix that the repository cannot maintain.
- Do not call live third-party APIs from CI.
Workflow Design Rules
- Reuse existing scripts if they already encode the right commands.
- Prefer one job with clear steps over a sprawling workflow.
- Add caching through the setup action when available:
- Python:
actions/setup-pythonwithcache: pip - Node:
actions/setup-nodewith package-manager cache - Go:
actions/setup-gocache support - Rust: lightweight cargo cache only if already justified
- If the repo has both lint and test but one is flaky, do not hide it. Either stabilize it first or document why the workflow currently omits it.
Workflow
Step 1: Confirm local commands
- Run or inspect the exact commands that should execute in CI.
- Prefer commands that contributors can also run locally.
Step 2: Merge with any existing workflow
- If
.github/workflows/ci.ymlor similar already exists, extend it rather than creating a competing workflow. - Keep the workflow readable for maintainers.
Step 3: Enforce CI-safe execution
- Mock or bypass external services.
- Use fixture files instead of network fetches.
- For paper or benchmark code, run a toy config, dry run, or tiny fixture path instead of full training or evaluation.
- Keep runtime short enough for pull requests.
Step 4: Document the workflow
Record in OSS_CI.md:
- what blocks merges now
- what remains intentionally out of scope
- how to reproduce the workflow locally
Anti-patterns
- Do not create a second workflow that duplicates an existing CI intent without improving it.
- Do not run commands in CI that are not already trusted locally.
- Do not hide omitted checks without recording why they were excluded in
OSS_CI.md. - Do not require secrets or live services in the primary blocking workflow.
Self-check
Before declaring this stage complete, verify:
- [ ] A workflow file exists under
.github/workflows/. - [ ] The workflow triggers on both
pushandpull_request. - [ ] The workflow runs lint and test commands that match the repo's local verification path.
- [ ]
OSS_CI.mdrecords triggers, jobs, cache behavior, local reproduction steps, and known follow-ups.
Failure Handling
- If no reliable test command exists yet, stop and hand back to
/oss-tests. - If the only available lint tool requires a heavy new dependency, document the recommendation and keep the workflow focused on what already works.
- If an existing workflow overlaps, consolidate instead of duplicating.
Done Criteria
.github/workflows/contains one primary CI workflow for the repo's lint and test path.- The workflow triggers on
pushandpull_request, fails on command failure, and avoids secrets or live services. OSS_CI.mdrecords triggers, jobs, commands, cache behavior, local reproduction, and remaining gaps.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: zeyuzhangzyz
- Source: zeyuzhangzyz/open-source-hardening-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.