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.