grok inspect printed yaml-yes and literal-true on consecutive lines. Both lines ended with the word project. Neither line said that one of those skills is not a slash command. The JSON report for the same directory said userInvocable was false for yaml-yes and true for literal-true. The frontmatter difference was one token: yes versus true.
That is the check a copied Claude skill needs before anyone binds /yaml-yes in a script or tells a teammate the command exists. The human summary that the installed guide offers first does not make the check. On Grok 1.0.67, an untrusted folder makes the same summary say the skill is absent, which is a different mistake.
What was measured
The binary was Grok Build 1.0.67, build 2fe064390d07, on Linux amd64. Its SHA-256 was ce33b1a29e37901f56fe59916cda7a1149e6fd377118f918e90d89f9abb52a51. The probe used a disposable git repository and a private GROK_HOME, so the scan did not include skills, trust decisions, or settings from a normal home directory. grok inspect and grok inspect --json were the only Grok commands that read the repository, plus one --trust invocation documented below. No model turn was started. Nothing was installed over the 1.0.67 binary.
The public changelog page, opened on 29 October 2026, listed 1.0.70 above 1.0.67. This article does not describe 1.0.70. A newer binary can parse the same frontmatter differently. The results below are the 1.0.67 report.
The repository held 18 SKILL.md files under .grok/skills/, two under .claude/skills/, and one flat command file at .grok/commands/flat-cmd.md. .gitignore ignored both .grok/ and .claude/. git check-ignore matched the ignored skill paths. A project .grok/config.toml contained one deny rule and one allow rule. Those rules are the reason the permission count below is 2. The report never printed the rule text, so the count is not a review of what the rules say.
The installed guide and the website do not say the same thing
The user guide shipped with this binary says user-invocable defaults to true and that false hides the skill from slash commands. It tells you to set disable-model-invocation if you want to stop the model from invoking the skill. It describes allowed-tools as the tools the skill uses, as a YAML list or a comma- or space-separated string. It does not say that yes fails. It does not say that allowed-tools is ignored.
The skills page on the xAI docs site, stamped 11 August 2026, says the opposite about both fields. It says only the literal true counts and that yes is false. It says false hides the skill from you and from the model. It says allowed-tools does not grant or restrict tools. That page does not name Grok 1.0.67, and it does not show grok inspect output.
Both documents tell you to run grok inspect to see discovered skills. The installed guide adds that the JSON report includes name, description, source, and userInvocable. It does not say the human summary omits userInvocable. That omission is what the probe measured.
This run cannot settle the model-side disagreement. A false userInvocable might hide the skill only from the slash menu, or it might also hide it from the model. The website asserts the second. The installed guide points at disable-model-invocation for the second. No prompt was sent, so neither sentence was tested against a live turn. The tested fact is the flag in the inspect report.
An untrusted folder reports no skills
The first grok inspect --json in the disposable repository exited 0 and returned an empty skills array. projectTrusted was false. permissions.loaded was 0 and permissions.sources was empty. The human summary said Project trusted: no, Skills (None), and 0 loaded, 0 skipped. The skill files were on disk the whole time. A reader who stops at that summary will delete a skill that was never loaded, or will copy a new one and believe discovery is broken.
The same JSON still listed the project config file under configSources. Trust and config discovery are not the same gate. The file path appearing in the report is not evidence that its deny rules are in force. Before trust, they were not loaded.
grok --help on this binary is 119 lines and does not contain the word trust. The installed guide still says headless startup needs --trust or a prior grant. The flag is accepted. grok --trust inspect --json, run from the repository root, exited 0, set projectTrusted to true, and wrote trusted_folders.toml under the private GROK_HOME. The file recorded trusted = true for that repository root and a decided_at unix time. A second grok inspect without --trust stayed trusted. The grant persisted in that home. It was not a one-shot process flag.
grok --trust with no subcommand, and with no terminal, exited 1 and printed Error: No such device or address (os error 6). On this binary the flag is not a standalone trust command that prints a confirmation and exits. Pair it with inspect if you need a non-interactive grant and a report in the same process. Do not treat a missing --trust line in grok --help as proof the flag is gone.
Trust is the repository root, not the machine. A sibling git repository, created after the first grant and given its own SKILL.md, still returned projectTrusted false and an empty skill list. The first grant did not leak across. A subdirectory of the trusted repository did inherit the grant. grok inspect --json from that subdirectory reported projectTrusted true, the same 20 skills, and the same project root.
The qualifier on a name collision changed with the working directory. At the repository root, a skill named login was userInvocable true, with collidesWith set to login and invocableAs set to local:login. From the subdirectory the same skill was repo:login. The human summary used the installed guide’s collision tag, [collides with /login → /local:login], only at the root. A wrapper that hardcodes /local:login will miss the skill when the working directory is not the directory that holds .grok/skills/. The bare name /login remains the built-in in both cases. The guide says the built-in keeps the bare name. That part matched.
Which spellings become a slash command
After the grant, the JSON listed 20 skills from 21 candidate files. The file that did not appear was the Claude copy of literal-true, whose frontmatter set user-invocable to false and whose description was not the description that won. The .grok/skills/literal-true copy remained, with description Literal YAML true and userInvocable true. The other Claude skill, claude-only, appeared with vendor set to claude and compatibilityStatus set to enabled. A same-named Claude skill does not hide the Grok skill. Inspect does not mention the file it dropped, so a false on the losing copy is not a second vote.
The human summary still did not print userInvocable. yaml-yes and literal-true were both project lines. The JSON values were:
frontmatter userInvocable
true true
True true
TRUE true
"true" true
omitted true
false false
"false" false
yes false
"yes" false
on false
no false
1 false
True and TRUE counted. The website sentence “only the literal true counts” is too narrow for this binary. A capital True, an uppercase TRUE, and a quoted "true" were all invocable. Unquoted yes, quoted "yes", unquoted on, and the integer 1 were not. Unquoted no and both spellings of false were not. Omitting the field left the skill invocable, which matches the default both documents state.
A directory named bad_name, with no name field, was reported as bad-name. A name value of spaced name was reported as spaced-name. The installed guide says spaces and underscores become hyphens. That normalization happened. A flat file .grok/commands/flat-cmd.md became a project skill named flat-cmd with userInvocable true. The guide’s note that flat command files are slash commands matched this file.
.gitignore did not remove any of those skills. The ignored paths were still in the JSON after trust. The installed guide says skill discovery does not use .gitignore and that [skills] ignore is the hide mechanism. This repository had no [skills] ignore entry. The ignore file hid the skills from git status and did not hide them from grok inspect.
One file had a description that started with an unclosed [. Inspect still listed it. The stored description was the text [this is not closed. userInvocable was true. Standard error was empty. A broken description did not drop the skill and did not produce a warning on this command. Do not treat a clean grok inspect exit as a frontmatter linter.
Fields the report never prints
No skill object contained allowed-tools, allowedTools, or a tool list. The skills whose frontmatter said Read, or Bash, Edit, had the same keys as a skill with no allowed-tools line: name, description, source, and userInvocable, plus collision or vendor fields when those applied. Inspect cannot show you a tool boundary that the field was supposed to create. The website says the field does not grant or restrict tools. The installed guide describes it as the tools the skill uses. This report cannot prove either sentence against a live tool call. It can prove that 1.0.67’s inspect JSON is the wrong place to audit the field. A permission boundary has to be a deny rule, a --deny flag, or a hook. It is not a line in SKILL.md that this command will echo back.
disable-model-invocation was also absent. The skill that set it to true and the skill that set it to yes both came back as userInvocable true, with no extra key. The human lines were disable-model and disable-yes, both marked project, with no disabled tag. The installed guide says a true value means only the slash command runs the skill. The JSON report the same guide recommends does not show that value. You cannot confirm the gate from grok inspect. A later session would have to be the test, and this one was not.
The permission section has the same shape of gap. After trust, permissions.loaded was 2 and the only source string was the project config path plus the word config. The human summary said 2 loaded, 0 skipped. It did not print Bash(rm -rf *) or Bash(git status). Before trust the same file was visible as a config source and contributed zero loaded rules. If the review you need is “which commands are denied,” open the config file. Inspect tells you whether a file was loaded. It does not quote the rules.
What to verify
Run the check from the directory where the skill will be invoked, after a grant you can see.
grok inspect --json
If projectTrusted is false and skills is empty while SKILL.md files are on disk, the folder is not trusted. grok --help may not mention the flag. This binary accepted:
grok --trust inspect --json
Read projectTrusted again. It should be true, and the skill count should match the files you expect, minus same-named copies that lost the priority order. Then read userInvocable for the skill you intend to call. true, True, TRUE, "true", and an omitted field were invocable here. yes, "yes", on, and 1 were not. The human summary is the wrong view for that question. It listed the non-command skill anyway.
If the name collides with a built-in, read invocableAs in the same working directory you will use later. At the root of this repository the login skill was local:login. One directory down it was repo:login. A script that changes directory and then types the qualifier from a root inspect will call the wrong name, or no skill.
Do not use this report as a tool allowlist. allowed-tools was not in the JSON. disable-model-invocation was not in the JSON. The two loaded permission rules were not printed. If the skill must not run a command, put that limit in a deny rule and confirm the loaded count only as a hint that the file was read. Open the file to see the text.
A clean exit is not a schema check. The unclosed description still produced a skill and an empty standard error. Read the description string back if a slash menu is showing a skill you do not recognize.
This comparison did not send a prompt, did not open the TUI slash menu, and did not watch a tool call get approved or denied. userInvocable: false means this binary’s inspect report will not advertise that skill as a user command. It does not, by itself, prove what a signed-in model session will do with the same file. The installed guide and the 11 August website page still disagree on that point. Settle it with a turn you can read, not with either document alone.
Sources
- User guide shipped with Grok Build 1.0.67, Skills chapter: discovery locations,
user-invocable,allowed-tools,disable-model-invocation, gitignore behavior, and thegrok inspectJSON fields - User guide shipped with the same binary, Permissions and safety chapter: folder trust gates project skills and project permission rules
- Skills, Plugins and Marketplaces, page stamp 11 August 2026: literal
true,yesis false, andallowed-toolsdoes not grant or restrict tools - Grok Build changelog, read 29 October 2026, listing 1.0.70 above the tested 1.0.67 binary
grok inspect --jsonandgrok --trust inspect --jsonon that binary, 29 October 2026, against the disposable repository described above