Update to FormHug

{
  "description": "Audit and improve an existing FormHug form for clarity, completion friction, field order, required fields, mobile usability, pagination, conditional logic, settings, and visual consistency. Use when the user asks to review, optimize, simplify, fix, or redesign an existing form. Treat review-only requests as read-only. For a quiz or assessment change involving scoring, answers, score ranges, or result feedback, use formhug-create-quiz instead.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 482
    }
  ],
  "name": "formhug-improve-form",
  "skill_md_contents": "---\nname: formhug-improve-form\ndescription: Audit and improve an existing FormHug form for clarity, completion friction, field order, required fields, mobile usability, pagination, conditional logic, settings, and visual consistency. Use when the user asks to review, optimize, simplify, fix, or redesign an existing form. Treat review-only requests as read-only. For a quiz or assessment change involving scoring, answers, score ranges, or result feedback, use formhug-create-quiz instead.\n---\n\n# Improve an existing FormHug form\n\nDiagnose first, then make the smallest changes that solve the user's problem.\n\n## Inspect\n\n1. Resolve the target with `list_forms` when the token is unknown. Prefer its name filter when a name is known; if the target is not on the first page, follow `next_cursor` until found or the list is exhausted. If several forms match, ask the user to choose rather than guessing.\n2. Use `get_form` and `preview_form` to inspect structure and api_codes. Read `get_form_settings`, `get_form_theme`, and `get_field_rules` when the requested review touches behavior, appearance, or conditional logic.\n3. Consult the current MCP resources only as needed:\n   - `formhug://field-types` for field suitability and advanced shapes.\n   - `formhug://field-rules` for conditional behavior.\n   - `formhug://themes` for visual changes.\n   If direct resource access is unavailable, call `read_reference` with the same URI.\n\n## Diagnose\n\nEvaluate the form against its stated purpose and audience:\n\n- Identify questions that could be removed because they do not support a decision, handoff, or promised respondent outcome.\n- Check whether required fields are genuinely necessary.\n- Put low-effort questions before sensitive, complex, or open-ended ones.\n- Prefer structured field types when downstream filtering or validation matters.\n- Check choice completeness, balanced wording, duplicate questions, instructions, locale, timezone, and after-submission behavior.\n- Use page breaks only when a classic form is long enough to benefit. Remember that classic pagination requires zero or at least two correctly placed `page_break` fields.\n- Verify that conditional targets follow their triggers and that rule api_codes still exist.\n- Review the theme for readability and consistency, not merely decoration.\n- Flag unnecessary collection or exposure of personal and sensitive data.\n\nReturn prioritized findings before mutating anything when the user asked only for an audit, critique, or recommendations.\n\n## Apply requested improvements\n\nAn explicit request to optimize, fix, or apply changes authorizes non-destructive improvements. Ask for additional authorization only for the destructive or data-affecting operations listed below.\n\n1. Re-read the latest form state immediately before writing if the review and edit are separated by discussion.\n2. Use the narrowest tool for each change: `update_form`, `add_fields`, `update_fields`, `move_field`, `remove_field`, `update_form_settings`, `update_form_theme`, or `update_field_rules`.\n3. Preserve data and identifiers:\n   - Include the existing field api_code in every `update_fields` item.\n   - Never change a field's `type` through `update_fields`; field types are immutable after creation.\n   - Treat a type change as a migration: add a replacement field, repair affected rules, and remove the old field only after explicit user authorization. Warn that existing response values remain attached to the old field and are not migrated automatically.\n   - Treat nested arrays as replacements. Include every existing choice, statement, dimension, or item that should remain, with its api_code.\n   - Treat `update_form_settings` and `update_form_theme` as partial merges: omitted keys remain unchanged, while explicit `null` clears a value.\n   - Read current field rules before structural edits that can invalidate their trigger or target api_codes. In `update_field_rules`, each included rule key replaces that rule kind's complete list, `[]` clears it, and an omitted key leaves it unchanged.\n4. Require explicit user authorization before removing a field, clearing a rule list, clearing a setting, replacing a choice set, or deleting any resource. Never call `delete_form` as part of optimization.\n5. Verify the saved form with `get_form` or `preview_form`, and re-read settings, theme, or rules that were changed.\n6. Summarize the exact changes, remaining recommendations, and the public form URL for live testing. Include the edit URL when further manual refinement is likely.\n\n## Tool-call guardrails\n\n- If FormHug tools are unavailable, pause and ask the user to connect the FormHug app. On an authentication or authorization error, ask the user to reconnect or reauthorize rather than repeatedly retrying.\n- For validation errors, correct the narrow payload from the tool response and relevant MCP resource. If a write result is uncertain, re-read the form before retrying and apply only the missing change.\n- Never invent current state, api_codes, form tokens, URLs, or successful results. Report partial success and any remaining work explicitly.\n"
}