feat(setup): recognize Grok as a universal skill reader

[KatalKavya96]

Summary

• Recognize Grok as a reader of Magpie's canonical .agents/skills/ universal skill path instead of introducing a Grok-specific skill target.
• Keep setup install/upgrade guidance, status rendering, fallback metadata, and setup-status fixtures aligned with the updated universal reader list.
• Fix stale skills/setup/agents.md references in the harness authoring guide so they point to the current registry under plugins/magpie-setup/skills/setup/agents.md.

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other: setup agent-target registry/status metadata and corresponding eval fixtures

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:
  • python3 -m py_compile plugins/magpie-setup/skills/status/scripts/collect_status.py
  • verified load_agent_targets() resolves Grok through the existing universal target and does not create a grok target
  • ran all 18 setup-status eval fixtures in runner print/assembly mode
  • uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-validate
  • full prek suite passed with TMPDIR=/tmp on macOS

RFC-AI-0004 compliance

• HITL — any new mutation is gated on explicit user confirmation
• Sandbox — no new unrestricted host access; network reach declared in the adapter
• Vendor neutrality — Grok reuses the existing canonical .agents/skills/ path rather than adding a vendor-specific skill placement
• Conversational + correctable — agentic-override path documented if behaviour is adopter-tunable
• Write-access discipline — no autonomous outbound messages; drafts only, sent on confirmation
• Privacy LLM — private content does not reach a non-approved LLM; redactor invoked where needed

Linked issues

Refs #1416

Notes for reviewers

This PR intentionally covers only the skill-discovery/setup portion of Grok support.

Grok already reads the standard .agents/skills/ project path, so no .grok/skills/ relay or Grok-specific setup target is needed. The existing universal target remains the single canonical placement.

Agent-guard integration, headless spec-loop support, and first-class adapter documentation/registry promotion are intentionally left for follow-up PRs under #1416.

The first full prek run hit macOS's AF_UNIX path-length limit in an unrelated container-gateway temporary socket test. Re-running with TMPDIR=/tmp made the full workspace test and prek suite pass.

[KatalKavya96]

@potiuk I’ve started splitting the Grok work into small reviewable PRs.

The first slice only wires Grok into the existing universal .agents/skills/ path and keeps setup/status surfaces + fixtures consistent — no Grok-specific skill target or .grok/skills/ relay, since Grok already reads the shared path natively.

Next I’m planning:

1. Grok PreToolUse integration with agent-guard
2. Grok headless support in spec-loop
3. final adapter docs / registry promotion

Keeping the runtime/security changes separate should make each piece easier to review.

[potiuk]

Thanks — I pushed a fixup commit (4c61a6c) rather than going another round, and approving with it.

What I changed and why. xAI's Grok reads project skills from .grok/skills/ only — it reads .agents/skills/ at user scope (~/.agents/skills/), not in the project (Grok skills docs). So listing it under the universal target would have recorded an inaccurate fact in the registry that collect_status.py copies into every adopter's status dashboard. The fixup:

• Drops Grok from the universal reader lists — the registry row and prose, the setup/status subdocs, the collect_status.py fallback tuple, and the setup-status eval fixtures go back to their previous wording.
• Adds a grok registry row (.grok/skills/, native relay), with a note citing the xAI docs. The note also records that Grok reads Claude Code skills and instruction files, so the .claude/skills/ relays already reach it. (Per the same docs Grok reads the AGENTS.md family natively too, which answers the other open question in #1416.)
• Wires .grok/skills/ exactly like .kiro/skills/: committed magpie-* relay symlinks into .agents/skills/, the .gitignore and .gitattributes (export-ignore) entries, the symlink-lint prek file patterns, list_skills.py's directory list, and the release-contents doc.

Your add-a-harness.md link update is kept. prek run --all-files and both symlink-lint passes (tree and release archive) are green locally.

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Magpie handles maintainer review:
CONTRIBUTING.md.