feat: expand required-field FLS detection in generating-permission-set

[brianevanmiller]

References: Contributing guide · Skill authoring guide · Agent Skills spec

What changed

• Added a "What counts as required" subsection to Step 3 of skills/generating-permission-set/SKILL.md, covering Master-Detail relationships, system-required standard fields (Name, OwnerId, CreatedById), and required Lookups — beyond the existing <required>true</required> check.
• Added a detection note: read the field's *.field-meta.xml before emitting a <fieldPermissions> entry; if the file can't be read, flag for manual review rather than guessing.
• Quoted the actual Salesforce deployment error in "What Causes Deployment Failure" so agents retrying a failed deploy can pattern-match the error to the rule.
• Tightened the Validation Checklist item on required fields to require verifying the field's metadata file rather than asserting "no required fields" by assumption.

Why

The skill already forbids <fieldPermissions> entries on required fields, but the guidance reads as a single check against <required>true</required> in field metadata. In practice, three other patterns produce the same deployment failure and are under-covered:

1. Master-Detail fields are implicitly required on the child object — mentioned in one passing line, no detection guidance.
2. System-required standard fields (e.g. Name, OwnerId) and required Lookups also fail FLS deployment.
3. The platform error message is unambiguous (You can't edit field-level security for a required field, universally required field, or master-detail relationship field...) but isn't quoted in the skill, so an agent retrying a failed deploy can't match the error back to the rule.

Real-world trigger: a custom datetime field was flipped to <required>true</required> to back an LWC requirement; the existing permission set's <fieldPermissions> entry silently broke the next deploy with the error above. The updated guidance directs the agent to read the field metadata before emitting an entry, which catches this and similar cases.

Notes

• Single-file change: skills/generating-permission-set/SKILL.md (+15 / -2). No frontmatter changes.
• npm run validate:skills passes locally (57/57). The three pre-existing line-count warnings on unrelated skills (developing-agentforce, generating-flexipage, using-ui-bundle-salesforce-data) are unchanged.
• Happy to soften the language if maintainers prefer "flag and ask" over "omit the entry" when metadata can't be read.

---

Skills

Manual checklist

Description quality

• Describes what the skill does and the expected output
• Includes relevant Salesforce domain keywords (Apex, LWC, SOQL, metadata types, etc.)
• Trigger phrases are specific enough for Vibes to select this skill reliably

Instructions

• Clear goal statement
• Step-by-step workflow
• Validation rules for generated output
• Defined output / artifact

Context efficiency

• Core instructions are concise — supporting material lives in templates/, examples/, or docs/ subdirectories
• No unnecessary background explanation in the body

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @brianevanmiller to sign the Salesforce Inc. Contributor License Agreement.

[brianevanmiller]

Thanks for the contribution! Before we can merge this, we need @brianevanmiller to sign the Salesforce Inc. Contributor License Agreement.

I signed it, thank you!

[brianevanmiller]

Confirming that the CLA was signed: