pyro-maniac

Define and validate PyroManiac DSL configurations for Ash resources and page modules.

28|3|Updated Jan 7, 2024
One-click install
npx skills add https://github.com/frankdugan3/pyro_maniac --skill pyro-maniac
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pyro-maniac
Source: https://github.com/frankdugan3/pyro_maniac/tree/main/usage-rules/skills/pyro-maniac
Command: npx skills add https://github.com/frankdugan3/pyro_maniac --skill pyro-maniac

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

PyroManiac removes the manual overhead of designing and validating Ash Framework UI configuration by turning declarative page definitions into a compiled, inspectable DSL.

Core Features & Use Cases

  • Compile-time validation: Catch invalid UI definitions early through Spark transformers and verifiers.
  • Renderer-agnostic architecture: Define UI behavior once and pair it with a separate renderer for your stack.
  • Structured UI building blocks: Model pages, views, forms, searches, navigation, and kanban behavior in a consistent DSL.
  • Use case: Create an admin or internal app page for an Ash resource with table views, wizard forms, and navigation links without embedding rendering code in the page module.

Quick Start

Use this skill to define or update a PyroManiac page module and Ash resource so the DSL validates correctly and exposes the intended UI metadata.

Frequently Asked Questions about pyro-maniac

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

FAQPage Schema
How do I define Ash UI configurations for pages, forms, and kanban views without embedding rendering code?

Use a declarative DSL to model Ash UI configurations for pages, views, forms, searches, navigation, and kanban scenarios. This renderer-agnostic approach defines UI behavior once at compile-time, keeping rendering code separate from page modules.

Does Ash framework support compile-time validation for custom UI DSLs?

Ash UI DSLs can use Spark transformers and verifiers for compile-time validation. This catches invalid UI definitions early, ensuring strict DSL rules for view types, forms, and navigation items are enforced before runtime execution.

What is the best way to structure admin page navigation and table views for Ash resources?

The best way is using a structured UI DSL that models pages, table views, wizard forms, and navigation links as metadata. This removes manual overhead and provides a consistent, inspectable configuration for Ash resources without embedding rendering logic.

Can I use a renderer-agnostic DSL to build internal app pages with Ash resources?

Yes, you can define UI behavior in a renderer-agnostic DSL and pair it with a separate renderer for your stack. This allows creating admin or internal app pages for Ash resources with table views, wizard forms, and navigation links independently.

Why does my Ash resource UI DSL fail validation without a default label?

Strict DSL rules require a PyroManiac.Resource default label for validation to pass. This mandatory label ensures the DSL can properly identify and render Ash resources across different view types and form scenarios.

Do I need Spark to validate Ash UI page modules and view type definitions?

Yes, Spark-based compile-time validation is required to enforce strict DSL rules for view types, forms, and navigation items. This ensures all page modules and Ash resource configurations are validated correctly during compilation.