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 GiustoPiedimonte/agentic-engineering-marketplace --skill opensourcegit clone --depth 1 https://github.com/GiustoPiedimonte/agentic-engineering-marketplaceWrote 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/giustopiedimonte/agentic-engineering-marketplace/opensource)<a href="https://agentmods.dev/skills/giustopiedimonte/agentic-engineering-marketplace/opensource"><img src="https://agentmods.dev/badge/skills/giustopiedimonte/agentic-engineering-marketplace/opensource.svg" alt="Measured on agentmods" height="20"></a>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.00104 | $0.00888 |
| Opus 5 | $0.00052 | $0.00444 |
| Sonnet 5 | $0.00021 | $0.00178 |
| Haiku 4.5 | $0.00010 | $0.00089 |
Grade A, and why
opensource 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 7d 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.
How it starts
The opening of the file, as written. The whole thing — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/opensource — make a repository well-made and public-ready
A public repo is judged on more than its README: the community-health files, an
honest CI signal, a security policy, and sane settings are what make it a project
people trust and can contribute to. This skill establishes the gap and closes it.
$ARGUMENTS is the target repo (default: the current one).
Two gates govern everything:
- Outward/irreversible actions need explicit confirmation. Making a repo public, creating a release, changing visibility or settings, and pushing are outward — confirm first. Never flip a repo to public without the human saying so.
- Contact details are the human's call. A Code of Conduct and a Security policy need a reporting channel — ask; don't expose a personal email by default. The privacy-preserving default is GitHub's private vulnerability reporting.
Process
-
Establish ground truth — read, don't assume. Is it a GitHub repo? Public or private? Pull the community profile and existing files/settings, and detect the repo type (it drives the CI check and the install docs). See
references/OSS_PLAYBOOK.md. -
Report the gap, then confirm the plan. Present present-vs-missing against the checklist, split into files (safe, in-repo) and settings / outward actions (need confirmation). Ask the two questions: contact method, and whether to add CI. Don't generate until the plan is agreed.
-
Generate the community-health files from
references/templates/, filling placeholders ({{OWNER}},{{REPO}},{{PROJECT}},{{CONTACT}},{{VALIDATE_COMMAND}}). Match the repo's voice. If a file already exists, improve it instead of overwriting — and gate a big rewrite on confirmation (same rule as/readme). -
Add an honest CI gate. Commit
.github/workflows/validate.ymlrunning the repo's real, deterministic check (tests/lint for a code repo; a structure/link validation script for a markdown/config repo). Only after it exists, add the CI badge — never a CI badge without a workflow.
What ships with it
9 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.
- references/OSS_PLAYBOOK.md 5.8 KB
- references/templates/.github/ISSUE_TEMPLATE/bug_report.yml 809 B
- references/templates/.github/ISSUE_TEMPLATE/config.yml 271 B
- references/templates/.github/ISSUE_TEMPLATE/feature_request.yml 564 B
- references/templates/.github/PULL_REQUEST_TEMPLATE.md 563 B
- references/templates/.github/workflows/validate.yml 784 B
- references/templates/CODE_OF_CONDUCT.md 2.8 KB
- references/templates/CONTRIBUTING.md 1.0 KB
- references/templates/SECURITY.md 977 B
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.
- 7d ago First seen · 77 lines · 104 tokens per session scan A 8c4605aab591
opensource is a skill published in the GitHub repository GiustoPiedimonte/agentic-engineering-marketplace (13 stars, last pushed 1mo ago), licensed MIT. It adds 104 tokens to every session and 888 once invoked, about $0.0005 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
release
Bump a plugin's version, write a detailed changelog entry for the upgrade skill to consume, and commit+push. Takes a plugin slug argument identifying which plugin under plugins/ to release. Use this skill whenever the user says "release", "version bump", "cut a release", "changelog and push", or finishes a set of…
pre-release-review
Run the pre-release gate for this multi-plugin monorepo: establish each plugin's release boundary from its last reachable tag to HEAD, audit every changed plugin's [Unreleased] changelog against the actual code diff, identify contract-surface and breaking changes, and, per the objective the user picks up front, either…
commit
Changelog and commit — lightweight motion for day-to-day plugin dev work in the monorepo. One commit per plugin scope; CHANGELOG and staging routed by detected slug. Trigger when the user says "commit", "commit this", "save this", "wrap this up", "let's commit", or finishes a change and wants to capture it. NOT for…
fleet-release
Use this skill whenever the user wants to release, ship, prep, or cut versions for two or more plugins together on the current branch. Trigger on phrasings like "release both plugins", "ship them together", "release all changed plugins", "fleet release", "multi-plugin release", "release in order", or "release…
pipeline-digest
Daily release-pipeline digest with a change gate — reports which plugins are pending release, whether main's CI is green, and which branches went stale, and notifies the operator only when that state actually moved since the last run. Use when the operator asks "what moved in the pipeline", "anything to ship"…
github-pr-merge
Merges GitHub Pull Requests after validating pre-merge checklist. Use when user wants to merge PR, close PR, finalize PR, complete merge, approve and merge, or execute merge. Runs pre-merge validation (tests, lint, CI, comments), confirms with user, merges with proper format, handles post-merge cleanup.