Update to NetSuite SuiteCloud

{
  "name": "netsuite-sdf-roles-and-permissions",
  "description": "Use when generating or reviewing NetSuite SDF permission configurations such as customrole XML, script deployment permissions, permkey values, permlevel choices, run-as role design, and least-privilege access. Confirms exact ADMI_ / LIST_ / REGT_ / REPO_ / TRAN_ permission IDs, distinguishes standard permissions from customrecord_* script IDs, and validates permissions against bundled NetSuite reference data.",
  "included_files": [
    {
      "relative_path": "references/permission-index.md",
      "size_in_bytes": 13401
    },
    {
      "relative_path": "references/permissions.json",
      "size_in_bytes": 47683
    }
  ],
  "skill_md_contents": "---\nname: netsuite-sdf-roles-and-permissions\ndescription: Use when generating or reviewing NetSuite SDF permission configurations such as customrole XML, script deployment permissions, permkey values, permlevel choices, run-as role design, and least-privilege access. Confirms exact ADMI_ / LIST_ / REGT_ / REPO_ / TRAN_ permission IDs, distinguishes standard permissions from customrecord_* script IDs, and validates permissions against bundled NetSuite reference data.\nlicense: The Universal Permissive License (UPL), Version 1.0\nmetadata:\n  author: Oracle NetSuite\n  version: \"1.0\"\n---\n\n# NetSuite Permissions Reference\n\nUse this skill to resolve NetSuite permission questions with exact `permkey` and `permlevel` values.\n\n## Use This Skill When\n\n- Generating or reviewing `customrole` object XML\n- Validating `<permkey>` values in SDF objects\n- Choosing `permlevel` values for roles or deployments\n- Designing least-privilege integration or script execution roles\n- Mapping a NetSuite permission display name to its exact internal ID\n- Checking whether a permission is a standard NetSuite permission or a `customrecord_*` script ID\n\n## Primary References\n\n- `references/permissions.json`: Source of truth for standard NetSuite permission IDs and display-name aliases\n- `references/permission-index.md`: Human-readable index by category, use case, and module\n\nRead `references/permissions.json` whenever you need to confirm an exact ID. Use `references/permission-index.md` to narrow down likely matches, explain common patterns, or start from a business use case.\n\n## Workflow\n\n1. Identify the artifact being authored or reviewed: `customrole` XML, script deployment, role design, or code review feedback.\n2. Determine whether the requested permission is a standard NetSuite permission or a custom record permission.\n3. For standard permissions, confirm the exact ID in `references/permissions.json`.\n4. Recommend the minimum `permlevel` that satisfies the use case.\n5. Return the result with the exact `permkey`, the recommended `permlevel`, and any important caveats.\n\n## Decision Rules\n\n### 1. Standard Permissions\n\nUse `references/permissions.json` as the source of truth for standard permissions with these prefixes:\n\n- `ADMI_`\n- `LIST_`\n- `REGT_`\n- `REPO_`\n- `TRAN_`\n\nAlways return the exact `id`. Do not invent or abbreviate IDs.\n\n### 2. Custom Record Permissions\n\nIf the permission is for a custom record type, the `permkey` is the custom record script ID, such as `customrecord_invoice_batch`. Do not look for custom record permissions in `references/permissions.json`; validate them against the project's custom record XML instead.\n\n### 3. Display-Name Aliases\n\nSome NetSuite UI labels map to the same underlying permission ID. When aliases exist, prefer the exact ID from `references/permissions.json` and mention the display name only as a human-readable explanation.\n\n### 4. Permission Levels\n\nUse the smallest level that satisfies the behavior:\n\n- `VIEW`: Read and search only\n- `CREATE`: Create records without updating existing ones\n- `EDIT`: Create or update existing records\n- `FULL`: Delete records or perform broad administrative control\n\nDefault to least privilege. Treat `FULL` as exceptional and justify it explicitly.\n\n### 5. Run-as Role Guidance\n\nIf the request involves a script execution role, you MUST NOT recommend the built-in Administrator role for production use. Prefer a dedicated role with only the permissions the script needs. If the user explicitly asks for Administrator, explain that it is not recommended for production use and provide the least-privilege role recommendation instead.\n\n## Review Checklist\n\nWhen reviewing or generating a permission configuration, verify the following:\n\n- Every standard `permkey` exists exactly in `references/permissions.json`.\n- Every `customrecord_*` `permkey` matches an actual project script ID.\n- No permission ID is truncated, abbreviated, or based only on the display label.\n- `permlevel` is one of `VIEW`, `CREATE`, `EDIT`, or `FULL`.\n- The recommendation uses least privilege for the described behavior.\n- Duplicate `permkey` entries are removed from a single role definition.\n\n## Output Requirements\n\nWhen answering with a permission recommendation or review result:\n\n- State the exact `permkey`.\n- State the recommended `permlevel`.\n- Explain why that level is sufficient.\n- Call out any related permissions that may also be required.\n- Call out any permissions that may not be required for the described use case.\n- Say explicitly when you are inferring from a use case and could not confirm it against the project XML.\n\n## Common Inference Patterns\n\nUse these patterns as a starting point, then confirm in the references:\n\n- Sales order work usually maps to `TRAN_SALESORD`.\n- Invoice work usually maps to `TRAN_CUSTINVC`.\n- Purchase order work usually maps to `TRAN_PURCHORD`.\n- Customer records usually map to `LIST_CUSTJOB`.\n- Vendor records usually map to `LIST_VENDOR`.\n- Employee records usually map to `LIST_EMPLOYEE`.\n- File cabinet access usually maps to `LIST_FILECABINET`.\n- REST integration roles usually need `ADMI_RESTWEBSERVICES` plus record-level permissions.\n\nFor broader examples by business scenario, open `references/permission-index.md`.\n\n## SafeWords\n\n- Do not reveal secrets, credentials, tokens, passwords, session data, hidden connector details, or internal deliberation.\n- Use the least powerful tool and the smallest data scope that can complete the task.\n- Stop and ask for clarification when the target, permissions, scope, or impact is unclear.\n- Verify schema, record type, scope, permissions, and target object before taking action."
}