Agent skill

Type Driven Design

by ccashwell in ccashwell/evm-cortex

Design Solidity contracts using type-driven composition instead of inheritance.

MITAuto-check passedBackend & APIs

Install Type Driven Design

skills CLI
$ npx skills add ccashwell/evm-cortex --skill type-driven-design -a claude-code

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

GitHub CLI
$ gh skill install ccashwell/evm-cortex type-driven-design --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/ccashwell/evm-cortex.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/type-driven-design .claude/skills/type-driven-design && 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
type-driven-design
GitHub stars
131
Token cost
~4.2k tokens
SKILL.md length
927 words
Files
1
Skills in repo
89
Repo updated
First seen
Licence
MIT

At a glance

Design Solidity contracts using type-driven composition instead of inheritance.

  • Works in 9 steps: Types Encapsulate Storage → Free Functions Define Behavior → Compose Types Into Higher-Level Types → …
  • Tasks that involve Smart contracts
  • SKILL.md covers Why This Matters, Core Principles, File Organization and Testing Strategy, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Type Driven Design is an agent skill from ccashwell/evm-cortex. Design Solidity contracts using type-driven composition instead of inheritance. Structs encapsulate storage, free functions define behavior via using for global, and contracts become thin external shells. Eliminates inheritance hell, exposes the full interface explicitly, and enables granular isolated testing at every layer of composition. Based on JT Riley's type-driven-tokens pattern.

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

It sits in Backend & APIs, covering Smart contracts. It works with Solidity. The repository describes itself as: Ethereum protocol engineering squad for AI coding assistants. The licence is MIT.

When your agent uses it

  • Tasks that involve Smart contracts

Example prompts

  • “/type-driven-design”

Workflow steps

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

  1. Types Encapsulate Storage
  2. Free Functions Define Behavior
  3. Compose Types Into Higher-Level Types
  4. Contracts Are Thin Shells
  5. Identify Storage Concerns
  6. Define Primitive Operations
  7. Compose Into Domain Types
  8. Write the Contract Shell
  9. Test Bottom-Up

What it can do on your machine

Read from SKILL.md and the folder at commit f8f3301. 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 solidity).

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

  • Network

    Links to these hosts (documentation or services it may open):

    • github.com

    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

Type Driven Design loads about 4.2k tokens when it runs. Until then it costs about 103 tokens; SKILL.md has 927 words of instructions outside code blocks.

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

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 ccashwell/evm-cortex at commit f8f3301, republished under its MIT licence (© ccashwell). 927 words, ~4,190 tokens.

Download SKILL.mdSave it as .claude/skills/type-driven-design/SKILL.md (or your agent's skills folder).
name
type-driven-design
description
Design Solidity contracts using type-driven composition instead of inheritance. Structs encapsulate storage, free functions define behavior via `using for global`, and contracts become thin external shells. Eliminates inheritance hell, exposes the full interface explicitly, and enables granular isolated testing at every layer of composition. Based on JT Riley's type-driven-tokens pattern.

Type-Driven Solidity Design

Type-driven design replaces object inheritance with struct composition and free functions. Instead of deep inheritance trees where storage layouts are hidden and method overriding is opaque, each data concern is a standalone struct with free functions bound via using ... for ... global. Contracts compose these types and serve only as the external interface.

Reference implementation: jtriley2p/type-driven-tokens

Why This Matters

Inheritance-based Solidity creates problems that compound as protocols grow:

  • Hidden interfaces — parent contracts add external/public functions implicitly
  • Storage layout opacity — storage slots are scattered across an inheritance tree
  • Method override fragility — virtual/override chains break silently on refactor
  • Testing requires mocks — abstract contracts can't be tested without mock inheritors
  • Inheritance hell — diamond inheritance, linearization surprises, C3 ambiguity

Type-driven design eliminates all of these. The entire external interface is explicit in one contract. Storage is visible as struct composition. Each component is independently testable without mocks.

Core Principles

1. Types Encapsulate Storage

Each struct wraps the minimum storage it needs. The internal field is private by convention (_inner).

solidity
struct Balances {
    mapping(address => uint256) _inner;
}

struct TotalSupply {
    uint256 _inner;
}

struct Allowances {
    mapping(address => mapping(address => uint256)) _inner;
}

struct Operators {
    mapping(address => mapping(address => bool)) _inner;
}
2. Free Functions Define Behavior

Behavior is defined as free functions (file-level, outside any contract) bound to the struct with using ... for ... global. Every mutating function takes Type storage self and returns Type storage for fluent chaining.

solidity
using { read, write, increase, decrease } for Balances global;

function read(Balances storage self, address account) view returns (uint256) {
    return self._inner[account];
}

function write(Balances storage self, address account, uint256 amount) returns (Balances storage) {
    self._inner[account] = amount;
    return self;
}

function increase(Balances storage self, address account, uint256 amount) returns (Balances storage) {
    self._inner[account] += amount;
    return self;
}

function decrease(Balances storage self, address account, uint256 amount) returns (Balances storage) {
    self._inner[account] -= amount;
    return self;
}
3. Compose Types Into Higher-Level Types

Higher-level types compose primitives. A Token is just Balances + Allowances + TotalSupply. Its free functions delegate to the inner types.

solidity
struct Token {
    Allowances allowances;
    Balances balances;
    TotalSupply supply;
}

using { balanceOf, totalSupply, allowance, mint, burn, transfer, transferFrom, approve } for Token global;

function mint(Token storage self, address receiver, uint256 amount) returns (Token storage) {
    self.balances.increase(receiver, amount);
    self.supply.increase(amount);
    return self;
}

function transfer(
    Token storage self,
    address sender,
    address receiver,
    uint256 amount
) returns (Token storage) {
    self.balances.decrease(sender, amount);
    self.balances.increase(receiver, amount);
    return self;
}

function transferFrom(
    Token storage self,
    address spender,
    address sender,
    address receiver,
    uint256 amount
) returns (Token storage) {
    if (spender != sender) self.allowances.decrease(sender, spender, amount);
    self.balances.decrease(sender, amount);
    self.balances.increase(receiver, amount);
    return self;
}

Multi-token types compose further — a MultiToken maps token IDs to Token instances and adds an Operators layer:

solidity
struct MultiToken {
    mapping(uint256 => Token) tokens;
    Operators operators;
}

using { balanceOf, totalSupply, mint, burn, transfer, transferFrom, approve, setOperator } for MultiToken global;

function transfer(
    MultiToken storage self,
    uint256 id,
    address sender,
    address receiver,
    uint256 amount
) returns (MultiToken storage) {
    self.tokens[id].transfer(sender, receiver, amount);
    return self;
}
4. Contracts Are Thin Shells

The contract's only job is to wire msg.sender, emit events, enforce access control, and expose the external interface. All logic lives in the type layer.

solidity
contract ERC20 {
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);

    Token internal self;

    function transfer(address receiver, uint256 amount) public returns (bool) {
        self.transfer(msg.sender, receiver, amount);
        emit Transfer(msg.sender, receiver, amount);
        return true;
    }

    function transferFrom(address sender, address receiver, uint256 amount) public returns (bool) {
        self.transferFrom(msg.sender, sender, receiver, amount);
        emit Transfer(sender, receiver, amount);
        return true;
    }

    function approve(address spender, uint256 amount) public returns (bool) {
        self.approve(msg.sender, spender, amount);
        emit Approval(msg.sender, spender, amount);
        return true;
    }
}

File Organization

src/
├── types/
│   ├── Balances.sol        # Primitive: address → uint256 mapping
│   ├── Allowances.sol      # Primitive: owner → spender → uint256
│   ├── TotalSupply.sol     # Primitive: single uint256
│   ├── Operators.sol       # Primitive: owner → operator → bool
│   ├── Token.sol           # Composed: Balances + Allowances + TotalSupply
│   └── MultiToken.sol      # Composed: mapping(id => Token) + Operators
├── ERC20.sol               # Contract shell using Token
└── ERC6909.sol             # Contract shell using MultiToken
test/
├── Balances.t.sol          # Test primitive in isolation
├── Allowances.t.sol        # Test primitive in isolation
├── TotalSupply.t.sol       # Test primitive in isolation
├── Operators.t.sol         # Test primitive in isolation
├── Token.t.sol             # Test composed type
└── ERC20.t.sol             # Test external interface

Each type lives in its own file. Each composed type imports its dependencies. The contract imports only the top-level composed type.

Testing Strategy

The key advantage: every layer is independently testable without mock contracts.

Test Primitives in Isolation

Declare the type as a storage variable directly in the test contract. No mock, no inheritance, no factory.

solidity
contract BalancesTest is Test {
    Balances internal balances;
    address internal alice = vm.addr(1);

    function testIncrease() public {
        balances.increase(alice, 100);
        assertEq(balances.read(alice), 100);
    }

    function testDecreaseUnderflow() public {
        vm.expectRevert();
        balances.decrease(alice, 1);
    }

    function testFuzzIncrease(address account, uint256 a, uint256 b) public {
        bool overflow = type(uint256).max - a < b;
        balances.increase(account, a);
        if (overflow) vm.expectRevert();
        balances.increase(account, b);
        if (!overflow) assertEq(balances.read(account), a + b);
    }
}
Test Composed Types

The composed type is also just a storage variable. Test its functions, which delegate to the primitives. Use .write() on inner types for state setup.

solidity
contract TokenTest is Test {
    Token internal token;
    address internal alice = vm.addr(1);
    address internal bob = vm.addr(2);

    function testMint() public {
        token.mint(alice, 100);
        assertEq(token.balanceOf(alice), 100);
        assertEq(token.totalSupply(), 100);
    }

    function testTransferFrom() public {
        token.mint(alice, 100);
        token.approve(alice, bob, 50);
        token.transferFrom(bob, alice, bob, 50);
        assertEq(token.balanceOf(bob), 50);
        assertEq(token.allowance(alice, bob), 0);
    }

    function testFuzzTransfer(address sender, address receiver, uint256 mintAmt, uint256 xferAmt) public {
        vm.assume(sender != receiver);
        bool underflow = mintAmt < xferAmt;
        token.mint(sender, mintAmt);
        if (underflow) vm.expectRevert();
        token.transfer(sender, receiver, xferAmt);
        if (!underflow) {
            assertEq(token.balanceOf(sender), mintAmt - xferAmt);
            assertEq(token.balanceOf(receiver), xferAmt);
        }
    }
}
Test the Contract Shell

Only test the external interface (events, msg.sender wiring, return values). All logic was already tested at the type layer.

Designing Your Own Types

Step 1 — Identify Storage Concerns

Break your protocol into its independent data concerns. Each mapping, counter, or flag set becomes its own primitive type.

Data ConcernStructInternal Storage
Per-user balancesBalancesmapping(address => uint256)
Approval matrixAllowancesmapping(address => mapping(address => uint256))
Global counterTotalSupplyuint256
Boolean permissionOperatorsmapping(address => mapping(address => bool))
Nonce trackingNoncesmapping(address => uint256)
Timelocked valueTimelockstruct { uint256 value; uint48 unlockTime; }
Role membershipRolesmapping(bytes32 => mapping(address => bool))
Step 2 — Define Primitive Operations

Each primitive gets the minimum operations it needs. Follow a consistent pattern:

OperationSignature PatternReturns
Readread(T storage self, ...) view returns (ValueType)The stored value
Writewrite(T storage self, ..., value) returns (T storage)Self for chaining
Increaseincrease(T storage self, ..., amount) returns (T storage)Self for chaining
Decreasedecrease(T storage self, ..., amount) returns (T storage)Self for chaining

Not every type needs all four. A boolean toggle only needs read and write. A monotonic counter might only need read and increase.

Show full SKILL.md (382 more words)Show less
Step 3 — Compose Into Domain Types

Compose primitives into types that represent your domain concepts. The composed type's functions express business logic by orchestrating calls to its inner types.

solidity
struct Vault {
    Balances shares;
    Balances assets;
    TotalSupply totalShares;
    TotalSupply totalAssets;
}

using { deposit, withdraw, sharePrice } for Vault global;

function deposit(Vault storage self, address depositor, uint256 assetAmount) returns (Vault storage) {
    uint256 shareAmount = _convertToShares(self, assetAmount);
    self.assets.increase(depositor, assetAmount);
    self.totalAssets.increase(assetAmount);
    self.shares.increase(depositor, shareAmount);
    self.totalShares.increase(shareAmount);
    return self;
}

function sharePrice(Vault storage self) view returns (uint256) {
    uint256 supply = self.totalShares.read();
    if (supply == 0) return 1e18;
    return (self.totalAssets.read() * 1e18) / supply;
}
Step 4 — Write the Contract Shell

The contract handles only what free functions cannot:

  • msg.sender — free functions don't have access to the execution context
  • Events — free functions can't emit events
  • Access control — require/revert with caller checks
  • External interfaces — public/external function signatures matching the EIP
Step 5 — Test Bottom-Up
  1. Test each primitive type in isolation (read, write, increase, decrease, overflow, underflow)
  2. Test each composed type (business logic, invariant preservation)
  3. Test the contract shell (events, access control, msg.sender wiring)
  4. Fuzz at every level — primitive fuzz tests are cheap and catch edge cases early

Patterns for Common Concerns

Access Control
solidity
struct Owner {
    address _inner;
}

using { read, write, onlyOwner } for Owner global;

function read(Owner storage self) view returns (address) {
    return self._inner;
}

function write(Owner storage self, address newOwner) returns (Owner storage) {
    self._inner = newOwner;
    return self;
}

function onlyOwner(Owner storage self, address caller) view {
    require(caller == self._inner, "not owner");
}
Reentrancy Guard
solidity
struct Lock {
    uint256 _inner;
}

using { acquire, release } for Lock global;

function acquire(Lock storage self) returns (Lock storage) {
    require(self._inner == 0, "locked");
    self._inner = 1;
    return self;
}

function release(Lock storage self) returns (Lock storage) {
    self._inner = 0;
    return self;
}
Nonces (Replay Protection)
solidity
struct Nonces {
    mapping(address => uint256) _inner;
}

using { current, use } for Nonces global;

function current(Nonces storage self, address account) view returns (uint256) {
    return self._inner[account];
}

function use(Nonces storage self, address account) returns (uint256 nonce) {
    nonce = self._inner[account];
    self._inner[account] = nonce + 1;
}
Pausable
solidity
struct Paused {
    bool _inner;
}

using { isPaused, pause, unpause, whenNotPaused } for Paused global;

function isPaused(Paused storage self) view returns (bool) {
    return self._inner;
}

function pause(Paused storage self) returns (Paused storage) {
    self._inner = true;
    return self;
}

function unpause(Paused storage self) returns (Paused storage) {
    self._inner = false;
    return self;
}

function whenNotPaused(Paused storage self) view {
    require(!self._inner, "paused");
}
Full Protocol Composition
solidity
struct ProtocolStore {
    Owner owner;
    Lock lock;
    Paused paused;
    Token token;
    Nonces nonces;
}

contract Protocol {
    ProtocolStore internal self;

    function transfer(address to, uint256 amount) external {
        self.paused.whenNotPaused();
        self.lock.acquire();
        self.token.transfer(msg.sender, to, amount);
        self.lock.release();
        emit Transfer(msg.sender, to, amount);
    }

    function pause() external {
        self.owner.onlyOwner(msg.sender);
        self.paused.pause();
    }
}

Rules

  1. One struct per storage concern. If two mappings serve different purposes, they get different types.
  2. Free functions only. No methods on contracts or abstract contracts for core logic.
  3. using for global so the functions are available everywhere without import boilerplate.
  4. Mutators return self for fluent chaining. View functions return the value.
  5. No inheritance. Zero is relationships. The contract composes its store as a single struct.
  6. Contracts are thin. They wire msg.sender, emit events, enforce access control, and nothing else.
  7. Test bottom-up. Primitives first, compositions second, contract shell last.
  8. Fuzz everything. Primitive types are especially cheap to fuzz — overflow, underflow, and boundary conditions.

When to Use This Pattern

Good fit:

  • Token standards (ERC-20, ERC-721, ERC-1155, ERC-6909)
  • Vault/staking contracts with share accounting
  • Protocols with clearly separable data concerns
  • Systems where testing granularity matters
  • Greenfield contracts where you control the architecture

Less ideal:

  • Integrating with existing inheritance-based libraries (OpenZeppelin)
  • Contracts that must inherit from required base contracts (ERC-721Receiver callbacks)
  • Very simple single-purpose contracts where the overhead isn't justified

Comparison With Inheritance

AspectInheritanceType-Driven
Interface visibilityHidden across parentsFully explicit in contract
Storage layoutScattered across treeVisible as struct composition
Method overridevirtual/override chainsNo overrides — replace the function
TestingRequires mock contractsDirect storage variable in test
Code reuseis BaseContractusing Lib for Type global
Refactoring riskC3 linearization surprisesSwap a type, fix compile errors
ComposabilityMultiple inheritance limitsArbitrary struct nesting

© ccashwell, 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 skills/type-driven-design of ccashwell/evm-cortex.

Open the folder on GitHubat commit f8f3301

Compare with similar skills

Type Driven Design 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.

Type Driven Design compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Type Driven Design this skillccashwell/evm-cortex131—~4.2kAutomated safety check: PassMIT
Fizz Convertpashov/skills1.2k2 repos~3.7kAutomated safety check: PassMIT
Feynman Auditor0xiehnnkta/nemesis-auditor2441 repos~11kAutomated safety check: PassMIT
Smart Contract Auditgreatpie/smart-contract-audit-skill101—~1.1kAutomated safety check: PassNone
RadarAuditware/radar154—~2.1kAutomated safety check: PassGPL-3.0
Solidity AuditorGabson0x/bountyforge443—~3.7kAutomated safety check: PassNone

Similar skills

  • Fizz Convert

    pashov/skills

    Convert English-language properties in PROPERTIES.md (produced by the Fizz skill) into Solidity assertions inside the existing fuzz harness, then flip their checkboxes.

    1.2k GitHub starsUsed in 2 repos~3.7k tokens
    Backend & APIsAuto-check passed
  • Feynman Auditor

    0xiehnnkta/nemesis-auditor

    Deep business logic bug finder using the Feynman technique. An agent skill from 0xiehnnkta/nemesis-auditor.

    244 GitHub starsUsed in 1 repo~11k tokens
    Backend & APIsAuto-check passed
  • Smart Contract Audit

    greatpie/smart-contract-audit-skill

    Script-backed, out-of-box auditing workflow for Solidity/EVM repositories based on EVMbench detect/patch/exploit methodology.

    101 GitHub stars~1.1k tokensUpdated 7 mo ago
    Backend & APIsAuto-check passed
  • Radar

    Auditware/radar

    Use radar for smart contract security analysis, AST generation, and detection template development.

    154 GitHub stars~2.1k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed
  • Solidity Auditor

    Gabson0x/bountyforge

    Security audit of Solidity code while you develop. An agent skill from Gabson0x/bountyforge.

    443 GitHub stars~3.7k tokensUpdated 20 days ago
    Backend & APIsAuto-check passed
  • Add Explorer

    lidofinance/diffyscan

    Adds or repairs Diffyscan explorer API routing and response adapters for a new host, chain or payload format.

    142 GitHub stars~1k tokensUpdated yesterday
    Backend & APIsAuto-check passed

More from ccashwell/evm-cortex

All 89 skills in this repo
  • Xray Pre Audit

    ccashwell/evm-cortex

    A skill your agent uses when preparing for a security audit, performing reconnaissance on a new codebase, or creating a protocol overview.

    131 GitHub stars~25k tokensUpdated 7 days ago
    Auto-check passed
  • Aave Integration

    ccashwell/evm-cortex

    A skill your agent uses when integrating with Aave V3 for lending, borrowing, flash loans, or building on top of Aave markets.

    131 GitHub stars~1.3k tokensUpdated 7 days ago
    Auto-check passed
  • Access Control Patterns

    ccashwell/evm-cortex

    Access control design patterns for Solidity protocols. An agent skill from ccashwell/evm-cortex.

    131 GitHub stars~1.8k tokensUpdated 7 days ago
    Auto-check passed
  • Anvil Patterns

    ccashwell/evm-cortex

    A skill your agent uses when running a local Ethereum node with Anvil.

    131 GitHub stars~1.3k tokensUpdated 7 days ago
    Auto-check passed
  • Audit Breadth Scan

    ccashwell/evm-cortex

    A skill your agent uses when performing systematic breadth-first review of all contracts during a security audit.

    131 GitHub stars~1.4k tokensUpdated 7 days ago
    Auto-check passed
  • Audit Depth Analysis

    ccashwell/evm-cortex

    A skill your agent uses when performing deep analysis of specific findings or high-risk areas during a security audit.

    131 GitHub stars~1.6k tokensUpdated 7 days ago
    Auto-check passed

Works with

Categories

Questions about Type Driven Design

What does Type Driven Design do?

Design Solidity contracts using type-driven composition instead of inheritance. Type Driven Design is an agent skill from ccashwell/evm-cortex. Design Solidity contracts using type-driven composition instead of inheritance.

When should I use Type Driven Design?

Type Driven Design fits situations like: tasks that involve Smart contracts.

How do I install Type Driven Design in Claude Code?

Run `npx skills add ccashwell/evm-cortex --skill type-driven-design -a claude-code`. Or copy the skill folder (skills/type-driven-design in ccashwell/evm-cortex) into .claude/skills/type-driven-design in your project. Claude Code loads it when a task matches its description.

How do I install Type Driven Design in Codex?

Run `npx skills add ccashwell/evm-cortex --skill type-driven-design -a codex`. Or copy the skill folder (skills/type-driven-design in ccashwell/evm-cortex) into .agents/skills/type-driven-design in your project. Codex loads it when a task matches its description.

Can I use Type Driven Design 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 ccashwell/evm-cortex --skill type-driven-design -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/type-driven-design, .gemini/skills/type-driven-design, .github/skills/type-driven-design and .opencode/skills/type-driven-design in your project.

What does Type Driven Design need to run?

SKILL.md names no scripts, command-line tools or credentials: Type Driven Design is instructions for the agent only.

Does Type Driven Design access the network?

SKILL.md names 1 domain. As links in the text: github.com. This is read from the text; nothing was executed.

Is Type Driven Design 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 Type Driven Design use?

Type Driven Design 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 Type Driven Design use?

About 4.2k tokens (SKILL.md is roughly 17k 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 Type Driven Design?

Skills that share tags, products or a category with Type Driven Design: Fizz Convert (pashov/skills, 1.2k stars), Feynman Auditor (0xiehnnkta/nemesis-auditor, 244 stars), Smart Contract Audit (greatpie/smart-contract-audit-skill, 101 stars) and Radar (Auditware/radar, 154 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Type Driven Design?

ccashwell (a GitHub user) maintains it in ccashwell/evm-cortex, which has 131 GitHub stars. The repository holds 89 skills in this directory. The repository was last updated on September 30, 2026.

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