randroid

What this skill does

# Randroid Commands

## loop

Run the autonomous research/implementation loop. In Claude Code, use `/randroid:loop`.

The loop supports either task tracker:
- `dot-html` for HTML-backed tasks under `.dots/`
- `dot` for Markdown-backed tasks under `.dots/`

Each iteration detects the project tracker and uses the selected command as `$DOT`. Do not mix `dot` and `dot-html` in one project.

Bundled loop resources:
- `commands/loop.md`: Claude Code slash command instructions
- `research-loop.md` and `implement-loop.md`: mode-specific prompts
- `loop-shared.md`: shared task tracker, git workflow, iteration, and completion rules
- `scripts/setup-loop.sh`: initializes loop state
- `scripts/randroid-loop.sh`: external loop wrapper for Codex
- `hooks/stop-hook.sh`: Claude Code keep-context loop hook

## address-pr-comments

Address every actionable PR review comment end to end: inspect the feedback, update the code, verify the change, and reply clearly.

### Workflow

1. Identify the target PR from the user's link/number, the current branch, or the available GitHub tooling. If no PR can be identified, ask for the PR URL or number.
2. Gather all review comments, review threads, requested changes, and relevant CI context. Prefer thread-aware APIs when available so resolved and outdated comments are not mistaken for open work.
3. Classify each comment as actionable, already addressed, outdated, duplicate, or needing clarification. Do not ignore requested changes.
4. Implement fixes for all actionable comments. Keep edits scoped to the review feedback unless a nearby change is required for correctness.
5. Run the smallest meaningful verification for the changed area. If verification cannot run, say exactly why in the PR response and final message.
6. Reply to each addressed thread, or leave a concise PR summary if the available tooling cannot reply inline. Mention what changed and any tests run.
7. Do not mark a thread resolved unless the issue is actually fixed or the reviewer explicitly made it non-actionable.

### Comment Signature

Every comment or reply posted to GitHub must end with this signature on its own line:

```text
-- Randroid (Randy's Bot)
```

Do not use a different sign-off. Do not omit the signature from inline review replies, PR comments, or review summaries.

### Response Style

- Be specific about the files or behavior changed.
- Keep replies short; reviewers need status, not a changelog.
- If a comment is not actionable, explain why and sign the reply.
- If user approval is required before posting comments in the current harness, prepare the exact signed comment text and ask before posting.

## vibereview

Run browser-game playtest review sessions with the VibeReview headless CLI. In Claude Code, use `/randroid:vibereview`.

VibeReview records review sessions, screenshots, browser-state snapshots, notes, severity, rating, and tags, then writes review artifacts into the target project. In Spiral-HTML projects, those artifacts are evidence for the qualitative gate: `docs/PLAYTEST.html`, `docs/FOLLOWUPS.html`, `docs/OPEN_QUESTIONS.html`, and `docs/FUN_FACTOR_AUDIT.html`.

Use this command when the user asks to review, playtest, capture feedback, record evidence, or turn a human game-review observation into project artifacts.

VibeReview does not replace hands-on review. When the agent is doing the review itself, it should use available browser-control tools to open the target game, interact with it, inspect visible behavior, and reproduce observations before running `"$VIBEREVIEW_CLI" capture`. Use the in-app Browser for local URLs such as `localhost`, `127.0.0.1`, or `file://` when available. Use Chrome when the review depends on an installed Chrome extension, logged-in browser state, existing tabs, or the VibeReview Chrome extension bridge.

### Preflight

First choose a real headless CLI path and store it in `VIBEREVIEW_CLI`. Do not start by running the bare `vibereview` command. On some machines `/usr/local/bin/vibereview` is an app launcher into `/Applications/VibeReview.app`; calling it can open GUI windows instead of printing CLI output.

Prefer standalone build artifacts outside `VibeReview.app`. The known-good candidates are `.build/reinstall/vibereview` and `build/vibereview` inside the VibeReview repo. The snippet checks both a sibling repo from the current working directory and Randy's normal local source path:

```bash
VIBEREVIEW_CLI=""
for candidate in \
  "../VibeReview/.build/reinstall/vibereview" \
  "../VibeReview/build/vibereview" \
  "/Users/randroid/Documents/Dev/VibeReview/.build/reinstall/vibereview" \
  "/Users/randroid/Documents/Dev/VibeReview/build/vibereview"
do
  if [[ -x "$candidate" ]]; then
    VIBEREVIEW_CLI="$candidate"
    break
  fi
done

if [[ -z "$VIBEREVIEW_CLI" ]]; then
  if [[ -x "../VibeReview/scripts/build.sh" ]]; then
    ../VibeReview/scripts/build.sh
    VIBEREVIEW_CLI="../VibeReview/build/vibereview"
  elif [[ -x "/Users/randroid/Documents/Dev/VibeReview/scripts/build.sh" ]]; then
    /Users/randroid/Documents/Dev/VibeReview/scripts/build.sh
    VIBEREVIEW_CLI="/Users/randroid/Documents/Dev/VibeReview/build/vibereview"
  else
    echo "Could not find VibeReview repo or standalone CLI. Set VIBEREVIEW_CLI to the headless binary path." >&2
    exit 1
  fi
fi

if [[ "$VIBEREVIEW_CLI" == *".app/Contents/MacOS/"* ]]; then
  echo "Refusing app-bundle path: $VIBEREVIEW_CLI" >&2
  exit 1
fi

"$VIBEREVIEW_CLI" --version
```

If the build artifact is unavailable, inspect any alternate path before executing it. Avoid `/usr/local/bin/vibereview` when it resolves under `/Applications/VibeReview.app`. Also avoid `../VibeReview/build/VibeReview.app/Contents/MacOS/vibereview`: on case-insensitive APFS, lowercase `vibereview` collides with the GUI executable `VibeReview`, so that path can launch the app instead of the CLI.

```bash
readlink /usr/local/bin/vibereview 2>/dev/null || true
```

Use the verified `"$VIBEREVIEW_CLI"` path in every command below. Do not substitute bare `vibereview` unless it has already been verified not to launch the GUI.

For browser snapshots:

- Keep the VibeReview Chrome extension loaded in the Chromium browser tab under review.
- If the extension is not installed, install it from source: open Chrome or another Chromium browser to `chrome://extensions`, enable Developer Mode, click "Load unpacked", and choose `../VibeReview/ChromeExtension` from this skills repo. If working from a different directory, resolve that path to the sibling VibeReview repo.
- The CLI listens briefly on `http://127.0.0.1:37717/snapshot` during capture.
- If capture reports that the browser snapshot is unavailable, preserve the screenshot/note result and mention that the extension or port was not available.
- If port `37717` is occupied by the VibeReview app or another process, close the app/process or retry when the port is free.

### CLI Reference

```bash
"$VIBEREVIEW_CLI" start --project <path> [--title <title>]
"$VIBEREVIEW_CLI" capture --project <path> --note <text> [--severity note|polish|issue|blocksRelease] [--rating 1...5] [--tags a,b,c]
"$VIBEREVIEW_CLI" capture --project <path> --note-file <path-or->
"$VIBEREVIEW_CLI" end --project <path>
"$VIBEREVIEW_CLI" status [--project <path>]
"$VIBEREVIEW_CLI" list
"$VIBEREVIEW_CLI" --version
```

Defaults:

- `--severity` defaults to `issue`.
- `--rating` defaults to `3`.
- `--tags` is a comma-separated list; empty entries are ignored.
- `--note-file -` reads the note from stdin.

### Review Workflow

1. Identify the project root. Use the game repo path, not the skills repo path.
2. Start or resume a review session:

   ```bash
   "$VIBEREVIEW_CLI" start --project /path/to/game --title "Playtest review"
   "$VIBEREVIEW_CLI" status --project /path/to/game
   ```

3. Open the game with browser-control tools and play enough to observe behavior directly. Prefer the in-app Browser for local dev servers and Chrome when the VibeReview extension or existing browser