FOSMVVM Fields Generator
Generate Form Specifications following FOSMVVM patterns.
Conceptual Foundation
For full architecture context, see FOSMVVMArchitecture.md | OpenClaw reference
A Form Specification (implemented as a {Name}Fields protocol) is the single source of truth for user input. It answers:
- What data can the user provide? (properties)
- How should it be presented? (FormField with type, keyboard, autofill semantics)
- What constraints apply? (validation rules)
- What messages should be shown? (localized titles, placeholders, errors)
Why This Matters
The Form Specification is defined once, used everywhere:
swift
1// Same protocol adopted by different consumers:
2struct CreateIdeaRequestBody: ServerRequestBody, IdeaFields { ... } // HTTP transmission
3@ViewModel struct IdeaFormViewModel: IdeaFields { ... } // Form rendering
4final class Idea: Model, IdeaFields { ... } // Persistence validation
This ensures:
- Consistent validation - Same rules on client and server
- Shared localization - One YAML file, used everywhere
- Single source of truth - Change once, applies everywhere
Connection to FOSMVVM
Form Specifications integrate with:
- Localization System - FormField titles/placeholders and validation messages use
LocalizableString
- Validation System - Implements
ValidatableModel protocol
- Request System - RequestBody types adopt Fields for validated transmission
- ViewModel System - ViewModels adopt Fields for form rendering
When to Use This Skill
- Defining a new form (create, edit, filter, search)
- Adding validation to a request body
- Any type that needs to conform to
ValidatableModel
- When
fosmvvm-fluent-datamodel-generator needs form fields for a DataModel
What This Skill Generates
A complete Form Specification consists of 3 files:
| File | Purpose |
|---|
{Name}Fields.swift | Protocol + FormField definitions + validation methods |
{Name}FieldsMessages.swift | @FieldValidationModel struct with @LocalizedString properties |
{Name}FieldsMessages.yml | YAML localization (titles, placeholders, error messages) |
Project Structure Configuration
Replace placeholders with your project's actual paths:
| Placeholder | Description | Example |
|---|
{ViewModelsTarget} | Shared ViewModels SPM target | ViewModels, SharedViewModels |
{ResourcesPath} | Localization resources path | Sources/Resources |
Expected Structure:
Sources/
{ViewModelsTarget}/
FieldModels/
{Name}Fields.swift
{Name}FieldsMessages.swift
{ResourcesPath}/
FieldModels/
{Name}FieldsMessages.yml
How to Use This Skill
Invocation:
/fosmvvm-fields-generator
Prerequisites:
- Form purpose understood from conversation context
- Field requirements discussed (names, types, constraints)
- Entity relationship identified (what is this form creating/editing)
Workflow integration:
This skill is used when defining form validation and user input contracts. The skill references conversation context automatically—no file paths or Q&A needed. Often precedes fosmvvm-fluent-datamodel-generator for form-backed models.
Pattern Implementation
This skill references conversation context to determine Fields protocol structure:
From conversation context, the skill identifies:
- Form purpose (create, edit, filter, login, settings)
- Entity relation (User, Idea, Document - what's being created/edited)
- Protocol naming (CreateIdeaFields, UpdateProfile, LoginCredentials)
Field Design
For each field from requirements:
- Property specification (name, type, optional vs required)
- Presentation type (FormFieldType: text, textArea, select, checkbox)
- Input semantics (FormInputType: email, password, tel, date)
- Constraints (required, length range, value range, date range)
- Localization (title, placeholder, validation error messages)
File Generation Order
- Fields protocol with FormField definitions and validation
- FieldsMessages struct with @LocalizedString properties
- FieldsMessages YAML with localized strings
Context Sources
Skill references information from:
- Prior conversation: Form requirements, field specifications discussed
- Specification files: If Claude has read form specs into context
- Existing patterns: From codebase analysis of similar Fields protocols
Key Patterns
Protocol Structure
swift
1public protocol {Name}Fields: ValidatableModel, Codable, Sendable {
2 var fieldName: FieldType { get set }
3 var {name}ValidationMessages: {Name}FieldsMessages { get }
4}
swift
1static var contentField: FormField<String?> { .init(
2 fieldId: .init(id: "content"),
3 title: .localized(for: {Name}FieldsMessages.self, propertyName: "content", messageKey: "title"),
4 placeholder: .localized(for: {Name}FieldsMessages.self, propertyName: "content", messageKey: "placeholder"),
5 type: .textArea(inputType: .text),
6 options: [
7 .required(value: true)
8 ] + FormInputOption.rangeLength(contentRange)
9) }
| FormFieldType | Use Case |
|---|
.text(inputType:) | Single-line input |
.textArea(inputType:) | Multi-line input |
.checkbox | Boolean toggle |
.select | Dropdown selection |
.colorPicker | Color selection |
| FormInputType | Keyboard/Autofill |
|---|
.text | Default keyboard |
.emailAddress | Email keyboard, email autofill |
.password | Secure entry |
.tel | Phone keyboard |
.url | URL keyboard |
.date, .datetimeLocal | Date picker |
.givenName, .familyName | Name autofill |
Validation Method Pattern
swift
1internal func validateContent(_ fields: [FormFieldBase]?) -> [ValidationResult]? {
2 guard fields == nil || (fields?.contains(Self.contentField) == true) else {
3 return nil
4 }
5
6 var result = [ValidationResult]()
7
8 if content.isEmpty {
9 result.append(.init(
10 status: .error,
11 field: Self.contentField,
12 message: {name}ValidationMessages.contentRequiredMessage
13 ))
14 } else if !Self.contentRange.contains(NSString(string: content).length) {
15 result.append(.init(
16 status: .error,
17 field: Self.contentField,
18 message: {name}ValidationMessages.contentOutOfRangeMessage
19 ))
20 }
21
22 return result.isEmpty ? nil : result
23}
Messages Struct Pattern
swift
1@FieldValidationModel public struct {Name}FieldsMessages {
2 @LocalizedString("content", messageGroup: "validationMessages", messageKey: "required")
3 public var contentRequiredMessage
4
5 @LocalizedString("content", messageGroup: "validationMessages", messageKey: "outOfRange")
6 public var contentOutOfRangeMessage
7}
YAML Structure
yaml
1en:
2 {Name}FieldsMessages:
3 content:
4 title: "Content"
5 placeholder: "Enter your content..."
6 validationMessages:
7 required: "Content is required"
8 outOfRange: "Content must be between 1 and 10,000 characters"
Naming Conventions
| Concept | Convention | Example |
|---|
| Protocol | {Name}Fields | IdeaFields, CreateIdeaFields |
| Messages struct | {Name}FieldsMessages | IdeaFieldsMessages |
| Messages property | {name}ValidationMessages | ideaValidationMessages |
| Field definition | {fieldName}Field | contentField |
| Range constant | {fieldName}Range | contentRange |
| Validate method | validate{FieldName} | validateContent |
| Required message | {fieldName}RequiredMessage | contentRequiredMessage |
| OutOfRange message | {fieldName}OutOfRangeMessage | contentOutOfRangeMessage |
See Also
Version History
| Version | Date | Changes |
|---|
| 1.0 | 2024-12-24 | Initial skill |
| 2.0 | 2024-12-26 | Rewritten with conceptual foundation; generalized from Kairos-specific |
| 2.1 | 2026-01-24 | Update to context-aware approach (remove file-parsing/Q&A). Skill references conversation context instead of asking questions or accepting file paths. |