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.
Design Solidity contracts using type-driven composition instead of inheritance.
$ npx skills add ccashwell/evm-cortex --skill type-driven-design -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install ccashwell/evm-cortex type-driven-design --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ 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-srcUse ~/.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/
Install the "type-driven-design" agent skill from https://github.com/ccashwell/evm-cortex/tree/main/skills/type-driven-design into .claude/skills/type-driven-design/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "type-driven-design", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/ccashwell/evm-cortex/tree/main/skills/type-driven-designType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add ccashwell/evm-cortex --skill type-driven-design -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install ccashwell/evm-cortex type-driven-design --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ccashwell/evm-cortex.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/type-driven-design .agents/skills/type-driven-design && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "type-driven-design" agent skill from https://github.com/ccashwell/evm-cortex/tree/main/skills/type-driven-design into .agents/skills/type-driven-design/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "type-driven-design", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add ccashwell/evm-cortex --skill type-driven-design -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install ccashwell/evm-cortex type-driven-design --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ccashwell/evm-cortex.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/type-driven-design .cursor/skills/type-driven-design && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "type-driven-design" agent skill from https://github.com/ccashwell/evm-cortex/tree/main/skills/type-driven-design into .cursor/skills/type-driven-design/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "type-driven-design", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/ccashwell/evm-cortex.git --path skills/type-driven-design--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add ccashwell/evm-cortex --skill type-driven-design -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install ccashwell/evm-cortex type-driven-design --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ccashwell/evm-cortex.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/type-driven-design .gemini/skills/type-driven-design && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "type-driven-design" agent skill from https://github.com/ccashwell/evm-cortex/tree/main/skills/type-driven-design into .gemini/skills/type-driven-design/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "type-driven-design", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install ccashwell/evm-cortex type-driven-designInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add ccashwell/evm-cortex --skill type-driven-design -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/ccashwell/evm-cortex.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/type-driven-design .github/skills/type-driven-design && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "type-driven-design" agent skill from https://github.com/ccashwell/evm-cortex/tree/main/skills/type-driven-design into .github/skills/type-driven-design/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "type-driven-design", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add ccashwell/evm-cortex --skill type-driven-design -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install ccashwell/evm-cortex type-driven-design --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/ccashwell/evm-cortex.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/type-driven-design .opencode/skills/type-driven-design && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "type-driven-design" agent skill from https://github.com/ccashwell/evm-cortex/tree/main/skills/type-driven-design into .opencode/skills/type-driven-design/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "type-driven-design", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
type-driven-designDesign 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. 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.
9 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit f8f3301. It shows what the files ask for, not the result of running them.
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.
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.
Links to these hosts (documentation or services it may open):
github.comFrom URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
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.
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.
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.
The full file from ccashwell/evm-cortex at commit f8f3301, republished under its MIT licence (© ccashwell). 927 words, ~4,190 tokens.
.claude/skills/type-driven-design/SKILL.md (or your agent's skills folder).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
Inheritance-based Solidity creates problems that compound as protocols grow:
virtual/override chains break silently on refactorType-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.
Each struct wraps the minimum storage it needs. The internal field is private by convention (_inner).
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;
}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.
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;
}Higher-level types compose primitives. A Token is just Balances + Allowances + TotalSupply. Its free functions delegate to the inner types.
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:
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;
}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.
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;
}
}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 interfaceEach type lives in its own file. Each composed type imports its dependencies. The contract imports only the top-level composed type.
The key advantage: every layer is independently testable without mock contracts.
Declare the type as a storage variable directly in the test contract. No mock, no inheritance, no factory.
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);
}
}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.
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);
}
}
}Only test the external interface (events, msg.sender wiring, return values). All logic was already tested at the type layer.
Break your protocol into its independent data concerns. Each mapping, counter, or flag set becomes its own primitive type.
| Data Concern | Struct | Internal Storage |
|---|---|---|
| Per-user balances | Balances | mapping(address => uint256) |
| Approval matrix | Allowances | mapping(address => mapping(address => uint256)) |
| Global counter | TotalSupply | uint256 |
| Boolean permission | Operators | mapping(address => mapping(address => bool)) |
| Nonce tracking | Nonces | mapping(address => uint256) |
| Timelocked value | Timelock | struct { uint256 value; uint48 unlockTime; } |
| Role membership | Roles | mapping(bytes32 => mapping(address => bool)) |
Each primitive gets the minimum operations it needs. Follow a consistent pattern:
| Operation | Signature Pattern | Returns |
|---|---|---|
| Read | read(T storage self, ...) view returns (ValueType) | The stored value |
| Write | write(T storage self, ..., value) returns (T storage) | Self for chaining |
| Increase | increase(T storage self, ..., amount) returns (T storage) | Self for chaining |
| Decrease | decrease(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.
Compose primitives into types that represent your domain concepts. The composed type's functions express business logic by orchestrating calls to its inner types.
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;
}The contract handles only what free functions cannot:
msg.sender — free functions don't have access to the execution contextrequire/revert with caller checkspublic/external function signatures matching the EIPstruct 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");
}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;
}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;
}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");
}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();
}
}using for global so the functions are available everywhere without import boilerplate.self for fluent chaining. View functions return the value.is relationships. The contract composes its store as a single struct.msg.sender, emit events, enforce access control, and nothing else.Good fit:
Less ideal:
| Aspect | Inheritance | Type-Driven |
|---|---|---|
| Interface visibility | Hidden across parents | Fully explicit in contract |
| Storage layout | Scattered across tree | Visible as struct composition |
| Method override | virtual/override chains | No overrides — replace the function |
| Testing | Requires mock contracts | Direct storage variable in test |
| Code reuse | is BaseContract | using Lib for Type global |
| Refactoring risk | C3 linearization surprises | Swap a type, fix compile errors |
| Composability | Multiple inheritance limits | Arbitrary 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
Just SKILL.md in skills/type-driven-design of ccashwell/evm-cortex.
Open the folder on GitHubat commit f8f3301
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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Type Driven Design this skillccashwell/evm-cortex | 131 | — | ~4.2k | Automated safety check: Pass | MIT | |
| Fizz Convertpashov/skills | 1.2k | 2 repos | ~3.7k | Automated safety check: Pass | MIT | |
| Feynman Auditor0xiehnnkta/nemesis-auditor | 244 | 1 repos | ~11k | Automated safety check: Pass | MIT | |
| Smart Contract Auditgreatpie/smart-contract-audit-skill | 101 | — | ~1.1k | Automated safety check: Pass | None | |
| RadarAuditware/radar | 154 | — | ~2.1k | Automated safety check: Pass | GPL-3.0 | |
| Solidity AuditorGabson0x/bountyforge | 443 | — | ~3.7k | Automated safety check: Pass | None |
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.
0xiehnnkta/nemesis-auditor
Deep business logic bug finder using the Feynman technique. An agent skill from 0xiehnnkta/nemesis-auditor.
greatpie/smart-contract-audit-skill
Script-backed, out-of-box auditing workflow for Solidity/EVM repositories based on EVMbench detect/patch/exploit methodology.
Auditware/radar
Use radar for smart contract security analysis, AST generation, and detection template development.
Gabson0x/bountyforge
Security audit of Solidity code while you develop. An agent skill from Gabson0x/bountyforge.
lidofinance/diffyscan
Adds or repairs Diffyscan explorer API routing and response adapters for a new host, chain or payload format.
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.
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.
ccashwell/evm-cortex
Access control design patterns for Solidity protocols. An agent skill from ccashwell/evm-cortex.
ccashwell/evm-cortex
A skill your agent uses when running a local Ethereum node with Anvil.
ccashwell/evm-cortex
A skill your agent uses when performing systematic breadth-first review of all contracts during a security audit.
ccashwell/evm-cortex
A skill your agent uses when performing deep analysis of specific findings or high-risk areas during a security audit.
Works with
Categories
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.
Type Driven Design fits situations like: tasks that involve Smart contracts.
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.
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.
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.
SKILL.md names no scripts, command-line tools or credentials: Type Driven Design is instructions for the agent only.
SKILL.md names 1 domain. As links in the text: github.com. This is read from the text; nothing was executed.
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.
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.
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.
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.
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.