Mobile harness does not register project skills from .claude/skills/ as slash commands

[kingofrock]

Summary

On the Claude Code mobile app (iOS), project-level skills under .claude/skills/*/SKILL.md are present on disk and readable by the model via context, but are not registered as user-invocable slash commands — AND the Skill tool dispatched programmatically by the agent cannot resolve them either. The desktop CLI registers both paths correctly.

Reproduction

1. Mobile session on a project whose .claude/skills/ contains N custom skills (e.g., /skill-a, /skill-b, /skill-c)
2. In session, type /skill-a
3. Agent responds conversationally instead of invoking the skill via the Skill tool
4. Ask agent: "what slash commands are available?" — only ~12 built-ins appear (/update-config, /simplify, /loop, /claude-api, /session-start-hook, /init, /statusline, /review, /security-review, /insights, /team-onboarding, /keybindings-help)
5. Ask agent to ls .claude/skills/ — N custom skills present on disk
6. Agent attempts Skill("skill-a") programmatically — returns Unknown skill: skill-a

Expected

Project skills should be registered and invocable via both paths (user /slash typing AND the agent's Skill tool) on mobile, matching desktop behaviour.

Impact — two axes

Axis 1: user UX

Operators cannot invoke custom skills via slash commands on mobile. They must describe them in natural language (e.g., "run the analyze skill"), relying on the agent to Read and follow the SKILL.md directly.

Axis 2: agent autonomous / chained execution

This is the bigger impact. Any autonomous / multi-skill workflow that chains through skill invocations (e.g., /analyze → /plan → /code → /test → /stage, or whatever SDLC phases a given project defines) fails on mobile because every chained Skill("<name>") call returns Unknown skill.

Workaround possible via a project-level rule: instruct the agent on mobile to invoke custom skills by Read(".claude/skills/<name>/SKILL.md") then execute the protocol inline. This works for behavioral equivalence, BUT:

Token-cost asymmetry: each invocation now lands the full SKILL.md content in conversation context (vs. a short tool call + result). For a 20-skill autonomous chain:

Path	Tokens for skill machinery
Tool dispatch (desktop)	~15-30k
Read + interpret (mobile workaround)	~60-100k

On mobile — where sessions already have tighter effective context budgets and compaction is more brittle than desktop — this hits the compaction threshold 2-3 skills sooner than desktop. Autonomous chains still run, just more compactions, more re-reading of survival context, more turn budget consumed.

Context

Projects distribute skills under .claude/skills/ using the documented directory layout. Desktop Claude Code registers these at session start; mobile apparently does not. The substrate files themselves land correctly (rules, agents, custom skill files all on disk and readable by model context via additionalDirectories inheritance); it's specifically the mobile harness's slash-command / Skill-tool registry step that doesn't pick up .claude/skills/ entries.

Environment

• Mobile: claude.ai/code iOS app, tested 2026-04-15
• Skills: .claude/skills/*/SKILL.md with standard frontmatter (name, description, etc.)
• Readable from model context: ✅ (the additionalDirectories / CLAUDE.md inheritance path DOES surface them)
• Resolvable by Skill tool: ❌

Desired behavior

Mobile harness should scan .claude/skills/*/SKILL.md at session start (ideally post-SessionStart-hook) and register each discovered skill in both the user slash-command UI AND the Skill tool's resolvable set, matching desktop CLI behavior.

Related

• Desktop CLI handles this correctly — both .claude/skills/ and additionalDirectories skills are registered
• Model can still follow skill content via Read(SKILL.md) + inline execution if instructed via a project-level rule, at the token cost described above

[github-actions]

Found 3 possible duplicate issues:

1. Project-level skills in .claude/skills/ not discovered #33733
2. Custom skill in .claude/skills/ recognized but fails with 'Unknown skill' when invoked #34586
3. [BUG] Skill loads into context and works via the internal Skill tool, but /skill-name and /plugin:skill slash commands return "Unknown skill" #37956

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

Project skills from .claude/skills/ not registering as slash commands in the mobile harness is a capability discovery gap — the skills exist and are valid, but the mobile environment is not surfacing them to the user or including them in the command registry.

From an agent identity perspective, skills are part of the agent capability declaration — what this Claude Code instance can do in this project context. If the mobile harness presents a different capability set than the desktop harness for the same project, the agent is presenting an inconsistent identity to the user across surfaces. A user who authored skills expecting them to be available in mobile will make incorrect assumptions about agent capability.

Two additions worth considering:

1. Capability manifest at session start. Claude Code should log (and optionally display) the full capability set at session start — which skills loaded, which slash commands registered, which MCP servers connected. Differences across harnesses would then be immediately visible rather than discovered mid-workflow.

2. Harness capability negotiation. If mobile has limitations (no shell access, sandboxed file system, etc.), the capability manifest should explicitly list what was omitted and why. "Skills not loaded: requires shell access unavailable in mobile harness" is actionable; silent non-registration is not.

This also matters for behavioral trust — an agent that advertises skills it cannot execute (or fails to advertise skills it can) has a capability claim that does not match its behavioral reality. Consistent capability declaration across harnesses is a component of agent identity integrity.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[koxon]

Requesting reopen — symptom still present on Android (Claude Code mobile app, latest version).

Project skills under .claude/skills/*/SKILL.md are not surfaced as slash commands in the mobile UI: typing / gives no autocomplete for them, and the agent's Skill tool dispatch from the same project returns "Unknown skill" for entries that the desktop CLI registers without issue. From the user side this reads as "skills are broken on mobile" — the only workaround is describing the skill in natural language and hoping the agent Reads the SKILL.md directly, which loses the autocomplete affordance and the slash-command UX entirely.

The stale-bot auto-close today (10:47 UTC) was premature — the capability gap between desktop and mobile harnesses hasn't been addressed. Happy to provide a fresh repro on request.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.