CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

30.8 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 1 flagged

Securityscore 88 · 1 finding

MEDIUMInstruction telling the agent not to ask for approvalSS-SKILL-INJECT-DONT-ASK-01 · Prompt injection · README.md

MEDIUM — it fires on intent; the real damage depends on the host agent's own approval-gating.

Why it matters

The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.

The exact value spotted

excerptREADME.md· markdown

342## Accounts and credentials

343

344SC should never ask you to paste a password, API key, or access token into chat or machine-t

… (9 chars elided on L344)

345

346When account access is required, SC should tell you:

Occurrences

1 occurrence · at L344

How to fix

Remove the approval-skipping instruction, or scope it narrowly to a specific safe, reversible action.

Delete blanket "don't ask / no need to confirm" directives from the skill.
If the skill is a genuine autonomous job, restrict the opt-out to a named non-destructive action rather than all actions.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-DONT-ASK-01sha25614b7852251bf4666…rubric 365aacaView on GitHub

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

skills/sc-resend/SKILL.md · 1 file

skills/sc-resend/SKILL.md3.1 KB · Markdown

name: sc-resend

description: "(STUB / NOT IMPLEMENTED YET) Transactional email via Resend — verify sender domain DNS (DKIM/SPF/DMARC), create API keys, send template-based emails. Pairs with sc-cf or lib/hostinger.js for the DNS record creation step."

use_when: "Use only when maintaining or implementing the unfinished dedicated Resend automation itself. Credential storage and live verification belong to sc-provider until this skill is implemented."

do_not_use_when: "Do not route normal user-facing Resend provisioning/email tasks here; the dedicated automation is not implemented yet. Keep credential work in sc-provider and explain the current limitation."

required_tools: []

security_constraints: "Never request, print, or persist plaintext credentials in chat/tool payloads; use SI-Coder safe credential handoffs."

references: []

compatibility: "Standalone SI-Coder; host invocation syntax and available tools may vary."

/sc-resend — Resend (STUB)

Status: boilerplate only.

Scope when implemented

Domain verification: register a sending domain with Resend, fetch the DKIM/SPF/DMARC records it requires, then create them via sc-cf or lib/hostinger.js automatically — no manual DNS copy-paste.
API key rotation per project, scoped to the verified domain.
Audience creation for broadcast lists (optional).
Smoke send to a verified recipient to confirm DNS propagation.

Sender identity policy

Sender identity is project configuration, not repository-global policy. Use one explicitly verified Resend domain/account selected by the user and keep the visible project name separate from the sender address:

From: <Project Name> <[email protected]>
Reply-To: <optional monitored mailbox>

Do not infer a sender address from the application hostname. A project hosted at app.example.com may legitimately send from a different verified domain. Keep the project-local contract explicit:

[email protected]
EMAIL_PROJECT_NAME=<Project Name>
EMAIL_PROJECT_TAG=<project-slug>
EMAIL_REPLY_TO=

Framework adapters may map these values into native variables, but the selected project configuration remains the source of truth. Never bake another project's domain, sender, or display name into this skill.

Env vars

Var	Purpose
`RESEND_API_KEY`	`re_...` server key
`RESEND_FROM_DOMAIN`	The verified sending domain

Suggested file layout

sc-resend/
├── SKILL.md
└── scripts/
    ├── verify-domain.js   # register + auto-create DNS records via sc-cf / hostinger
    ├── api-key.js         # create/rotate scoped API key
    ├── audiences.js       # CRUD audience (optional)
    └── smoke-send.js      # send a test email to confirm

Implementation notes

API base: https://api.resend.com
Auth: Authorization: Bearer <RESEND_API_KEY>
Domain verify response gives 3 records [{ name, type, value }] — feed those into the DNS module via configureDns().
DMARC: Resend recommends v=DMARC1; p=none; initially, tighten to p=quarantine once SPF/DKIM are confirmed in DNS for 24h.

sc-resend— agent skill

Is sc-resend safe to install?

/sc-resend — Resend (STUB)

Scope when implemented

Sender identity policy

Env vars

Suggested file layout

Implementation notes

Audit the pieces. Scan the whole. Decide.