Recently I ran into a puzzling issue while connecting an application to ADFS using its built-in OpenID Connect support. The login worked fine, the user got authenticated, but the ID token contained almost nothing I needed. No group claims, no custom attributes, just the basics. The claim rules were configured correctly. So where were my claims? Where did my claims go? ADFS keeps a strict separation between the two tokens. The claims you define through the issuance transform rules end up in the access token. The ID token gets a much smaller set by default. If your application reads the ID token to get user information, you have two options: Call the userinfo endpoint with the access token Ask ADFS to copy the access token claims into the ID token This is where the allatclaims scope comes in. What does allatclaims do? When the authorization request includes scope=allatclaims , ADFS customizes the ID token so it includes the claims from the access token, based on ...
Coding agents are good at explaining things. They are also good at explaining them in five verbose paragraphs when a ten-line tree would have done the job. You would almost think that output tokens are free! Recently I came across the show-me skill from HumanLayer . It’s a small skill with one purpose: when you ask your agent to explain something, it answers with a visual representation instead of a wall of text. What does it do? The whole skill is a short set of instructions. It tells the agent to skip the preamble, keep the prose brief and pick the smallest view that makes the point clear. Sounds simple? Because the idea is indeed. For each kind of explanation, the skill names the view to use: Logic or an algorithm → pseudocode Runtime control flow → a call tree UI structure → a component tree, including the state and module boundaries that matter File responsibility or a broad refactor → a shallow file tree Component interaction or data flow → a Me...