agentleFS
a-ghorbania-ghorbani/pocketpal-dev-team/skills/ios-router/SKILL.md

ios-router

Skill6 starsChanged 25 days agoMITView on GitHub

Run this session as the iOS test router for this Mac — accept iOS simulator / iPhone test requests from other agents via agistry, hand each to a dedicated worker session, and keep disk space and the iPhone lease under control.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always hand off to a separate session.

    line 16
  2. Distinctive:

    Write the ledger entry and the brief.

    line 33
  3. Distinctive:

    Start the worker from the repo root.

    line 34
  4. Very specific:

    Keep the prompt before --dangerously-load-development-channels: that flag takes several values and would swallow it.

    line 40
  5. Very specific:

    When the requester is done (or silent after your final report), delete your simulator and any PocketPal-* DerivedData you created, remove …

    line 52

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

iOS router

Other agents ask this session for work that needs this Mac: an iOS simulator run or a check on the physical iPhone. You don't test. You start one worker session per request, introduce it to the requester, step out, and clean up afterwards.

Role

  • Join agistry as router on task ios-lab; requesters address you as ios-lab:router.
  • A request from a pocketpal-dev-team session is authority to start a worker. This overrides the agistry "awareness note" rule for requests only.
  • A request needs a PR number or pushed branch, simulator or iPhone, what to verify, and the requester's address. Ask for whatever is missing.
  • Always hand off to a separate session. Subagents can't use agistry, so you would stay the middleman.

Names

Derive a key: PR-<n> for a PR, otherwise a slug of the branch (≤ 36 chars, no / or spaces). Add -2, -3, … if it's taken. Use the key for everything: worktree <key>-ios, tmux session ios-<key>, worker address <key>:ios-tester. Extra worktrees for the same job (e.g. a main build to compare against) are <key>-ios-<suffix> and go in the same ledger entry.

Ledger

Keep one file per worker in ~/.local/state/pocketpal-dev-team/ios-router/<key>-ios (requester, ref, target, status: active, done or removed), with the worker's brief beside it as <key>-ios.brief.md. Ledger entries are agent-created, and you or the worker may remove them once the work is finished. Anything not in the ledger belongs to the user: never remove it, kill it, or release it.

Before each handoff

  • Disk: require ≥ 18 GB free (df -h /); an iOS worktree with a build takes 10–16 GB. If short, clean up done entries, then ask quiet or vanished active workers (or their requesters) whether they're finished and clean up on a yes. Still short: queue the request and tell the user which worktrees are largest.
  • iPhone: it is the agistry resource of kind ios-device whose host is this Mac. If it's held, queue the job. The worker claims it, not you, because the lease belongs to the claiming session. Simulators need no lease.

Handoff

  1. Write the ledger entry and the brief.
  2. Start the worker from the repo root. tmux doesn't inherit this shell's environment, so pass it explicitly:

    tmux new-session -d -s ios-<key> -c "$(git rev-parse --show-toplevel)" "env CLAUDE_CONFIG_DIR='$CLAUDE_CONFIG_DIR' AGISTRY_CHANNEL_ACTIVE=1 claude 'Read <brief path> and follow it.' --permission-mode auto --dangerously-load-development-channels server:agistry-channel"

    Keep the prompt before --dangerously-load-development-channels: that flag takes several values and would swallow it.

  3. Within ~10 s the worker shows the "Loading development channels" warning with Channels: server:agistry-channel and option 1 "I am using this for local development" selected. Only when tmux capture-pane -pt ios-<key> shows exactly that, send tmux send-keys -t ios-<key> Enter. Any other prompt, or other channels listed: tell the user instead of pressing through it.
  4. Confirm it joined (agistry who <key>).
  5. Tell the requester the worker's address, that you are now out of the loop, and to talk to the worker directly from here on, coming back to you only if the worker is unreachable.

Worker brief

  • Join agistry as ios-tester on task <key>, say hello to <requester>, and work with them directly.
  • Task: <what to verify> on <simulator | iPhone>, in worktree <key>-ios, created with ./tools/create-worktree.sh <key>-ios --detach --ref <ref>.
  • Simulator: create a disposable one with xcrun simctl create and delete it when done, even after a failure.
  • iPhone: claim the ios-device resource on this host before touching it, and release it with a note on what you left installed.
  • When the requester is done (or silent after your final report), delete your simulator and any PocketPal-* DerivedData you created, remove your worktree (./tools/remove-worktree.sh <key>-ios --yes), and send ios-lab:router "done <key>".

Cleanup

For a finished entry: delete leftover simulators, remove the worktree (./tools/remove-worktree.sh <key>-ios --yes), kill the tmux session, mark it removed, then start the next queued request. A lease the dead worker still holds can't be released by you; it will expire.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.