Trim ping-identity skill descriptions to routing-only signal#7
Conversation
Descriptions were carrying routing logic, behavioural guardrails, and "when NOT to use" lists that belong in the skill body. This inflates context for every agent interaction regardless of whether the skill is invoked. Trim all 6 ping-identity descriptions to the minimum signal needed for correct routing. Validated with a 20-case multi-skill routing eval (current: 18/20, proposed: 19/20). AIC vs PingOne distinction scores 8/8 on both. The one regression (batch job → ping-foundation) was fixed by adding 'Worker apps and service accounts for M2M API access' to ping-foundation. The two shared failures are pre-existing description-level ambiguities (Verify SDK invocation, push MFA in a flow) not introduced by this change. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
patrickcping
left a comment
There was a problem hiding this comment.
Some proposed adjustments. The main adjustment is that there is "also invoke with" instruction, but then references itself. The intention may be to have the agent invoke a foundational skill as well, like a hierarchy or a tight coupling, but this is probably best left determined by the agent based on the descriptions of the other skills and what it needs for the instruction it has.
| --- | ||
| name: ping-app-integration | ||
| description: "Use this skill whenever the task involves writing code or wiring an SDK to integrate Ping Identity into an application. Triggers: Android, iOS, or React/JavaScript SDK integration; embedding DaVinci flows or AIC journeys in a web or mobile app; OIDC authorization code + PKCE flow wiring; server-side backend OIDC (Node.js, Java, Python, .NET); token validation, refresh, and session management; client credentials (M2M) and token exchange patterns; redirect_uri_mismatch, CORS, token refresh failures, push MFA not delivering; migrating from ForgeRock SDK to Ping SDK; embedding a Ping service SDK (Protect JavaScript signals SDK, Verify mobile SDK) in app code; on-prem PingFederate or PingAccess agent integration. NOT for: configuring or invoking PingOne Verify, Protect, IGA, or Authorize at the service/policy level (use ping-universal-services); platform admin (use ping-foundation); flow design (use ping-orchestration). Also invoke with /ping-app-integration." | ||
| description: "Use when writing code or wiring an SDK to integrate Ping Identity into a web, mobile, or backend app — Android/iOS/JavaScript SDK installation, OIDC authorization code + PKCE flows, token management, ForgeRock-to-Ping SDK migration, and app-side troubleshooting (redirect_uri_mismatch, CORS, token refresh failures). Also invoke with /ping-app-integration." |
There was a problem hiding this comment.
| description: "Use when writing code or wiring an SDK to integrate Ping Identity into a web, mobile, or backend app — Android/iOS/JavaScript SDK installation, OIDC authorization code + PKCE flows, token management, ForgeRock-to-Ping SDK migration, and app-side troubleshooting (redirect_uri_mismatch, CORS, token refresh failures). Also invoke with /ping-app-integration." | |
| description: "Use when writing code or wiring an SDK to integrate Ping Identity into a web, mobile, or backend app — Android/iOS/JavaScript SDK installation, OIDC authorization code + PKCE flows, token management, ForgeRock-to-Ping SDK migration, and app-side troubleshooting (redirect_uri_mismatch, CORS, token refresh failures)." |
| --- | ||
| name: ping-foundation | ||
| description: "Use this skill whenever the task involves setting up, configuring, or administering any Ping Identity platform — PingOne (multi-tenant cloud), PingOne Advanced Identity Cloud (AIC), PingFederate, PingAccess, PingDirectory, or PingID. Triggers: create or manage environments, tenants, realms; register OIDC, SAML, WS-Federation, or OAuth 2.0 apps; configure SSO, Platform SSO, or workforce single sign-on; manage directories, LDAP, user populations, or schema; configure sign-on policies, authentication policies, or step-up MFA policy settings at the platform level; configure MFA methods or PingID in PingFederate; branding, custom domains, or notification templates; administer on-premises Ping software; advisory questions like 'how should I structure my tenant' or 'what grant type should I use'. Prerequisite — a specific platform must be named or clearly implied; 'add a user to Ping' or 'create a user in Ping' without a named platform belongs in ping-quickstart first. Also invoke with /ping-foundation." | ||
| description: "Use when setting up, configuring, or administering any Ping Identity platform — PingOne, PingOne Advanced Identity Cloud (AIC), PingFederate, PingAccess, PingDirectory, or PingID. Covers tenant/environment creation, app registration (including Worker apps and service accounts for M2M API access), SSO, directories, policies, and branding. Requires a named or clearly implied platform. Also invoke with /ping-foundation." |
There was a problem hiding this comment.
| description: "Use when setting up, configuring, or administering any Ping Identity platform — PingOne, PingOne Advanced Identity Cloud (AIC), PingFederate, PingAccess, PingDirectory, or PingID. Covers tenant/environment creation, app registration (including Worker apps and service accounts for M2M API access), SSO, directories, policies, and branding. Requires a named or clearly implied platform. Also invoke with /ping-foundation." | |
| description: "Use when setting up, configuring, or administering any Ping Identity platform — PingOne, PingOne Advanced Identity Cloud (AIC), PingFederate, PingAccess, PingDirectory, or PingID. Covers tenant/environment creation, app registration (including Worker apps and service accounts for M2M API access), SSO, directories, policies, and branding. Requires a named or clearly implied platform." |
| --- | ||
| name: ping-identity-for-ai | ||
| description: "Use this skill whenever the task involves an AI agent, LLM, or agentic workflow interacting with Ping Identity. Triggers: giving an AI agent or LLM a verified machine identity; securing agent-to-API access with client credentials or short-lived tokens; Verified Trust signals or verifiable credentials for AI apps; Identity for AI 5-pillar architecture (Agent Identity, Agent Security, Agent Gateway, Agent Detection, Verified Trust); PingGateway as an MCP gateway for AI agents; CIBA human-in-the-loop approvals for high-risk agent actions; bot detection and AI agent detection with PingOne Protect; delegated tokens for helpdesk AI or workforce AI assistants; 'how do I give my AI agent an identity', 'secure my MCP server', 'token rotation for an autonomous agent'. If the request says 'automated process', 'scheduled job', or 'service account' WITHOUT mentioning AI, LLM, or agent — ask a clarifying question before routing here. If the prompt says only 'agent' or 'authenticate an agent' with no AI/LLM/agentic context — ask a clarifying question, as 'agent' is ambiguous (could mean AI agent, Ping integration agent, or browser user-agent). Also invoke with /ping-identity-for-ai." | ||
| description: "Use when an AI agent, LLM, or agentic workflow interacts with Ping Identity — agent machine identity, client credentials for agents, Verified Trust signals, Identity for AI 5-pillar architecture, PingGateway as MCP gateway, CIBA human-in-the-loop approvals, or AI/bot detection with PingOne Protect. Ask a clarifying question before routing if 'agent' lacks AI/LLM context. Also invoke with /ping-identity-for-ai." |
There was a problem hiding this comment.
| description: "Use when an AI agent, LLM, or agentic workflow interacts with Ping Identity — agent machine identity, client credentials for agents, Verified Trust signals, Identity for AI 5-pillar architecture, PingGateway as MCP gateway, CIBA human-in-the-loop approvals, or AI/bot detection with PingOne Protect. Ask a clarifying question before routing if 'agent' lacks AI/LLM context. Also invoke with /ping-identity-for-ai." | |
| description: "Use when an AI agent, LLM, or agentic workflow interacts with Ping Identity — agent machine identity, client credentials for agents, Verified Trust signals, Identity for AI 5-pillar architecture, PingGateway as MCP gateway, CIBA human-in-the-loop approvals, or AI/bot detection with PingOne Protect. Ask a clarifying question before routing if 'agent' lacks AI/LLM context." |
| --- | ||
| name: ping-orchestration | ||
| description: "Use this skill whenever the task involves designing, building, or advising on authentication flows, journeys, or orchestration logic in Ping Identity. Triggers: DaVinci flows, PingOne Advanced Identity Cloud (AIC) journeys, PingAM authentication trees, scripted decision nodes; login, registration, recovery, MFA, or step-up journey design; passwordless authentication (passkeys, FIDO2, magic links, biometric); authenticator app enrollment, TOTP, push MFA flows; transaction approvals via email or push notification (CIBA, out-of-band step-up); progressive profiling, social login, consent; flow troubleshooting; 'what nodes do I need', 'design a flow for', 'build a journey that'. When the user asks 'journey vs DaVinci flow?', 'AIC or DaVinci?', 'which orchestration platform should we use?', or 'where do I configure MFA in Ping?' without stating both a use case (workforce / CIAM / B2B) AND a platform — you MUST ask one clarifying question before recommending. Do not guess. Also invoke with /ping-orchestration." | ||
| description: "Use when designing, building, or advising on authentication flows or orchestration logic — DaVinci flows, PingOne Advanced Identity Cloud journeys, PingAM trees, login/registration/MFA/step-up/passwordless flows, scripted decision nodes, and social login. Ask one clarifying question about use case and platform before recommending journey vs DaVinci if either is unknown. Also invoke with /ping-orchestration." |
There was a problem hiding this comment.
| description: "Use when designing, building, or advising on authentication flows or orchestration logic — DaVinci flows, PingOne Advanced Identity Cloud journeys, PingAM trees, login/registration/MFA/step-up/passwordless flows, scripted decision nodes, and social login. Ask one clarifying question about use case and platform before recommending journey vs DaVinci if either is unknown. Also invoke with /ping-orchestration." | |
| description: "Use when designing, building, or advising on authentication flows or orchestration logic — DaVinci flows, PingOne Advanced Identity Cloud journeys, PingAM trees, login/registration/MFA/step-up/passwordless flows, scripted decision nodes, and social login. Ask one clarifying question about use case and platform before recommending journey vs DaVinci if either is unknown." |
| --- | ||
| name: ping-quickstart | ||
| description: "Use this skill BEFORE any more specialised Ping skill whenever the user is in orientation mode — phrases like 'where do we start', 'where do I start', 'where do we begin', 'how do we begin', 'we want to add X — where do we start', 'we are evaluating', 'we are migrating from ForgeRock / Okta / Auth0', 'I am new to Ping', 'I inherited a Ping deployment', 'help me choose', 'PingOne vs AIC vs PingFederate', 'which Ping product do I need', 'recommended starting point', 'test this end to end / validate my Ping setup'. Even when a specific feature, service, or product is mentioned (KYC, MFA, Verify, DaVinci, etc.), if the framing is 'where do we start' or 'we are evaluating' or 'we are migrating' — route here FIRST. Also triggers on bare user-management commands with no platform named: 'Add a user to Ping', 'Create a user in Ping', 'Manage users in Ping' — Ping has many products with separate user populations (PingOne, PingOne Advanced Identity Cloud / AIC, PingFederate, PingDirectory); for these prompts you MUST respond with action 'clarify' asking which platform, not 'route'. Catch-all front door when platform or starting point is unclear. Also invoke with /ping-quickstart." | ||
| description: "Use before any other Ping skill when the user is in orientation mode — 'where do I start', 'which Ping product do I need', 'help me choose', 'we're evaluating', 'migrating from ForgeRock/Okta/Auth0', or when platform is unknown. Also use for bare user-management commands with no platform named ('Add a user to Ping') — clarify platform before routing. Also invoke with /ping-quickstart." |
There was a problem hiding this comment.
| description: "Use before any other Ping skill when the user is in orientation mode — 'where do I start', 'which Ping product do I need', 'help me choose', 'we're evaluating', 'migrating from ForgeRock/Okta/Auth0', or when platform is unknown. Also use for bare user-management commands with no platform named ('Add a user to Ping') — clarify platform before routing. Also invoke with /ping-quickstart." | |
| description: "Use before any other Ping skill when the user is in orientation mode — 'where do I start', 'which Ping product do I need', 'help me choose', 'we're evaluating', 'migrating from ForgeRock/existing identity platform', or when platform is unknown. Also use for bare user-management commands with no platform named ('Add a user to Ping') — clarify platform before routing." |
| --- | ||
| name: ping-universal-services | ||
| description: "Use this skill whenever the task involves configuring or invoking a Ping shared service at the policy or service level. Triggers: PingOne Protect (risk scoring, predictors, risk policies, Signals SDK); PingOne Verify (KYC, identity proofing, document + liveness, verification policies); PingOne MFA (device management, MFA policies, enrollment API, MFA-as-a-service); PingOne Credentials (verifiable credential issuance, presentation, revocation); PingOne IGA (access requests, access reviews, provisioning, entitlements); PingOne Authorize (fine-grained authorization, ABAC policies); cross-platform SSO; 'which shared service do I need'. Service-in-flow rule — when a Protect, Verify, IGA, or Authorize node or connector appears inside a DaVinci flow or AIC journey, configuring that node, connector, or service invocation belongs here, NOT in ping-orchestration. Orchestration owns the flow shape; this skill owns the service node configuration regardless of where the node lives. MFA region guardrail — for Workforce MFA tasks, always establish the admin's PingOne region (console domain: .pingone.sg for Singapore vs .pingone.com/.eu/.asia for other regions) before advising on service model or available methods; the service model differs by region. Do NOT trigger on vague 'add security' requests — clarify which service first. Also invoke with /ping-universal-services." | ||
| description: "Use when configuring or invoking a Ping shared service at the policy or service level — PingOne Protect (risk scoring), PingOne Verify (KYC/identity proofing), PingOne MFA (device management, enrollment API), PingOne Credentials (verifiable credentials), PingOne IGA, or PingOne Authorize (fine-grained authorization). This skill owns service node configuration inside DaVinci flows and AIC journeys. Also invoke with /ping-universal-services." |
There was a problem hiding this comment.
| description: "Use when configuring or invoking a Ping shared service at the policy or service level — PingOne Protect (risk scoring), PingOne Verify (KYC/identity proofing), PingOne MFA (device management, enrollment API), PingOne Credentials (verifiable credentials), PingOne IGA, or PingOne Authorize (fine-grained authorization). This skill owns service node configuration inside DaVinci flows and AIC journeys. Also invoke with /ping-universal-services." | |
| description: "Use when configuring or invoking a Ping shared service at the policy or service level — PingOne Protect (risk scoring), PingOne Verify (KYC/identity proofing), PingOne MFA (device management, enrollment API), PingOne Credentials (verifiable credentials), PingOne IGA, or PingOne Authorize (fine-grained authorization). This skill owns service node configuration inside DaVinci flows and AIC journeys." |
Patrick's feedback: the 'Also invoke with /ping-xyz' tail in each description is circular — the agent reads descriptions to decide whether to invoke, so self-referencing the slash command is noise. Remove from all 6 descriptions. Also: ping-quickstart updated to use 'existing identity platform' instead of hard-coded competitor names, and adds 'inherited a Ping deployment' as an explicit orientation trigger. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
brando-dill
left a comment
There was a problem hiding this comment.
Overall, good, just a couple of minor comments.
| --- | ||
| name: ping-identity-for-ai | ||
| description: "Use this skill whenever the task involves an AI agent, LLM, or agentic workflow interacting with Ping Identity. Triggers: giving an AI agent or LLM a verified machine identity; securing agent-to-API access with client credentials or short-lived tokens; Verified Trust signals or verifiable credentials for AI apps; Identity for AI 5-pillar architecture (Agent Identity, Agent Security, Agent Gateway, Agent Detection, Verified Trust); PingGateway as an MCP gateway for AI agents; CIBA human-in-the-loop approvals for high-risk agent actions; bot detection and AI agent detection with PingOne Protect; delegated tokens for helpdesk AI or workforce AI assistants; 'how do I give my AI agent an identity', 'secure my MCP server', 'token rotation for an autonomous agent'. If the request says 'automated process', 'scheduled job', or 'service account' WITHOUT mentioning AI, LLM, or agent — ask a clarifying question before routing here. If the prompt says only 'agent' or 'authenticate an agent' with no AI/LLM/agentic context — ask a clarifying question, as 'agent' is ambiguous (could mean AI agent, Ping integration agent, or browser user-agent). Also invoke with /ping-identity-for-ai." | ||
| description: "Use when an AI agent, LLM, or agentic workflow interacts with Ping Identity — agent machine identity, client credentials for agents, Verified Trust signals, Identity for AI 5-pillar architecture, PingGateway as MCP gateway, CIBA human-in-the-loop approvals, or AI/bot detection with PingOne Protect. Ask a clarifying question before routing if 'agent' lacks AI/LLM context." |
There was a problem hiding this comment.
5-pillar architecture?
| --- | ||
| name: ping-quickstart | ||
| description: "Use this skill BEFORE any more specialised Ping skill whenever the user is in orientation mode — phrases like 'where do we start', 'where do I start', 'where do we begin', 'how do we begin', 'we want to add X — where do we start', 'we are evaluating', 'we are migrating from ForgeRock / Okta / Auth0', 'I am new to Ping', 'I inherited a Ping deployment', 'help me choose', 'PingOne vs AIC vs PingFederate', 'which Ping product do I need', 'recommended starting point', 'test this end to end / validate my Ping setup'. Even when a specific feature, service, or product is mentioned (KYC, MFA, Verify, DaVinci, etc.), if the framing is 'where do we start' or 'we are evaluating' or 'we are migrating' — route here FIRST. Also triggers on bare user-management commands with no platform named: 'Add a user to Ping', 'Create a user in Ping', 'Manage users in Ping' — Ping has many products with separate user populations (PingOne, PingOne Advanced Identity Cloud / AIC, PingFederate, PingDirectory); for these prompts you MUST respond with action 'clarify' asking which platform, not 'route'. Catch-all front door when platform or starting point is unclear. Also invoke with /ping-quickstart." | ||
| description: "Use before any other Ping skill when the user is in orientation mode — 'where do I start', 'which Ping product do I need', 'help me choose', 'we're evaluating', 'migrating from ForgeRock/existing identity platform', 'inherited a Ping deployment', or when platform is unknown. Also use for bare user-management commands with no platform named ('Add a user to Ping') — clarify platform before routing." |
There was a problem hiding this comment.
Get rid of migrating from ForgeRock as I don't even know what that means.
| --- | ||
| name: ping-universal-services | ||
| description: "Use this skill whenever the task involves configuring or invoking a Ping shared service at the policy or service level. Triggers: PingOne Protect (risk scoring, predictors, risk policies, Signals SDK); PingOne Verify (KYC, identity proofing, document + liveness, verification policies); PingOne MFA (device management, MFA policies, enrollment API, MFA-as-a-service); PingOne Credentials (verifiable credential issuance, presentation, revocation); PingOne IGA (access requests, access reviews, provisioning, entitlements); PingOne Authorize (fine-grained authorization, ABAC policies); cross-platform SSO; 'which shared service do I need'. Service-in-flow rule — when a Protect, Verify, IGA, or Authorize node or connector appears inside a DaVinci flow or AIC journey, configuring that node, connector, or service invocation belongs here, NOT in ping-orchestration. Orchestration owns the flow shape; this skill owns the service node configuration regardless of where the node lives. MFA region guardrail — for Workforce MFA tasks, always establish the admin's PingOne region (console domain: .pingone.sg for Singapore vs .pingone.com/.eu/.asia for other regions) before advising on service model or available methods; the service model differs by region. Do NOT trigger on vague 'add security' requests — clarify which service first. Also invoke with /ping-universal-services." | ||
| description: "Use when configuring or invoking a Ping shared service at the policy or service level — PingOne Protect (risk scoring), PingOne Verify (KYC/identity proofing), PingOne MFA (device management, enrollment API), PingOne Credentials (verifiable credentials), PingOne IGA, or PingOne Authorize (fine-grained authorization). This skill owns service node configuration inside DaVinci flows and AIC journeys." |
There was a problem hiding this comment.
Add PingOne Privilege.
| --- | ||
| name: ping-foundation | ||
| description: "Use this skill whenever the task involves setting up, configuring, or administering any Ping Identity platform — PingOne (multi-tenant cloud), PingOne Advanced Identity Cloud (AIC), PingFederate, PingAccess, PingDirectory, or PingID. Triggers: create or manage environments, tenants, realms; register OIDC, SAML, WS-Federation, or OAuth 2.0 apps; configure SSO, Platform SSO, or workforce single sign-on; manage directories, LDAP, user populations, or schema; configure sign-on policies, authentication policies, or step-up MFA policy settings at the platform level; configure MFA methods or PingID in PingFederate; branding, custom domains, or notification templates; administer on-premises Ping software; advisory questions like 'how should I structure my tenant' or 'what grant type should I use'. Prerequisite — a specific platform must be named or clearly implied; 'add a user to Ping' or 'create a user in Ping' without a named platform belongs in ping-quickstart first. Also invoke with /ping-foundation." | ||
| description: "Use when setting up, configuring, or administering any Ping Identity platform — PingOne, PingOne Advanced Identity Cloud (AIC), PingFederate, PingAccess, PingDirectory, or PingID. Covers tenant/environment creation, app registration (including Worker apps and service accounts for M2M API access), SSO, directories, policies, and branding. Requires a named or clearly implied platform." |
There was a problem hiding this comment.
We are missing a lot of software here. I would just put "Ping Advanced Identity Software (i.e. PingAM, PingFederate, PingDirectory).
- ping-identity-for-ai: remove internal '5-pillar architecture' jargon - ping-quickstart: replace 'ForgeRock/existing identity platform' with 'existing identity platform' (no product names) - ping-universal-services: add PingOne Privilege (PAM) - ping-foundation: replace flat product list with 'Ping Advanced Identity Software (PingAM, PingFederate, PingAccess, PingDirectory, PingID)' umbrella term per Brando's suggestion Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
…ates Addresses gaps identified via Glean research sweep across all 6 skills. New curated anchors: - ping-foundation/cross-platform/ping-cli-basics.md — Ping CLI 1.0 unified configuration automation: install, profiles, CRUD, platform export for Terraform/CaC, CI/CD patterns, gotchas; boundaries vs MCP servers and Terraform providers - ping-foundation/cross-platform/config-promotion.md — cross-platform configuration promotion covering PingOne native promotion, AIC self-service promotions, and Ping CLI + Terraform GitOps; model selection table; hard limits and constraints (EA-framing follows editorial rule 1a — behavioural constraints only, no dated GA claims) - ping-orchestration/cross-platform/journey-and-flow-promotion.md — journey/ flow-specific promotion depth: ESV integrity checks, orphaned scripts, DaVinci flow versioning and promotion variables, environment lock impact, per-node considerations, rollback behaviour Skill routing: - ping-foundation/SKILL.md: new Cross-platform tooling section with Ping CLI and config-promotion routing rows; pingcli trigger added to description and When to use list - ping-orchestration/SKILL.md: config-promotion row added to Cross-platform orchestration patterns Eval coverage: - ping-foundation.yaml: T-80–T-82 (Ping CLI), T-83–T-85 (config promotion), N-07–N-08 - ping-orchestration.yaml: T-59–T-61 (journey/flow promotion) API docs link update (#7): - 5 legacy apidocs.pingidentity.com links replaced with verified developer.pingidentity.com/pingone-api/ canonical URLs across service-invocation-patterns.md, core-admin-patterns.md, and tenant-and-environment-setup.md - grep confirms zero remaining apidocs.pingidentity.com references All validators pass: 6 skills, 69 curated anchors, all prompt YAML valid. Layer 1 + Layer 2 evals: 100% pass rate across all 5 skills. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Summary
ping-identityskill descriptions with shorter (~50 word) routing-signal versionsping-foundationto prevent batch job / service account requests leaking toping-app-integrationMotivation
Skill descriptions are loaded into context for every agent interaction to support skill selection. The existing descriptions (120–160 words each) were carrying routing logic, negative guards, and inline instructions that are already present in the skill bodies — adding ~900 words of context overhead that fires regardless of whether a skill is actually used. The Slack thread in
#3-headless-build-with-ai-agent-skillsflagged this as causing issues in some agent environments, and the right frame is that descriptions should be index entries not summaries.Validation
Ran a 20-case multi-skill routing eval covering AIC vs PingOne routing (8 cases), cross-skill boundaries (6), orientation/quickstart (4), and AI agent boundaries (2):
The AIC/PingOne distinction is fully preserved. The one remaining failure ("add push MFA to an existing DaVinci flow" routing to universal-services instead of orchestration) is a pre-existing ambiguity present in both description sets.
Test plan
🤖 Generated with Claude Code