• "Enable Dev Hub" / "Turn on Dev Hub" / "Set up this org for scratch orgs."
• "Is Dev Hub enabled on my org?" / "Check if Dev Hub is on."
• "How many scratch orgs can I create?" / "What's my scratch org allocation / limit?" / "How many scratch orgs do I have left?"
• "Turn on packaging / 2GP / unlocked packages" / "Enable org shape export" / "Enable scratch org snapshots" (Dev Hub sub-preferences).
• "List the scratch orgs on my Dev Hub."

• Creating or deleting an individual scratch org — that is

  sf org create scratch

  /

  sf org delete scratch

  , a different workflow. This skill enables the Dev Hub feature and reports allocation; it does not create scratch orgs.
• Switching the default/active org — use

  dx-org-switch

  .
• Trial or org expiration dates ("when does my org expire") — use

  dx-org-trial-expiration-check

  .

ScratchOrgInfo

SELECT COUNT() FROM ScratchOrgInfo

INVALID_TYPE

Do not infer enablement from

sf org list limits

alone: it reports

ActiveScratchOrgs

/

DailyScratchOrgs

rows even on orgs where Dev Hub is off, so limits show allocation but not enablement.

• The Dev Hub master switch is the deployable Metadata API field

  DevHubSettings.enableScratchOrgManagementPref

  . There is no

  enableDevHub

  field and no dedicated

  sf

  command to turn it on — deploying this setting is exactly what the Setup toggle does.
• Enabling is irreversible — once on, Dev Hub cannot be turned off.
• Requires a user with ModifyAllData or ModifyMetadata (a System Administrator has these). A user without them gets

  INSUFFICIENT_ACCESS

  .
• Cannot be enabled in a sandbox, or in an org that has a registered namespace.
• Available in Developer, Enterprise, Performance, Unlimited, and trial editions.

1. CRITICAL: Run the bundled helper script, which handles Dev Hub detection, the enablement deploy (with a safe dry-run default), allocation math, and structured output, and works on macOS and Linux. Always invoke it by absolute path from the skill directory — never

   ./scripts/

   , which resolves against the user's current directory and will either run the wrong script or fail. The script self-checks this: if

   $0

   is not absolute it exits with a usage error, so pass the full path to

   <skill_dir>

   (the directory containing this SKILL.md).
   bash

   bash "<skill_dir>/scripts/devhub.sh" <alias-or-username>            # status: on? + allocation
   bash "<skill_dir>/scripts/devhub.sh"                               # default org (target-org)
   bash "<skill_dir>/scripts/devhub.sh" <org> --allocation           # allocation only
   bash "<skill_dir>/scripts/devhub.sh" <org> --enable               # validate enabling (dry run)
   bash "<skill_dir>/scripts/devhub.sh" <org> --enable --apply       # actually enable (irreversible)
   bash "<skill_dir>/scripts/devhub.sh" <org> --list-scratch         # list active scratch orgs
   bash "<skill_dir>/scripts/devhub.sh" <alias> --instance-url <url> --enable --apply  # log in first, then enable
   bash "<skill_dir>/scripts/devhub.sh" <url>                        # bare instance URL: log in to it

   When the user supplies an instance URL (their My Domain, sandbox, or pre-release/scratch login URL — e.g.

   https://my-domain.my.salesforce.com

   ), pass that exact URL with

   --instance-url <url>

   — the script accepts Salesforce-owned hostnames and logs in with

   sf org login web --instance-url <url>

   and then continues. A bare URL positional is accepted as shorthand for the same thing.

   <skill_dir>

   is the absolute path to the directory containing this SKILL.md.
2. For enablement, default to a dry run first. Run

   --enable

   (no

   --apply

   ) to validate the deploy, then relay the result. Because enabling is irreversible, only run

   --enable --apply

   when the user has clearly asked to actually enable Dev Hub. Applied operations require an explicit org alias or username; the script refuses to mutate an implicit default org. If the deploy is rejected for permissions, surface the Setup-UI fallback it prints.
3. Relay the script output. When an org can't be queried, surface the

   sf org login web

   command the script prints so the user can authenticate. Pick optional flags based on the request (see below):

   --allocation

   for limits only,

   --list-scratch

   to enumerate scratch orgs,

   --packaging

   /

   --snapshots

   /

   --shape

   to turn on sub-preferences,

   --json

   for automation.

• CRITICAL: Invoked the helper via its absolute path (

  bash "<skill_dir>/scripts/devhub.sh" …

  ), never

  ./scripts/

  (the script rejects a non-absolute

  $0

  ).
• Did not run

  --apply

  unless the user clearly asked to actually enable Dev Hub or deploy a preference — enabling is irreversible.
• Relayed the script's own output (status/allocation or the login/Setup-UI guidance it printed), rather than substituting a hand-written answer.

• 0

  success

• 1

  an org could not be queried, or a deploy failed (auth/connection/deploy)

• 2

  bad usage or a missing dependency (

  sf

  or

  jq

  )

• 3

  Dev Hub is not enabled (only when

  --fail-if-disabled

  is set)

• Requires the Salesforce CLI (

  sf

  ) and

  jq

  on the PATH, plus at least one authenticated org (

  sf org login web

  ).
• After enabling, set the org as your default Dev Hub:

  sf config set target-dev-hub <org>

  .
• Enabling packaging (

  enablePackaging2

  ) requires Dev Hub to be on first —

  --enable --packaging

  handles the ordering in a single deploy.
• Non-admin users still need object access (Read/Create on

  ScratchOrgInfo

  and

  ActiveScratchOrg

  ) to create/view scratch orgs, and the "Create and Update Second-Generation Packages" permission to build 2GP/unlocked packages.
• To switch the default org use

  dx-org-switch

  ; to check expiration use

  dx-org-trial-expiration-check

  .