Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/dafthunk-com/dafthunk/node-generatornpx skills add dafthunk-com/dafthunk --skill node-generatorgit clone --depth 1 https://github.com/dafthunk-com/dafthunkWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00015 | $0.02320 |
| Opus 5 | $0.00008 | $0.01160 |
| Sonnet 5 | $0.00003 | $0.00464 |
| Haiku 4.5 | $0.00002 | $0.00232 |
Grade A, and why
node-generator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 284 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Node Generator Skill
Generate workflow nodes for Dafthunk: research requirements, create implementation and tests, register in the node registry.
Step 1: Research and Define Requirements
When a user requests a new node, research first, then present a complete specification for confirmation.
Research the functionality:
- If based on a library/API: Use WebSearch or WebFetch to find official documentation
- Look for function signatures, parameters, return types, and examples
- Check if the package exists in
apps/api/package.jsonor search npm for the latest version
Check existing patterns:
- Search
packages/runtime/src/nodes/<category>/for similar nodes - Examine 2-3 similar implementations to understand input/output patterns and validation approaches
Draft complete requirements:
- Node purpose, category, name, and kebab-case ID
- Inputs: names, types, descriptions, required/optional, defaults, repeated (from function signature/docs)
- Outputs: primary outputs and metadata outputs (hidden: true for counts, flags, etc.)
- Icon: appropriate lucide icon name
- Tags: category + relevant keywords
- Dependencies: package name and version if needed
Present for confirmation:
Based on [library/API/functionality], here's the proposed node:
**Name**: [Node Name]
**ID**: `node-id`
**Category**: category
**Icon**: icon-name
**Inputs**:
- `inputName` (type, required/optional): Description
**Outputs**:
- `outputName` (type): Description
- `metadata` (type, hidden): Description
**Dependencies**:
- package-name@^version
**Tags**: Category, Tag1, Tag2
Does this match your requirements?
Only ask for information you cannot reasonably infer or research. The goal is to present a complete, research-backed specification that the user only needs to approve or tweak.
Step 2: Create Node Implementation
File: packages/runtime/src/nodes/<category>/<node-id>.ts
import { NodeExecution, NodeType } from "@dafthunk/types";
import { ExecutableNode, NodeContext } from "../../runtime/node-types";
export class [NodeClassName]Node extends ExecutableNode {
public static readonly nodeType: NodeType = {
id: "[node-id]",
name: "[Node Display Name]",
type: "[node-id]",
description: "[One-line description]",
tags: ["Category", "Tag1", "Tag2"],
icon: "[icon-name]",
documentation: "[Detailed documentation]",
inlinable: false,
asTool: false,
inputs: [
{
name: "[inputName]",
type: "[type]",
description: "[Description]",
required: true,
repeated: false,
},
],
outputs: [
{
name: "[outputName]",
type: "[type]",
description: "[Description]",
},
],
};
public async execute(context: NodeContext): Promise<NodeExecution> {
try {
const { input1, optionalInput = "default" } = context.inputs;
// Validate required inputs
if (input1 === null || input1 === undefined) {
return this.createErrorResult("Missing required input: input1");
}
if (typeof input1 !== "expectedType") {
return this.createErrorResult(
`Invalid input type for input1: expected expectedType, got ${typeof input1}`
);
}
// Handle repeated inputs (arrays)
if (Array.isArray(input1)) {
for (let i = 0; i < input1.length; i++) {
if (typeof input1[i] !== "string") {
return this.createErrorResult(
`Invalid input at position ${i}: expected string, got ${typeof input1[i]}`
);
}
}
}
// Main logic
const result = processInput(input1);
return this.createSuccessResult({ output1: result });
} catch (err) {
const error = err as Error;
return this.createErrorResult(`Error in [NodeName]: ${error.message}`);
}
}
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 284 lines · 15 tokens per session scan A a68a326c4a74
node-generator is a skill published in the GitHub repository dafthunk-com/dafthunk (119 stars, last pushed 6d ago), licensed MIT. It adds 15 tokens to every session and 2,320 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
potpie-graph
Use when the task can read or write the project-memory graph through the potpie CLI: discover the contract with graph catalog, read named views with graph read, resolve entity identity with graph search-entities, create validated plans with graph propose, commit plans with graph commit --verify, inspect quality with…
potpie-source-ingestion
Use when the user explicitly asks to ingest, refresh, or deeply understand a repository, PR, issue, ticket, runbook, incident report, document, or web link into Potpie. The harness performs todo-driven discovery, uses local/GitHub/integration tools and read-only subagents when available, builds evidence-backed…
potpie-repo-baseline
Use when establishing, refreshing, or deeply understanding a repository's baseline memory in Potpie: purpose, application type, features, services/modules, environments, deploy shape, dependencies, API contracts, datastores, integrations, ownership, and explicit preferences. The harness reads authored and…
graph-mutation-plan
Cookbook for composing an applygraphmutations plan — stable entitykey patterns, the canonical label/edge vocabulary, evidence/invalidation/confidence discipline, and a worked example. Load this when building a non-trivial mutation plan.
potpie-cli
Use when the task is centered on running, explaining, configuring, or troubleshooting the potpie command: doctor, login, pot management, source registration, search, graph workbench reads/writes, and pot scope behavior.
potpie-change-timeline
Use when an agent needs recent or historical change context: what changed recently, regressions, merged PRs, tickets, docs, incidents, deployments, releases, and source-history ingestion.