New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Package Version Safety

by PlamenTSV in PlamenTSV/plamen

Trigger Pattern PACKAGEUPGRADE flag (UpgradeCap detected, multiple package versions, upgrade policy references) - Inject Into Breadth agents, depth-external

MITAuto-check passed

Install Package Version Safety

skills CLI
$ npx skills add PlamenTSV/plamen --skill package-version-safety -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install PlamenTSV/plamen package-version-safety --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/PlamenTSV/plamen.git skills-src && mkdir -p .claude/skills && cp -r skills-src/agents/skills/sui/package-version-safety .claude/skills/package-version-safety && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
package-version-safety
GitHub stars
303
Token cost
~3.1k tokens
SKILL.md length
1,339 words
Files
1
Skills in repo
87
Repo updated
First seen
Licence
MIT

At a glance

Trigger Pattern PACKAGEUPGRADE flag (UpgradeCap detected, multiple package versions, upgrade policy references) - Inject Into Breadth agents, depth-external

  • Works in 6 steps: Upgrade Policy Inventory → Version Consistency Check → Dependency Version Pinning → …
  • Pattern PACKAGEUPGRADE flag (UpgradeCap detected
  • SKILL.md covers Trigger Patterns, Step 1: Upgrade Policy Inventory, Step 2: Version Consistency… and Step 3: Dependency Version…, plus 7 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Package Version Safety is an agent skill from PlamenTSV/plamen. Trigger Pattern PACKAGEUPGRADE flag (UpgradeCap detected, multiple package versions, upgrade policy references) - Inject Into Breadth agents, depth-external

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: Autonomous Web3 security audit agent for Claude Code. The licence is MIT.

When your agent uses it

  • Pattern PACKAGEUPGRADE flag (UpgradeCap detected
  • Multiple package versions
  • Upgrade policy references) - Inject Into Breadth agents

Example prompts

  • “/package-version-safety”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Upgrade Policy Inventory
  2. Version Consistency Check
  3. Dependency Version Pinning
  4. Type Compatibility Across Versions
  5. Upgrade Migration Safety
  6. UpgradeCap Governance

What it can do on your machine

Read from SKILL.md and the folder at commit 795962b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Package Version Safety loads about 3.1k tokens when it runs. Until then it costs about 45 tokens; SKILL.md has 1,339 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~45
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from PlamenTSV/plamen at commit 795962b, republished under its MIT licence (© PlamenTSV). 1,339 words, ~3,051 tokens.

Download SKILL.mdSave it as .claude/skills/package-version-safety/SKILL.md (or your agent's skills folder).
name
package-version-safety
description
Trigger Pattern PACKAGE_UPGRADE flag (UpgradeCap detected, multiple package versions, upgrade policy references) - Inject Into Breadth agents, depth-external

Skill: PACKAGE_VERSION_SAFETY (Sui)

Trigger Pattern: PACKAGE_UPGRADE flag (UpgradeCap detected, multiple package versions, upgrade policy references) Inject Into: Breadth agents, depth-external Finding prefix: [PV-N] Rules referenced: R4, R8, R9, R10

Sui packages are immutable once published. "Upgrading" a package means publishing a NEW version at a NEW on-chain address, linked to the original via the UpgradeCap lineage. The old version's code remains callable forever. This creates a fundamentally different upgrade risk model compared to EVM proxies: instead of replacing logic in-place, Sui packages accumulate versions -- and shared objects may be accessible by ALL versions simultaneously.

Trigger Patterns

UpgradeCap|upgrade_policy|package::make_immutable|compatible|additive|dep_only|version|
migrate|old_version|new_version

Step 1: Upgrade Policy Inventory

For each package in scope:

#PackageUpgradeCap LocationUpgradeCap HolderHas store?Upgrade PolicyDestroyed?
1{pkg_name}{init function:line}{address / shared / wrapped in governance}YES/NO{compatible/additive/dep_only}YES (immutable) / NO

Checks:

  • Where is UpgradeCap stored?

    • Owned by deployer address: Single point of failure. Key loss -> permanent immutability. Key theft -> attacker can upgrade.
    • Shared object: DANGEROUS -- anyone can pass it to upgrade functions.
    • Wrapped in governance object: Good pattern -- upgrade requires governance approval.
    • Destroyed via make_immutable(): Package is permanently immutable. No upgrade risk.
    • Transferred to @0x0 or burn address: Effectively immutable.

  • Can UpgradeCap be transferred?

    • UpgradeCap has key + store by default -> freely transferable via public_transfer.
    • Is there a custom wrapper restricting transfer? (e.g., GovernanceCap wrapping UpgradeCap)
    • If transferable and held by EOA -> attacker stealing key can transfer UpgradeCap.

  • Can UpgradeCap be destroyed?

    • sui::package::make_immutable(cap) consumes UpgradeCap -> permanent immutability.
    • If UpgradeCap has drop via wrapper -> accidental destruction possible.
1b. UpgradeCap Governance Assessment
Governance ModelRisk LevelAssessment
Single EOACRITICALOne key compromise replaces all package logic
Multisig (2/3 or lower)HIGHLow collusion threshold
Multisig (3/5+)MEDIUMRequires majority collusion
Multisig + timelockLOWUsers can exit before malicious upgrade takes effect
DAO/governance contractLOWDistributed control, but check voter distribution
Destroyed (immutable)NONECannot upgrade, but also cannot patch bugs

Step 2: Version Consistency Check

For shared objects created by this package:

Shared ObjectCreated By (Version)Current Version Field?V1 Functions Access?V2 Functions Access?Consistency Risk
{obj_type}V1 init()YES: version: u64 / NO{list funcs}{list funcs}{describe}

What happens when package is upgraded?

  • Existing shared objects created by V1 remain at their original address
  • V2 functions CAN access V1-created shared objects (types are preserved in compatible upgrades)
  • V1 functions are STILL callable and CAN access the same shared objects
  • This dual-access is the primary version safety concern

Can old-version and new-version calls on same shared object create inconsistency?

  • V1 function writes field A based on formula F1
  • V2 function writes field A based on formula F2
  • User calls V1 then V2 in separate transactions -> field A has inconsistent state
  • Especially dangerous: V2 adds a new check that V1 lacks. Attacker calls V1 to bypass V2's check.

Step 3: Dependency Version Pinning

For each dependency in Move.toml:

DependencySourcePinned ToImmutable?Upgrade Risk
Sui Frameworksui = "..."{git rev or latest}Upgraded by validatorsFramework upgrade could change behavior
MoveStdlibMoveStdlib = "..."{git rev}Upgraded with frameworkSame as above
{third_party}{git url or on-chain}{specific rev / branch / on-chain version}YES/NO{describe}

Checks:

  • Are third-party dependencies pinned to specific git revisions? If pinned to main -> upstream changes included on recompile.
  • For on-chain published dependencies: is the dependency package immutable? If it has active UpgradeCap -> behavior can change.
  • Can a dependency upgrade break our package's invariants?
  • Are there transitive dependencies with their own upgrade risks?

Can dependency upgrade break our package?

  • Compatible dependency upgrade: function implementations can change but signatures preserved. Our calls still compile but behavior may differ.
  • Additive dependency upgrade: only new functions/types added. Existing behavior frozen.
  • Framework upgrades: sui::* packages upgraded by validators. Can change Move VM behavior, gas costs, object model rules.

Step 4: Type Compatibility Across Versions

When package V2 adds new types or fields:

TypeV1 DefinitionV2 ChangesCompatible Upgrade RuleMigration Needed?
{struct_name}{fields}{cannot change for compatible}Struct layouts FROZENNO -- same layout
{new_struct}N/A{new in V2}New types allowedN/A

Sui type rules for compatible upgrades:

  • Existing struct field layouts CANNOT change (enforced by validator during upgrade)
  • New structs CAN be added
  • Existing function signatures CANNOT change
  • Function bodies CAN change (this is where logic vulnerabilities occur)
  • Generic type parameters must remain the same

Can V1 objects be used with V2 functions?

  • YES for compatible upgrades: types are identical, V2 functions accept V1 objects.
  • NO for separate package deployment: different package address = different types.

Can V2 objects be used with V1 functions?

  • V2 does not create new object types that V1 knows about (V1 code is frozen).
  • But V2 functions can modify shared objects that V1 functions then read -- state corruption possible.

Dynamic field implications:

  • Dynamic fields keyed by type. If V2 changes key/value types for dynamic fields -> V1-era entries orphaned.
  • Check: does V2 change any dynamic field key types?
Show full SKILL.md (540 more words)Show less

Step 5: Upgrade Migration Safety

Does the package have migration functions to update shared objects from V1->V2 state?

Migration FunctionTriggerWhat It UpdatesReversible?Access Control
{migrate_func}{admin call / automatic}{version field, new state}NO{AdminCap / anyone}

Version guard pattern: Shared objects contain version: u64. V1 functions check assert!(version == 1). V2 migration function sets version = 2. After migration, V1 functions abort because version != 1.

Check:

  • Is version guard implemented? If NOT -> old functions remain callable indefinitely -> FINDING.
  • Can migration be triggered by unauthorized parties?
  • Is migration atomic? Can it be partially completed?
  • What happens to user-owned objects during migration? (Owned objects cannot be modified by admin migration)

Step 6: UpgradeCap Governance

If UpgradeCap is owned by a single address:

RiskDescriptionSeverity
Full logic replacementAttacker upgrades package with malicious code. All shared objects now interact with attacker's logic.CRITICAL
Subtle parameter changeAttacker upgrades to change a fee calculation or threshold in function body. Hard to detect.HIGH
Dependency manipulationAttacker upgrades to change dependency versions, pulling in vulnerable code.HIGH
Policy escalation blockedUpgrade policies can only be tightened (compatible -> additive -> dep_only -> immutable). Attacker cannot escalate from additive to compatible.Mitigation

Mitigations to check:

  • Is UpgradeCap behind multisig?
  • Is there an upgrade timelock (users can exit before upgrade takes effect)?
  • Is there a multi-party approval mechanism for upgrades?
  • Has the upgrade policy been tightened from the default compatible?
  • Is make_immutable() called in init() for packages that should never upgrade?

Key Questions (Must Answer All)

  1. UpgradeCap security: Who holds it? What is the attack surface if compromised?
  2. Upgrade policy: Is the policy appropriate? Could it be tightened without losing needed functionality?
  3. Cross-version bypass: Can old functions bypass security checks added in new versions?
  4. Version guard: Is there a mechanism to disable old functions after upgrade?
  5. Type compatibility: Are all types compatible? Are dynamic fields accessible across versions?

Common False Positives

  1. Immutable package: UpgradeCap destroyed or make_immutable called -> no upgrade risk
  2. No shared objects: If old and new packages share no objects, cross-version interaction impossible
  3. Version guard implemented: Shared objects check version field, old functions abort after migration
  4. Capability migrated: Old package's capabilities consumed by new package, old functions uncallable
  5. additive or dep_only policy: Existing logic frozen (but new functions can still access shared objects -- check Step 3c)

Output Schema

markdown
## Finding [PV-N]: Title

**Verdict**: CONFIRMED / PARTIAL / REFUTED / CONTESTED
**Step Execution**: check1,2,3,4,5,6 | skip(reason) | uncertain
**Rules Applied**: [R4:___, R8:___, R9:___, R10:___]
**Severity**: Critical/High/Medium/Low/Info
**Location**: sources/{module}.move:LineN

**Upgrade Risk Type**: UPGRADECAP_MANAGEMENT / POLICY_INAPPROPRIATE / CROSS_VERSION_BYPASS / TYPE_INCOMPATIBILITY / DEPENDENCY_RISK / MISSING_VERSION_GUARD
**Package Version**: V{N} -> V{N+1}
**Shared Objects Affected**: {list}

**Description**: What is wrong
**Impact**: What can happen (logic replacement, security bypass, stranded assets, type mismatch)
**Evidence**: Code showing vulnerability
**Recommendation**: How to fix (tighten policy, add version guard, migrate capabilities, destroy UpgradeCap)

Step Execution Checklist (MANDATORY)

StepRequiredCompleted?Notes
1. Upgrade Policy InventoryYESUpgradeCap location, holder, policy
1b. UpgradeCap Governance AssessmentYESRisk level for each package
2. Version Consistency CheckYESAll shared objects checked for dual-version access
3. Dependency Version PinningYESMove.toml analyzed
4. Type Compatibility Across VersionsYESDynamic fields included
5. Upgrade Migration SafetyYESVersion guard pattern checked
6. UpgradeCap GovernanceIF single-address holderMultisig/timelock/approval checks
Cross-Reference Markers

After Step 1: If UpgradeCap held by single address -> immediate finding (minimum HIGH).

After Step 2: If cross-version bypass possible -> cross-reference with MIGRATION_ANALYSIS Step 5 for shared object function enumeration.

After Step 3: Feed dependency risks to DEPENDENCY_AUDIT for transitive dependency analysis.

After Step 5: If no version guard AND shared objects hold user funds -> minimum HIGH finding.

If any step skipped, document valid reason (N/A, package is immutable, no shared objects, no third-party dependencies).

© PlamenTSV, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in agents/skills/sui/package-version-safety of PlamenTSV/plamen.

Open the folder on GitHubat commit 795962b

Compare with similar skills

Package Version Safety next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Package Version Safety compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Package Version Safety this skillPlamenTSV/plamen303—~3.1kAutomated safety check: PassMIT
Detecting Anomalous Authentication Patternsmukul975/Anthropic-Cybersecurity-Skills34k—~7.5kAutomated safety check: PassApache-2.0
Detecting Beaconing Patterns With Zeekmukul975/Anthropic-Cybersecurity-Skills34k—~662Automated safety check: PassApache-2.0
Python Patternsaffaan-m/ECC275k—~2.3kAutomated safety check: PassMIT
Memory Safety Patternswshobson/agents40k9 repos~646Automated safety check: PassMIT
Golang Patternsaffaan-m/ECC275k—~1.1kAutomated safety check: PassMIT

Similar skills

  • Detecting Anomalous Authentication Patterns

    mukul975/Anthropic-Cybersecurity-Skills

    Detects anomalous authentication patterns using UEBA analytics, statistical baselines, and machine learning models to identify impossible travel, credential stuffing, brute force, password spraying…

    34k GitHub stars~7.5k tokensUpdated 1 mo ago
    Data & AnalyticsAuto-check passed

  • Detecting Beaconing Patterns With Zeek

    mukul975/Anthropic-Cybersecurity-Skills

    Performs statistical analysis of Zeek conn.log connection intervals to detect C2 beaconing patterns.

    34k GitHub stars~662 tokensUpdated 1 mo ago
    Data & AnalyticsAuto-check passed

  • Python Patterns

    affaan-m/ECC

    Python-specific design patterns and best practices including protocols, dataclasses, context managers, decorators, async/await, type hints, and package organization.

    275k GitHub stars~2.3k tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • Memory Safety Patterns

    wshobson/agents

    Implement memory-safe programming with RAII, ownership, smart pointers, and resource management across Rust, C++, and C.

    40k GitHub starsUsed in 9 repos~646 tokens
    Auto-check passed

  • Golang Patterns

    affaan-m/ECC

    Go-specific design patterns and best practices including functional options, small interfaces, dependency injection, concurrency patterns, error handling, and package organization.

    275k GitHub stars~1.1k tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • RTK Rust Design Patterns

    rtk-ai/rtk

    Describes seven Rust design patterns for the RTK CLI filter modules, with when to use each, RTK examples, and notes on when a pattern is overkill.

    83k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed

More from PlamenTSV/plamen

All 87 skills in this repo

  • Audit Prep

    PlamenTSV/plamen

    Prepare Solidity projects for a security audit — test coverage, test quality, NatSpec docs, code hygiene, dependency health, best-practice enforcement, deployment readiness, and project…

    303 GitHub stars~3.7k tokensUpdated 11 days ago
    Auto-check passed

  • Verification Protocol

    PlamenTSV/plamen

    Trigger Pattern Always (used by all verifier agents) - Inject Into security-verifier agents (Phase 5)

    303 GitHub stars~3.5k tokensUpdated 11 days ago
    Auto-check passed

  • Ability Analysis

    PlamenTSV/plamen

    Trigger Pattern Always (Aptos Move) - foundational security check - Inject Into Breadth agents, depth agents

    303 GitHub stars~3.3k tokensUpdated 11 days ago
    Auto-check passed

  • Ability Analysis

    PlamenTSV/plamen

    Trigger Pattern Always (Sui Move) -- foundational security check - Inject Into Breadth agents, depth agents

    303 GitHub stars~3.2k tokensUpdated 11 days ago
    Auto-check passed

  • Account Lifecycle

    PlamenTSV/plamen

    Trigger Pattern ACCOUNTCLOSING flag detected (close/CloseAccount usage) - Inject Into Breadth agents, depth agents

    303 GitHub stars~1.2k tokensUpdated 11 days ago
    Auto-check passed

  • Account Validation

    PlamenTSV/plamen

    Trigger Pattern Always required for Solana audits - Inject Into Breadth agents, depth agents

    303 GitHub stars~1.7k tokensUpdated 11 days ago
    Auto-check passed

Questions about Package Version Safety

What does Package Version Safety do?

Trigger Pattern PACKAGEUPGRADE flag (UpgradeCap detected, multiple package versions, upgrade policy references) - Inject Into Breadth agents, depth-external. Package Version Safety is an agent skill from PlamenTSV/plamen.

When should I use Package Version Safety?

Package Version Safety fits situations like: pattern PACKAGEUPGRADE flag (UpgradeCap detected; multiple package versions; upgrade policy references) - Inject Into Breadth agents.

How do I install Package Version Safety in Claude Code?

Run `npx skills add PlamenTSV/plamen --skill package-version-safety -a claude-code`. Or copy the skill folder (agents/skills/sui/package-version-safety in PlamenTSV/plamen) into .claude/skills/package-version-safety in your project. Claude Code loads it when a task matches its description.

How do I install Package Version Safety in Codex?

Run `npx skills add PlamenTSV/plamen --skill package-version-safety -a codex`. Or copy the skill folder (agents/skills/sui/package-version-safety in PlamenTSV/plamen) into .agents/skills/package-version-safety in your project. Codex loads it when a task matches its description.

Can I use Package Version Safety in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add PlamenTSV/plamen --skill package-version-safety -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/package-version-safety, .gemini/skills/package-version-safety, .github/skills/package-version-safety and .opencode/skills/package-version-safety in your project.

What does Package Version Safety need to run?

SKILL.md names no scripts, command-line tools or credentials: Package Version Safety is instructions for the agent only.

Does Package Version Safety access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Package Version Safety safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Package Version Safety use?

Package Version Safety is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Package Version Safety use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Package Version Safety?

Skills that share tags, products or a category with Package Version Safety: Detecting Anomalous Authentication Patterns (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Detecting Beaconing Patterns With Zeek (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Python Patterns (affaan-m/ECC, 275k stars) and Memory Safety Patterns (wshobson/agents, 40k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Package Version Safety?

PlamenTSV (a GitHub user) maintains it in PlamenTSV/plamen, which has 303 GitHub stars. The repository holds 87 skills in this directory. The repository was last updated on September 26, 2026.

Source: PlamenTSV/plamen on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.