Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Generate FOSMVVM Fields protocols defining form fields, input types, validation rules, and localized messages for consistent, reusable form specifications.
Generate FOSMVVM Fields protocols defining form fields, input types, validation rules, and localized messages for consistent, reusable form specifications.
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
Generate Form Specifications following FOSMVVM patterns.
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)
The Form Specification is defined once, used everywhere: // Same protocol adopted by different consumers: struct CreateIdeaRequestBody: ServerRequestBody, IdeaFields { ... } // HTTP transmission @ViewModel struct IdeaFormViewModel: IdeaFields { ... } // Form rendering final 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
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
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
A complete Form Specification consists of 3 files: FilePurpose{Name}Fields.swiftProtocol + FormField definitions + validation methods{Name}FieldsMessages.swift@FieldValidationModel struct with @LocalizedString properties{Name}FieldsMessages.ymlYAML localization (titles, placeholders, error messages)
Replace placeholders with your project's actual paths: PlaceholderDescriptionExample{ViewModelsTarget}Shared ViewModels SPM targetViewModels, SharedViewModels{ResourcesPath}Localization resources pathSources/Resources Expected Structure: Sources/ {ViewModelsTarget}/ FieldModels/ {Name}Fields.swift {Name}FieldsMessages.swift {ResourcesPath}/ FieldModels/ {Name}FieldsMessages.yml
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.
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)
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)
Fields protocol with FormField definitions and validation FieldsMessages struct with @LocalizedString properties FieldsMessages YAML with localized strings
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
public protocol {Name}Fields: ValidatableModel, Codable, Sendable { var fieldName: FieldType { get set } var {name}ValidationMessages: {Name}FieldsMessages { get } }
static var contentField: FormField<String?> { .init( fieldId: .init(id: "content"), title: .localized(for: {Name}FieldsMessages.self, propertyName: "content", messageKey: "title"), placeholder: .localized(for: {Name}FieldsMessages.self, propertyName: "content", messageKey: "placeholder"), type: .textArea(inputType: .text), options: [ .required(value: true) ] + FormInputOption.rangeLength(contentRange) ) }
FormFieldTypeUse Case.text(inputType:)Single-line input.textArea(inputType:)Multi-line input.checkboxBoolean toggle.selectDropdown selection.colorPickerColor selection
FormInputTypeKeyboard/Autofill.textDefault keyboard.emailAddressEmail keyboard, email autofill.passwordSecure entry.telPhone keyboard.urlURL keyboard.date, .datetimeLocalDate picker.givenName, .familyNameName autofill
internal func validateContent(_ fields: [FormFieldBase]?) -> [ValidationResult]? { guard fields == nil || (fields?.contains(Self.contentField) == true) else { return nil } var result = [ValidationResult]() if content.isEmpty { result.append(.init( status: .error, field: Self.contentField, message: {name}ValidationMessages.contentRequiredMessage )) } else if !Self.contentRange.contains(NSString(string: content).length) { result.append(.init( status: .error, field: Self.contentField, message: {name}ValidationMessages.contentOutOfRangeMessage )) } return result.isEmpty ? nil : result }
@FieldValidationModel public struct {Name}FieldsMessages { @LocalizedString("content", messageGroup: "validationMessages", messageKey: "required") public var contentRequiredMessage @LocalizedString("content", messageGroup: "validationMessages", messageKey: "outOfRange") public var contentOutOfRangeMessage }
en: {Name}FieldsMessages: content: title: "Content" placeholder: "Enter your content..." validationMessages: required: "Content is required" outOfRange: "Content must be between 1 and 10,000 characters"
ConceptConventionExampleProtocol{Name}FieldsIdeaFields, CreateIdeaFieldsMessages struct{Name}FieldsMessagesIdeaFieldsMessagesMessages property{name}ValidationMessagesideaValidationMessagesField definition{fieldName}FieldcontentFieldRange constant{fieldName}RangecontentRangeValidate methodvalidate{FieldName}validateContentRequired message{fieldName}RequiredMessagecontentRequiredMessageOutOfRange message{fieldName}OutOfRangeMessagecontentOutOfRangeMessage
FOSMVVMArchitecture.md - Full FOSMVVM architecture reference fosmvvm-viewmodel-generator - For ViewModels that adopt Fields fosmvvm-fluent-datamodel-generator - For Fluent DataModels that implement Fields reference.md - Complete file templates
VersionDateChanges1.02024-12-24Initial skill2.02024-12-26Rewritten with conceptual foundation; generalized from Kairos-specific2.12026-01-24Update to context-aware approach (remove file-parsing/Q&A). Skill references conversation context instead of asking questions or accepting file paths.
Messaging, meetings, inboxes, CRM, and teammate communication surfaces.
Largest current source with strong distribution and engagement signals.