Guide for implementing, registering, and testing new pipeline node types and handlers in the Dark Factory DOT runner.
Scanned 8/31/2026
Install to Claude Code
npx -y skills add jleechanorg/dark-factory --skill dark-factory-node-type --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Dark Factory Node Type?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/jleechanorg-dark-factory-node-type)More formats (shields.io, HTML) on the badges page.
---
name: dark-factory-node-type
description: "Guide for implementing, registering, and testing new pipeline node types and handlers in the Dark Factory DOT runner."
---
# Adding a New Node Type in Dark Factory
Use this skill when extending the Dark Factory pipeline engine with a new node type, custom execution handler, or graph shape mapping in `runner/handlers.py`.
## When to use
- Adding a new handler function to `runner/handlers.py`.
- Registering a custom handler in `TYPE_REGISTRY` or `REGISTRY`.
- Referencing a new handler in `.dot` pipeline graphs via `type="..."` or custom node shape.
- Writing echo-backend unit tests to exercise custom handler outcomes and state mutations.
## Procedure
1. **Implement the handler:**
Implement `_my_handler(node, ctx) -> Result` in `runner/handlers.py`.
2. **Register the handler:**
Register in `TYPE_REGISTRY` (preferred — keyed by `type="..."`) or `REGISTRY` (keyed by DOT shape).
3. **Reference from a pipeline graph:**
Reference from a `.dot` file with `mynode [type="my_handler", ...]`.
4. **Add echo-backend unit tests:**
Echo-backend tests should drive paths via `ctx.state["<node>.outcome"]` — see `tests/test_gates.py`.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!
Practical guide to testing web applications with screen readers for comprehensive accessibility validation.
Plan a weekly editorial calendar by mapping company goals to publishable topics, owners, status, and verification notes.
Run, verify, reseed, and repair Paperclip isolated dev workspace services. Use when asked to start or fix a managed project/worktree service and prove health, login readiness, cloned data, runtime visibility, and correct port ownership.
Prepare a Paperclip branch for PR with commits, template body, and checks.
Produce QA acceptance criteria and a manual validation plan for a feature change — golden path, edge cases, error states, performance limits, and explicit pass/fail evidence.