dsl-coding

Implement EdgionDSL plugin builtins with defined variable and error semantics.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/Pandaala/Edgion --skill dsl-coding
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dsl-coding
Source: https://github.com/Pandaala/Edgion/tree/main/skills/03-coding/dsl
Command: npx skills add https://github.com/Pandaala/Edgion --skill dsl-coding

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill reduces the friction of implementing and extending EdgionDSL plugins by giving maintainers exact, contract-driven guidance for wiring new builtins and their runtime semantics. It prevents subtle behavior regressions by documenting how path/URI/query variables, VM lifecycle, and error-handling shapes must behave.

Core Features & Use Cases

  • Builtin implementation guidance for EdgionDSL, including how to use existing builtins from both script-author and gateway-developer perspectives.
  • Path/URI/query variable reference that explains what req.* values represent, how rewrites affect them, and what normalization implies for matching and rewrite behavior.
  • Safe outbound capability implementation via http.call() builtin guidance, including return shapes, SSRF protection, config limits, and async VM execution details.
  • Redis builtin implementation via redis.* guidance, including LinkSys alias resolution, Map { ok, value, error } return shapes, and a step-by-step recipe to add new redis operations.
  • Error semantics lock-in detailing when DSL builtins silently fall back versus when they raise RuntimeError::TypeError or RuntimeError::ApiError, preserving deployed-script behavior.

Quick Start

Tell your AI to produce a new EdgionDSL redis.* builtin that follows the existing Map { ok, value, error } contract and includes the required lock-in tests to preserve silent-fallback semantics.

Frequently Asked Questions about dsl-coding

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement SSRF protection for outbound http.call builtins in a DSL runtime?

Safe DSL builtins require strict error semantics, using silent fallbacks for non-critical failures and raising RuntimeError::TypeError or RuntimeError::ApiError for contract violations. This preserves deployed-script behavior by ensuring deterministic runtime execution.

How do I add a new Redis operation to EdgionDSL builtins?

To add a new Redis builtin, follow the step-by-step recipe to map the operation to the DslRuntime, resolve LinkSys aliases, and return a Map { ok, value, error } structure. This guarantees stable error-handling and deterministic script behavior.

What do req.* path and query variables represent in EdgionDSL?

The req.* variables represent path, URI, and query values within the VM runtime, which are affected by rewrites and normalization. Understanding these variables is essential for correct matching behavior and implementing stable builtins.

When should DSL builtins raise an ApiError instead of silently falling back?

DSL builtins should raise RuntimeError::ApiError or RuntimeError::TypeError when strict contract violations occur, while using silent fallbacks for non-critical missing values. Locking in these error semantics prevents subtle behavior regressions in deployed scripts.

Can I map new namespaces to DslRuntime fields when extending DSL builtins?

Yes, you can map new namespaces to DslRuntime fields when wiring new req.*, http.*, or redis.* builtins. This process requires following the documented builtin shapes and return-value structures to ensure correct variable semantics in the VM runtime.