Generated banner for Sharp Edges
Generated logo for Sharp Edges

Sharp Edges

Trail of BitsOfficialPublished by Trail of Bits

  • Skill
  • Guidelines
  • Security
  • CC-BY-SA-4.0
  • Medium risk

From the author

Identifies error-prone APIs, dangerous configurations, and footgun designs that enable security mistakes. Use when reviewing API designs, configuration schemas, cryptographic library ergonomics, or evaluating whether code follows 'secure by default' and 'pit of success' principles. Triggers: footgun, misuse-resistant, secure defaults, API usability, dangerous configuration.
— the description by Trail of Bits

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Sharp Edges is a systematic analysis framework designed to identify 'footguns'—design patterns in APIs, libraries, and configurations that make it easy for developers to inadvertently introduce security flaws. By focusing on the 'pit of success' principle, this skill helps auditors and developers ensure that the path of least resistance is also the most secure one. It provides a structured workflow to probe for common pitfalls like weak algorithm selection, insecure defaults, silent failures, and type confusion, moving beyond simple bug hunting to address the root causes of developer-induced security mistakes.

What it does

  • Maps security-relevant APIs and configuration schemas for potential misuse.
  • Probes for edge cases like zero, null, or negative values that bypass security logic.
  • Evaluates whether default settings are secure by design.
  • Identifies cryptographic and authentication patterns prone to developer error.
  • Assesses the risk of silent failures and stringly-typed security interfaces.
  • Classifies findings by severity based on how easily a developer can trigger a vulnerability.

When to use it

  • During the design phase of new APIs or configuration schemas.
  • When auditing cryptographic library ergonomics and usage patterns.
  • When reviewing authentication and authorization interfaces.
  • When assessing whether code follows secure-by-default principles.
  • When evaluating the impact of developer-facing configuration options.

Advantages

  • Focuses on design-level flaws rather than just implementation bugs.
  • Promotes the 'pit of success' by identifying where secure usage is difficult.
  • Provides a repeatable, four-phase workflow for consistent analysis.
  • Helps prevent common security mistakes like algorithm confusion and insecure defaults.
  • Encourages the creation of misuse-resistant APIs.

Usage examples

“Analyze this authentication library for potential sharp edges.”
The agent will identify if the library allows empty passwords, uses predictable token generation, or has insecure default session timeouts.
“Review this configuration schema for dangerous options.”
The agent will flag boolean flags that disable security, unvalidated constructor parameters, or magic values that could lead to catastrophic failure.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/trailofbits/sharp-edges/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip sharp-edges.zip -d .agents/skills

Documentation by Trail of Bits

Sharp Edges Analysis

Evaluates whether APIs, configurations, and interfaces are resistant to developer misuse. Identifies designs where the "easy path" leads to insecurity.

When to Use

  • Reviewing API or library design decisions

  • Auditing configuration schemas for dangerous options

  • Evaluating cryptographic API ergonomics

  • Assessing authentication/authorization interfaces

  • Reviewing any code that exposes security-relevant choices to developers

When NOT to Use

  • Implementation bugs (use standard code review)

  • Business logic flaws (use domain-specific analysis)

  • Performance optimization (different concern)

Agent

The sharp-edges-analyzer agent runs the full sharp edges analysis workflow autonomously. Use it when you want a dedicated analysis of APIs, configurations, or interfaces for misuse resistance and footgun potential. The agent follows the four-phase workflow (Surface Identification, Edge Case Probing, Threat Modeling, Validate Findings) and reads language-specific references on demand.

Core Principle

The pit of success: Secure usage should be the path of least resistance. If developers must understand cryptography, read documentation carefully, or remember special rules to avoid vulnerabilities, the API has failed.

Rationalizations to Reject

RationalizationWhy It's WrongRequired Action
"It's documented"Developers don't read docs under deadline pressureMake the secure choice the default or only option
"Advanced users need flexibility"Flexibility creates footguns; most "advanced" usage is copy-pasteProvide safe high-level APIs; hide primitives
"It's the developer's responsibility"Blame-shifting; you designed the footgunRemove the footgun or make it impossible to misuse
"Nobody would actually do that"Developers do everything imaginable under pressureAssume maximum developer confusion
"It's just a configuration option"Config is code; wrong configs ship to productionValidate configs; reject dangerous combinations
"We need backwards compatibility"Insecure defaults can't be grandfather-clausedDeprecate loudly; force migration

Sharp Edge Categories

1. Algorithm/Mode Selection Footguns

APIs that let developers choose algorithms invite choosing wrong ones.

The JWT Pattern (canonical example):

  • Header specifies algorithm: attacker can set "alg": "none" to bypass signatures

  • Algorithm confusion: RSA public key used as HMAC secret when switching RS256→HS256

  • Root cause: Letting untrusted input control security-critical decisions

Detection patterns:

  • Function parameters like algorithm, mode, cipher, hash_type

  • Enums/strings selecting cryptographic primitives

  • Configuration options for security mechanisms

Example - PHP password_hash allowing weak algorithms:

// DANGEROUS: allows crc32, md5, sha1
password_hash($password, PASSWORD_DEFAULT); // Good - no choice
hash($algorithm, $password); // BAD: accepts "crc32"
2. Dangerous Defaults

Defaults that are insecure, or zero/empty values that disable security.

The OTP Lifetime Pattern:

# What happens when lifetime=0?
def verify_otp(code, lifetime=300):  # 300 seconds default
    if lifetime == 0:
        return True  # OOPS: 0 means "accept all"?
        # Or does it mean "expired immediately"?

Detection patterns:

  • Timeouts/lifetimes that accept 0 (infinite? immediate expiry?)

  • Empty strings that bypass checks

  • Null values that skip validation

  • Boolean defaults that disable security features

  • Negative values with undefined semantics

Questions to ask:

  • What happens with timeout=0? max_attempts=0? key=""?

  • Is the default the most secure option?

  • Can any default value disable security entirely?

3. Primitive vs. Semantic APIs

APIs that expose raw bytes instead of meaningful types invite type confusion.

The Libsodium vs. Halite Pattern:

// Libsodium (primitives): bytes are bytes
sodium_crypto_box($message, $nonce, $keypair);
// Easy to: swap nonce/keypair, reuse nonces, use wrong key type

// Halite (semantic): types enforce correct usage
Crypto::seal($message, new EncryptionPublicKey($key));
// Wrong key type = type error, not silent failure

Detection patterns:

  • Functions taking bytes, string, []byte for distinct security concepts

  • Parameters that could be swapped without type errors

  • Same type used for keys, nonces, ciphertexts, signatures

The comparison footgun:

// Timing-safe comparison looks identical to unsafe
if hmac == expected { }           // BAD: timing attack
if hmac.Equal(mac, expected) { }  // Good: constant-time
// Same types, different security properties
4. Configuration Cliffs

One wrong setting creates catastrophic failure, with no warning.

Detection patterns:

  • Boolean flags that disable security entirely

  • String configs that aren't validated

  • Combinations of settings that interact dangerously

  • Environment variables that override security settings

  • Constructor parameters with sensible defaults but no validation (callers can override with insecure values)

Examples:

# One typo = disaster
verify_ssl: fasle  # Typo silently accepted as truthy?

# Magic values
session_timeout: -1  # Does this mean "never expire"?

# Dangerous combinations accepted silently
auth_required: true
bypass_auth_for_health_checks: true
health_check_path: "/"  # Oops
// Sensible default doesn't protect against bad callers
public function __construct(
    public string $hashAlgo = 'sha256',  // Good default...
    public int $otpLifetime = 120,       // ...but accepts md5, 0, etc.
) {}

See config-patterns.md for detailed patterns.

5. Silent Failures

Errors that don't surface, or success that masks failure.

Detection patterns:

  • Functions returning booleans instead of throwing on security failures

  • Empty catch blocks around security operations

  • Default values substituted on parse errors

  • Verification functions that "succeed" on malformed input

Examples:

# Silent bypass
def verify_signature(sig, data, key):
    if not key:
        return True  # No key = skip verification?!

# Return value ignored
signature.verify(data, sig)  # Throws on failure
crypto.verify(data, sig)     # Returns False on failure
# Developer forgets to check return value
6. Stringly-Typed Security

Security-critical values as plain strings enable injection and confusion.

Detection patterns:

  • SQL/commands built from string concatenation

  • Permissions as comma-separated strings

  • Roles/scopes as arbitrary strings instead of enums

  • URLs constructed by joining strings

The permission accumulation footgun:

permissions = "read,write"
permissions += ",admin"  # Too easy to escalate

# vs. type-safe
permissions = {Permission.READ, Permission.WRITE}
permissions.add(Permission.ADMIN)  # At least it's explicit

Analysis Workflow

Phase 1: Surface Identification
  1. Map security-relevant APIs: authentication, authorization, cryptography, session management, input validation

  2. Identify developer choice points: Where can developers select algorithms, configure timeouts, choose modes?

  3. Find configuration schemas: Environment variables, config files, constructor parameters

Phase 2: Edge Case Probing

For each choice point, ask:

  • Zero/empty/null: What happens with 0, "", null, []?

  • Negative values: What does -1 mean? Infinite? Error?

  • Type confusion: Can different security concepts be swapped?

  • Default values: Is the default secure? Is it documented?

  • Error paths: What happens on invalid input? Silent acceptance?

Phase 3: Threat Modeling

Consider three adversaries:

  1. The Scoundrel: Actively malicious developer or attacker controlling config

    • Can they disable security via configuration?

    • Can they downgrade algorithms?

    • Can they inject malicious values?

  2. The Lazy Developer: Copy-pastes examples, skips documentation

    • Will the first example they find be secure?

    • Is the path of least resistance secure?

    • Do error messages guide toward secure usage?

  3. The Confused Developer: Misunderstands the API

    • Can they swap parameters without type errors?

    • Can they use the wrong key/algorithm/mode by accident?

    • Are failure modes obvious or silent?

Phase 4: Validate Findings

For each identified sharp edge:

  1. Reproduce the misuse: Write minimal code demonstrating the footgun

  2. Verify exploitability: Does the misuse create a real vulnerability?

  3. Check documentation: Is the danger documented? (Documentation doesn't excuse bad design, but affects severity)

  4. Test mitigations: Can the API be used safely with reasonable effort?

If a finding seems questionable, return to Phase 2 and probe more edge cases.

Severity Classification

SeverityCriteriaExamples
CriticalDefault or obvious usage is insecureverify: false default; empty password allowed
HighEasy misconfiguration breaks securityAlgorithm parameter accepts "none"
MediumUnusual but possible misconfigurationNegative timeout has unexpected meaning
LowRequires deliberate misuseObscure parameter combination

References

By category:

By language (general footguns, not crypto-specific):

See also references/language-specific.md for a combined quick reference.

Quality Checklist

Before concluding analysis:

  • [ ] Probed all zero/empty/null edge cases

  • [ ] Verified defaults are secure

  • [ ] Checked for algorithm/mode selection footguns

  • [ ] Tested type confusion between security concepts

  • [ ] Considered all three adversary types

  • [ ] Verified error paths don't bypass security

  • [ ] Checked configuration validation

  • [ ] Constructor params validated (not just defaulted) - see config-patterns.md

Files

references/language-specific.md

Language-Specific Sharp Edges

General programming footguns by language—not limited to cryptography.

C / C++

Integer Overflow is Undefined Behavior
// DANGEROUS: Signed overflow is UB, compiler can optimize away checks
int x = INT_MAX;
if (x + 1 > x) {  // Compiler may assume always true (UB)
    // Overflow check optimized away!
}

// DANGEROUS: Size calculations
size_t size = user_count * sizeof(struct User);
// If user_count * sizeof overflows, allocates tiny buffer
void *buf = malloc(size);

The Problem: Signed integer overflow is undefined behavior. Compilers assume it never happens and optimize accordingly—including removing overflow checks.

Buffer Handling
// DANGEROUS: No bounds checking
char buf[64];
strcpy(buf, user_input);      // Classic overflow
sprintf(buf, "Hello %s", name); // Format + overflow
gets(buf);                     // Never use, removed in C11

// DANGEROUS: Off-by-one
char buf[64];
strncpy(buf, src, 64);        // NOT null-terminated if src >= 64!
buf[63] = '\0';               // Must do manually
Format Strings
// DANGEROUS: User controls format
printf(user_input);           // Format string attack
syslog(LOG_INFO, user_input); // Same problem

// SAFE: Format as literal
printf("%s", user_input);
Memory Cleanup
// DANGEROUS: Secrets persist
char password[64];
// ... use password ...
memset(password, 0, sizeof(password));  // May be optimized away!

// SAFER: Use explicit_bzero or volatile
explicit_bzero(password, sizeof(password));  // Won't be optimized

Go

Silent Integer Overflow
// DANGEROUS: Overflow wraps silently (no panic!)
var x int32 = math.MaxInt32
x = x + 1  // Wraps to -2147483648, no error

// This enables vulnerabilities in:
// - Size calculations for allocations
// - Loop bounds
// - Financial calculations

The Problem: Unlike Rust (debug panics), Go silently wraps. Fuzzing may never find overflow bugs because they don't crash.

Slice Aliasing
// DANGEROUS: Slices share backing array
original := []int{1, 2, 3, 4, 5}
slice1 := original[1:3]  // {2, 3}
slice2 := original[2:4]  // {3, 4}

slice1[1] = 999  // Modifies original AND slice2!
// slice2 is now {999, 4}
Interface Nil Confusion
// DANGEROUS: Typed nil vs untyped nil
var p *MyStruct = nil
var i interface{} = p

if i == nil {
    // This is FALSE! i holds (type=*MyStruct, value=nil)
    // An interface is only nil if both type and value are nil
}

// Common in error handling:
func getError() error {
    var err *MyError = nil
    return err  // Returns non-nil error interface!
}
JSON Field Matching
// DANGEROUS: Go's JSON decoder is case-insensitive
type User struct {
    Admin bool `json:"admin"`
}

// Attacker sends: {"ADMIN": true} or {"Admin": true}
// Both match the "admin" field!

// Also: duplicate keys - last one wins
// {"admin": false, "admin": true} → Admin = true

Fix: Use DisallowUnknownFields() and consider exact-match libraries.

Defer in Loops
// DANGEROUS: All defers execute at function end, not loop iteration
for _, file := range files {
    f, _ := os.Open(file)
    defer f.Close()  // Files stay open until function returns!
}
// Can exhaust file descriptors on large loops

Rust

Integer Overflow Behavior Changes
// In debug builds: panics
// In release builds: wraps silently!
let x: u8 = 255;
let y = x + 1;  // Debug: panic! Release: y = 0

The Problem: Behavior differs between debug and release. Bugs may only manifest in production.

Fix: Use wrapping_*, checked_*, or saturating_* explicitly.

Unsafe Blocks
// DANGEROUS: Unsafe disables Rust's safety guarantees
unsafe {
    // Can create data races
    // Can dereference raw pointers
    // Can call unsafe functions
    // Can access mutable statics
}

// Common in FFI—audit all unsafe blocks carefully
Mem::forget Skips Destructors
// DANGEROUS: Resources never cleaned up
let guard = Mutex::lock().unwrap();
std::mem::forget(guard);  // Lock never released = deadlock

// Also problematic for:
// - File handles
// - Memory mappings
// - Cryptographic key cleanup
Unwrap Panics
// DANGEROUS: Panics on None/Err
let value = some_option.unwrap();  // Panics if None
let result = fallible_fn().unwrap();  // Panics if Err

// In libraries: propagate errors with ?
// In binaries: use expect() with message, or handle properly

Swift

Force Unwrapping
// DANGEROUS: Crashes on nil
let value = optionalValue!  // Runtime crash if nil

// DANGEROUS: Implicitly unwrapped optionals
var name: String!  // IUO - crashes if accessed while nil
Bridge Type Surprises
// DANGEROUS: NSString/String bridging
let nsString: NSString = "hello"
let range = nsString.range(of: "é")  // UTF-16 range
let swiftString = nsString as String
// Range semantics differ between NSString (UTF-16) and String (grapheme clusters)

Java

Equality Confusion
// DANGEROUS: Reference equality, not value equality
String a = new String("hello");
String b = new String("hello");
if (a == b) {  // FALSE - different objects
}

Integer x = 128;
Integer y = 128;
if (x == y) {  // FALSE - outside cached range [-128, 127]
}

Integer p = 127;
Integer q = 127;
if (p == q) {  // TRUE - cached, but misleading
}
Type Erasure
// DANGEROUS: Generic types erased at runtime
List<String> strings = new ArrayList<>();
List<Integer> ints = new ArrayList<>();

// At runtime, both are just "List" - no type checking
// Can cast incorrectly and get ClassCastException later

// Also: can't do runtime checks
if (obj instanceof List<String>) {  // Compile error
}
Serialization
// DANGEROUS: Like pickle, arbitrary code execution
ObjectInputStream ois = new ObjectInputStream(untrustedInput);
Object obj = ois.readObject();  // Executes readObject() on malicious classes

// "Gadget chains" in libraries enable RCE
// Even without executing readObject(), deserialization triggers code
Swallowed Exceptions
// DANGEROUS: Empty catch blocks
try {
    sensitiveOperation();
} catch (Exception e) {
    // Silently swallowed - security failure masked
}

Kotlin

Platform Types from Java
// DANGEROUS: Java returns can be null, but Kotlin doesn't know
val result = javaLibrary.getValue()  // Platform type: String!
result.length  // NPE if Java returned null!

// Kotlin trusts Java's lack of nullability annotations
Not-Null Assertion
// DANGEROUS: Throws NPE
val value = nullableValue!!  // KotlinNullPointerException if null
Lateinit Pitfalls
// DANGEROUS: Accessing before initialization throws
lateinit var config: Config

fun process() {
    config.value  // UninitializedPropertyAccessException
}

C#

Nullable Reference Types Opt-In
// DANGEROUS: NRT is opt-in, not enforced by default
// Project must enable: <Nullable>enable</Nullable>

// Even when enabled, it's warnings only by default
string? nullable = null;
string nonNull = nullable;  // Warning, not error
nonNull.Length;  // NullReferenceException at runtime
Default Struct Values
// DANGEROUS: Structs have default values that may be invalid
struct Connection {
    public string Host;  // Default: null
    public int Port;     // Default: 0
}

var conn = default(Connection);
// conn.Host is null, conn.Port is 0 - probably invalid
IDisposable Leaks
// DANGEROUS: Resources not disposed
var conn = new SqlConnection(connectionString);
conn.Open();
// Exception here = connection never closed

// SAFE: using statement
using var conn = new SqlConnection(connectionString);
conn.Open();
// Disposed even on exception

PHP

Type Juggling
// DANGEROUS: Loose comparison (==) does type coercion
"0e123" == "0e456"  // TRUE - both are 0 in scientific notation
"0" == false        // TRUE
"" == false         // TRUE
[] == false         // TRUE
null == false       // TRUE

// Magic hash comparison
"0e462097431906509019562988736854" == "0"  // TRUE
// MD5("240610708") starts with 0e... = compares as 0

// SAFE: Strict comparison (===)
"0e123" === "0e456"  // FALSE
Variable Variables and Extract
// DANGEROUS: User controls variable names
$name = $_GET['name'];
$$name = $_GET['value'];  // Variable variable - arbitrary assignment

// DANGEROUS: Extract creates variables from array
extract($_POST);  // Every POST param becomes a variable
// Attacker sends: POST isAdmin=true → $isAdmin = true
Unserialize
// DANGEROUS: Like pickle, arbitrary object instantiation
$obj = unserialize($user_input);

// Triggers __wakeup(), __destruct() on crafted objects
// Can chain to RCE via "POP gadgets" in libraries

JavaScript / TypeScript

Coercion Madness
// DANGEROUS: == coerces types unpredictably
"0" == false   // true
"" == false    // true
[] == false    // true
[] == ![]      // true (wat)

// SAFE: === for strict equality
"0" === false  // false
Prototype Pollution
// DANGEROUS: Merging untrusted objects
function merge(target, source) {
    for (let key in source) {
        target[key] = source[key];  // Includes __proto__!
    }
}

// Attacker sends: {"__proto__": {"isAdmin": true}}
merge({}, userInput);
// Now ALL objects have isAdmin === true
({}).isAdmin  // true

Fix: Check hasOwnProperty, use Object.create(null), or safe merge libraries.

Regex DoS (ReDoS)
// DANGEROUS: Catastrophic backtracking
const regex = /^(a+)+$/;
regex.test("aaaaaaaaaaaaaaaaaaaaaaaaaaaa!");
// Exponential time - freezes the event loop

// Patterns to avoid: nested quantifiers (a+)+, (a*)*
// Overlapping alternatives: (a|a)+
ParseInt Radix
// DANGEROUS: Radix not specified
parseInt("08");   // 8 in modern JS, was 0 in old (octal)
parseInt("0x10"); // 16 - hex prefix recognized

// SAFE: Always specify radix
parseInt("08", 10);  // 8

Python

Mutable Default Arguments
# DANGEROUS: Default is shared across calls
def append_to(item, target=[]):
    target.append(item)
    return target

append_to(1)  # [1]
append_to(2)  # [1, 2] - same list!

# SAFE: Use None sentinel
def append_to(item, target=None):
    if target is None:
        target = []
    target.append(item)
    return target
Eval and Friends
# DANGEROUS: Arbitrary code execution
eval(user_input)      # Executes Python expression
exec(user_input)      # Executes Python statements
compile(user_input, '', 'exec')  # Compiles for later exec

# Also via:
input()  # In Python 2, equivalent to eval(raw_input())
Late Binding Closures
# DANGEROUS: Closures capture variable by reference
funcs = []
for i in range(3):
    funcs.append(lambda: i)

[f() for f in funcs]  # [2, 2, 2] - all see final i

# SAFE: Capture by value with default argument
funcs = []
for i in range(3):
    funcs.append(lambda i=i: i)

[f() for f in funcs]  # [0, 1, 2]
Is vs ==
# DANGEROUS: 'is' checks identity, not equality
a = 256
b = 256
a is b  # True - cached small integers

a = 257
b = 257
a is b  # False - different objects!

# Same string issue:
s1 = "hello"
s2 = "hello"
s1 is s2  # True - interned

s1 = "hello world"
s2 = "hello world"
s1 is s2  # Maybe - depends on interpreter

Ruby

Dynamic Execution
# DANGEROUS: Arbitrary code execution
eval(user_input)           # Executes Ruby code
send(user_input, *args)    # Calls arbitrary method
constantize(user_input)    # Gets arbitrary constant/class
public_send(user_input)    # Calls public method by name

# Rails-specific:
params[:controller].constantize  # Class injection
YAML.load
# DANGEROUS: Arbitrary object instantiation (like pickle)
YAML.load(user_input)

# Attacker sends YAML that instantiates arbitrary objects
# Can chain to RCE via "gadget" classes

# SAFE: Use safe_load
YAML.safe_load(user_input)
Mass Assignment
# DANGEROUS: All params assigned to model
User.new(params[:user])  # If params includes {admin: true}...

# Rails 4+ requires strong parameters:
params.require(:user).permit(:name, :email)  # Explicitly allowlist

Quick Reference Table

LanguagePrimary Sharp Edges
C/C++Integer overflow UB, buffer overflows, format strings, memory cleanup
GoSilent int overflow, slice aliasing, interface nil, JSON case-insensitive
RustDebug/release overflow difference, unsafe blocks, mem::forget
SwiftForce unwrap, implicitly unwrapped optionals
Java== vs equals, type erasure, serialization, swallowed exceptions
KotlinPlatform types, !!, lateinit
C#NRT opt-in, default struct values, IDisposable leaks
PHPType juggling (==), extract(), unserialize()
JS/TS== coercion, prototype pollution, ReDoS, parseInt radix
PythonMutable defaults, eval/exec/pickle, late binding, is vs ==
Rubyeval/send/constantize, YAML.load, mass assignment

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs Python

Security

What our scanner noticed· Medium risk

  • References to credential files

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Trail of Bits
Publisher
Trail of Bits (Official)
Source
trailofbits/skills · plugins/sharp-edges/skills/sharp-edges · commit e4dd0bb
Licence
Creative Commons Attribution-ShareAlike 4.0 International (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Trail of Bits or Trail of Bits.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download sharp-edges.zip