Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add harness/harness-skills --skill verify-signgit clone --depth 1 https://github.com/harness/harness-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/harness/harness-skills/verify-sign)<a href="https://agentmods.dev/skills/harness/harness-skills/verify-sign"><img src="https://agentmods.dev/badge/skills/harness/harness-skills/verify-sign/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/harness/harness-skills/verify-sign"><img src="https://agentmods.dev/badge/skills/harness/harness-skills/verify-sign.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Data Exfiltration · line 195 Code or instructions that leak agent conversation context to external services, potentially exposing sensitive user interactions.Fix: Remove any code that sends prompts, responses, or session data externally. Preserve user privacy; never exfiltrate conversation content.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00144 | $0.04102 |
| Opus 5 | $0.00072 | $0.02051 |
| Sonnet 5 | $0.00029 | $0.00820 |
| Haiku 4.5 | $0.00014 | $0.00410 |
Grade A, and why
verify-sign scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- verify-sign — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 420 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify Sign
Add an Artifact Verification (SscaArtifactVerification) step to an existing Harness pipeline.
The step verifies Cosign signatures on artifacts — typically immediately after SscaArtifactSigning.
This skill only works with existing pipelines — do not create standalone verification-only pipelines.
Prerequisites: Artifact must already be signed (typically via /sign-artifact /
SscaArtifactSigning). Key-based verify requires the Cosign public key file secret matching the
signing private key (/create-secret). If signing did not upload .sig to the registry, Harness
pulls the signature from its database during verification.
Supported stages: CI, Security, and CD (Deployment in containerized step group before deploy).
Guide the user through a step-by-step interactive wizard (same UX as /sign-artifact):
- Wizard:
references/interactive-wizard-flow.md - UI ↔ YAML:
references/artifact-verification-step.md - CD containerized step groups:
references/cd-containerized-step-group.md
Interaction model (mandatory)
- One question per turn — use
AskQuestionwhen available; otherwise numbered options with(Recommended). - Opening message — add Artifact Verification; mention signing prerequisite + HAR support.
- Progress breadcrumb — after pipeline fetch:
Pipeline · Placement · Source · Details · Verify · Submit - Record answers — running summary; do not re-ask unless the user changes direction.
- Fetch before configure —
harness_getbefore placement/source questions. - Show pipeline structure — highlight
SscaArtifactSigningand connectors. - Infer source from signing — when one
SscaArtifactSigningstep exists, reuse its source. If multiple exist, ask which step to mirror. - Never guess image tags — default from signing step; ask if ambiguous.
- Confirm before write — summary +
harness_updateonly after user confirms. - Stop after update — after successful
harness_update, provide a configuration summary and point the user to/run-pipelineto execute. Do not callharness_execute, poll executions, or runharness_diagnosein this skill (same pattern as/configure-repo-scan). - CD on CI-only pipeline — do not reject CD verify; run Phase 3b to add Deploy stage + containerized group.
- Verify method must match signing — keyless ↔ keyless, keybased/cosign ↔ public key from same key pair.
- Offer all three source tiles — Third-Party, HAR, and Harness Local Stage.
- List all connectors in Phase 6 — same rules as
/sign-artifact:harness_listwithfilters.type, all scopes,size: 100, paginate; never hand-pick a subset. See wizard Phase 6. - List all infrastructure in Phase 3b —
harness_listper environment withfilters.environment_id; never show only the infra for one pre-selected environment. - CD image defaults to
<+artifact.image>— for Deploy-stage verify, recommend the service artifact expression over a static tag from signing. Warn when static image ≠ service default tag. - Preflight delegates before CD update —
harness_list(resource_type="delegate")orharness_execute(test_connection)on the K8s connector used instepGroupInfra. Abort or warn ifDELEGATE_NOT_AVAILABLEis likely (connector hasdelegateSelectorswith no active delegate). - CD Deploy stage YAML requirements — new Deploy stages need
failureStrategies: StageRollback,rollbackStepswithK8sRollingRollback+spec: {}, and CI stages needMarkAsFailurewhen missing. Seereferences/cd-containerized-step-group.md.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 420 lines · 144 tokens per session scan A ae98224ea2da
verify-sign is a skill published in the GitHub repository harness/harness-skills (105 stars, last pushed yesterday), licensed Apache-2.0. It adds 144 tokens to every session and 4,102 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
github-actions-templates
Create production-ready GitHub Actions workflows for automated testing, building, and deploying applications. Use when setting up CI/CD with GitHub Actions, automating development workflows, or creating reusable workflow templates.
secrets-management
Implement secure secrets management for CI/CD pipelines using Vault, AWS Secrets Manager, or native platform solutions. Use when handling sensitive credentials, rotating secrets, or securing CI/CD environments.
deployment-pipeline-design
Design multi-stage CI/CD pipelines with approval gates, security checks, and deployment orchestration. Use this skill when designing zero-downtime deployment pipelines, implementing canary rollout strategies, setting up multi-environment promotion workflows, or debugging failed deployment gates in CI/CD.
gitlab-ci-patterns
Build GitLab CI/CD pipelines with multi-stage workflows, caching, and distributed runners for scalable automation. Use when implementing GitLab CI/CD, optimizing pipeline performance, or setting up automated testing and deployment.
airflow-dag-patterns
Build production Apache Airflow DAGs with best practices for operators, sensors, testing, and deployment. Use when creating data pipelines, orchestrating workflows, or scheduling batch jobs.
nx-workspace-patterns
Configure and optimize Nx monorepo workspaces. Use when setting up Nx, configuring project boundaries, optimizing build caching, or implementing affected commands.