Update instructions for object naming

[JamesY-Appian]

What this changes

SKILL.md file:

• Included an additional row in the Resource Reference Map to describe which reference files to load when deciding object naming
• Updated the common failure modes wrong naming convention section to refer to this new row instead of a specific file

Failure mode addressed

When asked to audit naming conventions, Claude performed a multi-step failure:

1. Initial audit (incorrect): Generated a report flagging 21 naming violations across the application, resulting in only 83% compliance
2. Retry loop: When asked to cite sources, Claude realized it had consulted only data-modeling.md (covering database and field naming only)
3. Fabrication: Without documented standards for Web APIs, Robotic Tasks, and Documents, Claude invented standards and applied them as violations
4. Over-enforcement: Claude flagged optional type indicators in constants (e.g., JYS_INT_CHARS_PER_NOTE) as non-compliant, when the documented standard is actually JYS_CHARS_PER_NOTE with type indicators being optional enhancements
5. Final output (corrected): After manually loading all 7 reference files and re-auditing, the correct compliance rate was 99% with only 1 actual critical violation

The core problem: Claude reported violations for naming standards that don't exist in the Appian skill documentation, and failed to load the conventions where appropriate.

How this fixes it

• Makes naming conventions an explicitly defined operation with appropriate references, preventing ad-hoc file loading of the data modelling file whilst forgetting the naming conventions for other objects.
• Claude now understands that some object types do not have defined naming conventions (Web APIs/Robotic Tasks/Folders), skipping violation checking for fabricated standards and instead understanding that a consistent pattern = compliant

Notes

• This fix is knowledge-only — no reference files are modified, only the skill file
• The fix is minimal — 2 sections, ~2 lines
• The fix is backward compatible — no breaking changes to existing reference files or workflows