rule-forms-vertical

Standardize and validate Grants.gov form schemas across API and frontend.

1|1|Updated Mar 31, 2026
One-click install
npx skills add https://github.com/btabaska/simpler-grants-documentation-automation --skill rule-forms-vertical
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rule-forms-vertical
Source: https://github.com/btabaska/simpler-grants-documentation-automation/tree/main/.claude/skills/rule-forms-vertical
Command: npx skills add https://github.com/btabaska/simpler-grants-documentation-automation --skill rule-forms-vertical

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Grants.gov form development spans multiple repos and requires strict consistency across API schemas, UI rendering, and business rules. This rule set ensures a standardized, validated approach to building and maintaining grant application forms, reducing drift and errors during updates.

Core Features & Use Cases

  • Enforces three-schema form definitions (FORM_JSON_SCHEMA, FORM_UI_SCHEMA, FORM_RULE_SCHEMA) co-located with a static Form instance registered in get_active_forms(), ensuring consistent validation, rendering, and business rules across code paths.
  • Uses a custom JSON schema validator to extend Draft2020-12, with strict required-field checks and proactive validation to catch schema issues before deployment.
  • Fail loudly on invalid schemas by validating schema structure prior to use and surfacing errors as logs or exceptions to prevent silent failures.
  • Provides declarative XML transform rules with required _metadata namespaces, preserving compatibility with Grants.gov XML outputs and enabling deterministic transformation.
  • Maintains legacy XML fidelity by verifying the order and presence of legacy XML elements to match XSD expectations.
  • Supports non-blocking validation by returning validation issues as warnings during PUT/save operations, allowing progressive refinement without blocking user actions.
  • Encourages end-to-end testing practices with a Page Object Model for E2E form tests and a triad of minimal/full/empty JSON validations.
  • Includes guidance for context enrichment and cross-rule references to ensure consistency with broader forms architecture rules.

Quick Start

Edit grant form schemas by defining three co-located schemas and a static Form instance, then validate with the custom validator before deployment.

Frequently Asked Questions about rule-forms-vertical

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

FAQPage Schema
How do I validate grant application form schemas for Grants.gov?

You can validate grant application form schemas using a custom JSON schema validator that extends Draft2020-12, enforcing strict required-field checks and proactive validation to catch schema issues before deployment.

What is the three-schema approach for form definitions?

The three-schema approach co-locates FORM_JSON_SCHEMA, FORM_UI_SCHEMA, and FORM_RULE_SCHEMA with a static Form instance registered in get_active_forms(), ensuring consistent validation, rendering, and business rules across API and frontend code paths.

How do I maintain legacy XML fidelity when transforming Grants.gov form data?

Maintain legacy XML fidelity by using declarative XML transform rules with required _metadata namespaces, verifying the order and presence of legacy XML elements to match XSD expectations for deterministic transformation.

Can I return validation issues as warnings without blocking form save operations?

Yes, you can use non-blocking validation to return validation issues as warnings during PUT/save operations, allowing progressive refinement of grant forms without blocking user actions.

What testing practices should I use for Grants.gov form schemas?

Use a Page Object Model for E2E form tests and run a triad of minimal, full, and empty JSON validations to ensure schema robustness across API and frontend integration points.

Why do my form schemas fail silently during Grants.gov updates?

Schemas fail silently when validation is not enforced prior to use; this approach validates schema structure proactively and fails loudly by surfacing errors as logs or exceptions to prevent silent failures during updates.