fix(internal-docs): address Greptile review feedback

- Workflow: rebase onto dev before push to handle non-fast-forward race;
  bump fetch-depth 1->50 so rebase has merge-base history.
- Workflow: move INTERNAL_DOCS_SYNC_TOKEN into step env: per Actions
  credential-injection pattern, instead of inlining in the script body.
- Skill (BASE bug): suppress git rev-parse stdout so SHA does not get
  captured into BASE alongside the literal 'dev'. Was breaking every
  downstream git log/diff call.
- Skill (tmp clone): trap 'rm -rf "$TMP" EXIT after mktemp so cleanup
  always runs, even if any subsequent step fails.

.claude/skills/ask-internal/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: ask-internal
+description: Answer questions about BrowserOS internal stuff (setup, features, architecture, design decisions) by reading the private internal-docs submodule and the codebase. Use for "how do I X", "where is Y", "what is the deal with Z", or any question that mixes ops/setup knowledge with code knowledge. Can execute steps with per-command confirmation.
+allowed-tools: Bash, Read, Grep, Glob, Edit, Write
+---
+
+# Ask Internal
+
+Answer team-internal questions by reading `.internal-docs/` and the codebase, synthesizing a direct answer with file:line citations, and optionally running surfaced commands with confirmation.
+
+**Announce at start:** "I'm using the ask-internal skill to answer this from internal-docs and the codebase."
+
+## When to use
+
+- "How do I reset my dogfood profile?"
+- "What's the deal with the OpenClaw VM startup?"
+- "Where do we configure release signing?"
+- Any question whose answer lives in setup runbooks, feature notes, architecture docs, or the code that produced them.
+
+## Hard rules — never do these
+
+- NEVER execute a state-mutating command without per-command `y` confirmation from the user.
+- NEVER edit BrowserOS code in response to an ask-internal question. The skill answers; it does not modify code. Use `/document-internal` for writes.
+- NEVER guess. If grep finds nothing useful in docs or code, say so plainly.
+- NEVER run this skill if `.internal-docs/` is missing. Stop with the init command.
+- NEVER cite a file or line number you have not actually read.
+
+## Voice rules
+
+Apply the same voice rules as `document-internal` to the synthesized answer:
+
+- Lead with the point.
+- Concrete nouns. Name files, functions, commands.
+- Short sentences. Active voice. No em dashes.
+- Banned words: delve, crucial, robust, comprehensive, nuanced, multifaceted, furthermore, moreover, additionally, pivotal, landscape, tapestry, underscore, foster, showcase, intricate, vibrant, fundamental, significant, leverage, utilize.
+- No filler intros.
+
+## Workflow
+
+### Step 0: Pre-flight
+
+```bash
+if git submodule status .internal-docs 2>/dev/null | grep -q '^-'; then
+  echo "internal-docs submodule not initialized. Run: git submodule update --init .internal-docs"
+  exit 0
+fi
+[ -d .internal-docs ] && [ -n "$(ls -A .internal-docs 2>/dev/null)" ] || {
+  echo ".internal-docs/ missing or empty. Submodule not configured?"
+  exit 0
+}
+```
+
+### Step 1: Parse the question
+
+Pull the keywords from the user's question. Drop stop words. Identify intent:
+
+- **Setup-question** ("how do I", "how to", "where do I configure"): bias the search toward `setup/`.
+- **Feature-question** ("what is X", "why does X work this way"): bias toward `features/` and `architecture/`.
+- **Free-form** ("anything about Y"): search all categories.
+
+### Step 2: Multi-source search
+
+Run grep in parallel across two sources.
+
+**Internal docs:**
+
+```bash
+grep -rni --include='*.md' '<keyword>' .internal-docs/
+```
+
+Search each keyword separately. Collect top hits by relevance (more keyword matches = higher).
+
+**Codebase (skip vendored Chromium and `node_modules`):**
+
+```bash
+grep -rni --include='*.ts' --include='*.tsx' --include='*.js' --include='*.json' --include='*.sh' \
+     --exclude-dir=node_modules --exclude-dir=chromium --exclude-dir=.grove \
+     '<keyword>' packages/ scripts/ .config/ .github/
+```
+
+Read the top 3-5 doc hits and top 3-5 code hits. Do not skim — read the relevant section fully so citations are accurate.
+
+### Step 3: Synthesize answer
+
+Structure the response:
+
+1. **Direct answer.** First sentence answers the question. No preamble.
+2. **Steps if applicable.** Numbered list with exact commands.
+3. **Citations.** Every factual claim references `path/to/file.md:42` or `path/to/code.ts:117`. Run the voice self-check before printing.
+
+If multiple docs cover the topic at different layers (e.g., a setup runbook and a feature note both mention dogfood profiles), reconcile them in the answer rather than dumping both.
+
+### Step 4: Offer execution (only if commands surfaced)
+
+If Step 3 produced executable commands the user could run, ask:
+
+> Run these for you? (y / n / dry-run)
+
+- **y:** Execute one at a time. For any command that mutates state (writes a file, modifies config, kills a process, deletes anything), ask "run this? <command>" before each. Read-only commands (`ls`, `cat`, `git status`) run without per-command confirmation but still print before running.
+- **n:** Skip. Done.
+- **dry-run:** Print the full sequence as a `bash` block. Do not execute.
+
+### Step 5: Doc-not-found path
+
+If Step 2 returned nothing useful (no doc hits AND no clear code answer):
+
+1. Tell the user: "No doc covers this. Tangentially relevant files: <list>."
+2. Ask: "Draft a new doc and open a PR to internal-docs?"
+3. On yes: invoke the full `/document-internal` flow (four sharp questions, draft, voice check, PR), forced to `setup/` doc type, with the code-grep findings handed in as initial context.
+
+### Step 6: Completion status
+
+Report one of:
+
+- **DONE** — answer delivered, citations verified.
+- **DONE_WITH_CONCERNS** — answered, but flag uncertainty (e.g., docs and code disagreed; user should reconcile).
+- **BLOCKED** — submodule missing or other pre-flight failure.
+- **NEEDS_CONTEXT** — question too vague to search effectively. Ask one clarifying question.
+
+## Citation discipline
+
+Every "X is at Y" claim in the answer must point to a file:line that the skill actually read. Do not approximate. If you didn't read it, don't cite it.
+
+If a doc says one thing and the code says another, surface the conflict explicitly:
+
+> The setup runbook (`setup/dogfood-profile.md:23`) says to delete `~/.cache/browseros/dogfood`, but the actual code path in `packages/cli/src/cleanup.ts:47` removes `~/.local/share/browseros/dogfood`. The doc looks stale. Recommend updating it.
+
+## Common Mistakes
+
+**Skimming and then citing**
+- **Problem:** Citation points to a line that doesn't actually contain the claim.
+- **Fix:** Read the section fully before citing. If you didn't read line 117, don't cite line 117.
+
+**Executing without per-command confirmation for mutations**
+- **Problem:** User says "y" to "run all", skill blasts through `rm -rf`-style commands.
+- **Fix:** "y" means "run this sequence with per-mutation confirmations". Per-command y is required for writes.
+
+**Searching only docs, not code**
+- **Problem:** Doc says X but code does Y; answer is wrong.
+- **Fix:** Always grep both sources in Step 2.
+
+## Red Flags
+
+**Never:**
+- Cite a file:line you haven't read.
+- Run mutations without per-command confirmation.
+- Modify BrowserOS code from this skill (use `/document-internal` for writes).
+
+**Always:**
+- Pre-flight check before any search.
+- Reconcile doc vs code conflicts in the answer, don't hide them.
+- Plain "no doc covers this" when grep is empty — never invent.

.claude/skills/document-internal/SKILL.md

@@ -0,0 +1,208 @@
+---
+name: document-internal
+description: Draft a 1-page internal doc (feature, architecture, or design) for the private browseros-ai/internal-docs repo. Use when wrapping up a feature on a branch, after the PR is open or about to be opened. Skill drafts from the diff, asks four sharp questions, enforces voice rules, and opens a PR to internal-docs.
+allowed-tools: Bash, Read, Write, Edit, Grep, Glob
+---
+
+# Document Internal
+
+Draft a 1-page internal doc (feature note, architecture note, or design spec) from the current branch's diff and open a PR to `browseros-ai/internal-docs`.
+
+**Announce at start:** "I'm using the document-internal skill to draft a doc for internal-docs."
+
+## When to use
+
+After finishing implementation on a feature branch, when the work is doc-worthy (a major feature, a new subsystem, a setup runbook for something internal, or a design decision that future engineers need to know).
+
+## Hard rules — never do these
+
+- NEVER `git add -A` or `git add .` inside the tmp clone of internal-docs. Always specific paths.
+- NEVER write outside the tmp clone (no spillover into the OSS repo's working tree).
+- NEVER fabricate filler content for empty template sections. Empty stays empty.
+- NEVER touch the OSS repo's `.gitmodules` or submodule pointer — the sync workflow handles that.
+- NEVER run this skill if `.internal-docs/` is missing. Stop with the init command.
+- NEVER push to `internal-docs/main` directly. Always a feature branch + PR.
+
+## Voice rules — enforced by Step 4
+
+The skill MUST follow these and refuse to draft otherwise. After generation, scan for violations and regenerate offending sentences (max 3 attempts).
+
+- Lead with the point. First sentence answers "what is this?"
+- Concrete nouns. Name files, functions, commands. Not "the system" or "the component".
+- Short sentences. Average <20 words. No deeply nested clauses.
+- Active voice. "X does Y" not "Y is done by X".
+- No em dashes. Use commas, periods, or rephrase.
+- Banned words: delve, crucial, robust, comprehensive, nuanced, multifaceted, furthermore, moreover, additionally, pivotal, landscape, tapestry, underscore, foster, showcase, intricate, vibrant, fundamental, significant, leverage, utilize.
+- "110 IQ" target. Write for a smart engineer who has not seen this code yet.
+- No filler intros ("This document describes..."). Start with the substance.
+- Empty sections stay empty. Do not write "N/A" or fabricate content.
+
+## Workflow
+
+### Step 0: Pre-flight
+
+Bail with a clear message on any failure.
+
+```bash
+# Submodule must be initialized
+if git submodule status .internal-docs 2>/dev/null | grep -q '^-'; then
+  echo "internal-docs submodule not initialized. Run: git submodule update --init .internal-docs"
+  exit 0
+fi
+[ -d .internal-docs ] || { echo ".internal-docs/ missing. Submodule not configured?"; exit 0; }
+
+# Must be on a feature branch
+BRANCH=$(git branch --show-current)
+if [ "$BRANCH" = "main" ] || [ "$BRANCH" = "dev" ]; then
+  echo "On $BRANCH. Run from a feature branch."
+  exit 0
+fi
+
+# Determine base branch (default: dev for this repo, fall back to main).
+# Suppress rev-parse's SHA output on stdout so it doesn't get captured into BASE.
+BASE=$(git rev-parse --verify origin/dev >/dev/null 2>&1 && echo dev || echo main)
+
+# Gather context
+git log "$BASE..HEAD" --oneline
+git diff "$BASE...HEAD" --stat
+gh pr view --json body -q .body 2>/dev/null  # may be empty if no PR yet
+```
+
+### Step 1: Identify the doc
+
+Ask the user for three things in one prompt:
+
+1. **Doc type:** `feature` (default for `feat/*` branches), `architecture`, or `design`
+2. **Slug:** kebab-case, short (e.g., `cowork-mcp`, `auto-skill-suggest`)
+3. **Owner:** GitHub handle (default = `git config user.name` or current `gh api user --jq .login`)
+
+### Step 2: Decision brief — four sharp questions
+
+Ask one question at a time. Each answer constrains the next. These force compression before drafting.
+
+1. "In one sentence: what can someone now DO that they could not before?"
+2. "What is the one design decision a future engineer needs to know?"
+3. "Which 3-5 files are the heart of this change?" (suggest candidates from the diff)
+4. "Any sharp edges or gotchas? (or 'none')"
+
+Skip any question that is N/A for the doc type. Architecture notes don't need question 1; design specs don't need question 4.
+
+### Step 3: Draft from the template
+
+Read the matching template from `.internal-docs/_templates/`:
+
+- `feature` → `feature-note.md`
+- `architecture` → `architecture-note.md`
+- `design` → `design-spec.md`
+
+If `.internal-docs/_templates/` does not exist (first run, before seeding), fall back to the seeds bundled with this skill at `.claude/skills/document-internal/seeds/_templates/`.
+
+Generate the 1-pager from the template, the four answers, and the diff context.
+
+### Step 4: Voice self-check
+
+Scan the draft for violations:
+
+- Em dash present (`—`).
+- Any banned word from the list.
+- Average sentence length > 20 words.
+- Body line count > 60 (feature notes only — architecture/design have no cap).
+
+If any violation found, regenerate the offending sentences in place. Max 3 attempts. If still failing after 3 attempts, stop and report which rules are violated.
+
+If the body is over 60 lines for a feature note, ask: "This is N lines, target is 60. Trim, or promote to `architecture/` (no length cap)?"
+
+### Step 5: Show + iterate
+
+Print the full draft. Ask:
+
+> Edit needed? Paste any changes, or say "looks good".
+
+Apply user edits with the Edit tool. Re-run Step 4. Loop until the user approves.
+
+### Step 6: Open PR to internal-docs
+
+Use a tmp clone. Never the user's `.internal-docs` checkout — keeps the user's submodule clean.
+
+```bash
+TMP=$(mktemp -d)
+trap 'rm -rf "$TMP"' EXIT  # cleans up even if any step below fails
+git clone -b main git@github.com:browseros-ai/internal-docs.git "$TMP"
+cd "$TMP"
+git checkout -b "docs/<slug>"
+
+# Write the doc
+mkdir -p "<type>"  # features, architecture, designs, or setup
+cat > "<type>/$(date -u +%Y-%m)-<slug>.md" <<'DOC'
+<draft content>
+DOC
+
+# Update the root README index — insert one line under the matching section
+# Use Edit tool to add: "- [<title>](<type>/YYYY-MM-<slug>.md) — <one-line description>"
+
+git add "<type>/$(date -u +%Y-%m)-<slug>.md" README.md
+git commit -m "docs(<type>): <slug>"
+git push -u origin "docs/<slug>"
+
+PR_URL=$(gh pr create -R browseros-ai/internal-docs --base main \
+  --head "docs/<slug>" \
+  --title "docs(<type>): <slug>" \
+  --body "$(cat <<'BODY'
+## Summary
+<one-line of what this doc covers>
+
+## Source
+- BrowserOS branch: <branch>
+- Related PR: <#NNN if any>
+BODY
+)")
+
+cd -
+echo "PR opened: $PR_URL"
+# trap above cleans up $TMP on EXIT
+```
+
+If the slug contains characters that won't shell-escape cleanly, sanitize before substitution.
+
+### Step 7: Completion status
+
+Report one of:
+
+- **DONE** — file written, branch pushed, PR opened. Print PR URL.
+- **DONE_WITH_CONCERNS** — same as DONE but list concerns (e.g., voice check needed multiple regens, user skipped a question).
+- **BLOCKED** — submodule missing, auth fail, or template missing. State exactly what's needed.
+
+## Doc type defaults
+
+| Branch pattern | Default doc type | Default location |
+|----------------|------------------|------------------|
+| `feat/*`       | feature          | `features/`      |
+| `arch/*` or refactor branches with >10 files in `packages/` | architecture | `architecture/` |
+| `rfc/*` or `design/*` | design          | `designs/`       |
+| Otherwise      | ask              | ask              |
+
+## Common Mistakes
+
+**Drafting before asking the four questions**
+- **Problem:** Output is generic filler that says nothing concrete.
+- **Fix:** Always ask Step 2 first, even if the diff "looks obvious".
+
+**Touching `.internal-docs/` directly**
+- **Problem:** User's submodule HEAD moves, parent repo shows dirty state.
+- **Fix:** Always use the tmp clone in Step 6.
+
+**Skipping voice check on user edits**
+- **Problem:** User pastes prose with em dashes or filler; ships as-is.
+- **Fix:** Re-run Step 4 after every user edit.
+
+## Red Flags
+
+**Never:**
+- Push to `internal-docs/main`. Always branch + PR.
+- Modify the OSS repo's `.gitmodules` or submodule pointer.
+- Fabricate content for empty template sections.
+
+**Always:**
+- Pre-flight check before doing any work.
+- One-pager rule for feature notes (60-line body cap).
+- File:line citations when referencing code.

.claude/skills/document-internal/seeds/README.md

@@ -0,0 +1,51 @@
+# BrowserOS Internal Docs
+
+Private team docs for `browseros-ai`. Mounted as a submodule into the public OSS repo at `.internal-docs/`.
+
+If you are reading this from a public clone of BrowserOS without team access — this submodule is for the BrowserOS internal team. Nothing here is required to build or use BrowserOS.
+
+## How to find what you need
+
+- Setup task ("how do I X locally") → look in [`setup/`](setup/)
+- Recently shipped feature → look in [`features/`](features/)
+- Cross-cutting subsystem → look in [`architecture/`](architecture/)
+- A design decision or RFC → look in [`designs/`](designs/)
+
+Or run `/ask-internal "<your question>"` from any BrowserOS checkout. The skill greps these docs and the codebase, then synthesizes an answer with citations.
+
+## How to add a doc
+
+Run `/document-internal` from a feature branch. The skill drafts a 1-pager from your branch's diff, asks four sharp questions, enforces voice rules, and opens a PR back to this repo.
+
+## Index
+
+### Setup
+<!-- one line per setup runbook: -->
+<!-- - [Dev environment](setup/dev-environment.md): first-time machine setup -->
+
+### Features
+<!-- one line per shipped feature, newest first: -->
+<!-- - [Cowork MCP](features/2026-04-cowork-mcp.md): bring outside MCPs into the BrowserOS agent -->
+
+### Architecture
+<!-- one line per cross-cutting subsystem: -->
+<!-- - [Chrome fork overview](architecture/chrome-fork-overview.md): what we patched and why -->
+
+### Designs
+<!-- one line per design spec, newest first: -->
+<!-- - [Internal docs submodule](designs/2026-04-30-internal-docs-submodule.md): this system -->
+
+## Templates
+
+When `/document-internal` runs, it reads from [`_templates/`](_templates/). Edit the templates here when the team's preferred shape changes.
+
+## Voice
+
+Docs in this repo follow these rules. The `/document-internal` skill enforces them; humans editing by hand should match.
+
+- Lead with the point.
+- Concrete nouns. Name files, functions, commands.
+- Short sentences, active voice, no em dashes.
+- No filler words: delve, crucial, robust, comprehensive, nuanced, multifaceted, leverage, utilize, etc.
+- Empty sections stay empty. Do not write "N/A" or fake content.
+- Feature notes target one screen, body 60 lines max.

.claude/skills/document-internal/seeds/_templates/architecture-note.md

@@ -0,0 +1,31 @@
+---
+title: <subsystem name>
+owner: <github handle>
+status: current | deprecated
+date: YYYY-MM-DD
+related-features: [feature-slug-1, feature-slug-2]
+---
+
+# <subsystem name>
+
+## What this subsystem does
+<1-2 paragraphs. The top-level responsibility. Boundaries.>
+
+## Architecture
+<Diagram (ASCII or mermaid) plus prose. Components and how they talk.>
+
+## Constraints
+<Hard rules the design enforces. "X must never call Y" type statements.>
+
+## Decisions made
+<Numbered list of non-obvious decisions and the reason for each.>
+
+## Key files
+- `path/to/file.ts` — role
+- `path/to/dir/` — what lives here
+
+## How to evolve this
+<Where to add things. Which tests to expect to update. What NOT to touch.>
+
+## Open questions
+<What is still being figured out. Empty if none.>

.claude/skills/document-internal/seeds/_templates/design-spec.md

@@ -0,0 +1,34 @@
+---
+title: <design name>
+owner: <github handle>
+status: proposed | accepted | rejected | superseded
+date: YYYY-MM-DD
+supersedes: <design-slug or none>
+---
+
+# <design name>
+
+## Goal
+<2-4 sentences. What this design is trying to accomplish.>
+
+## Context
+<1-2 paragraphs. The current state, what is failing, why this needs to change.>
+
+## Selected Approach
+<The chosen design at a high level. Architecture, components, data flow.>
+
+## Alternatives Considered
+### 1. <name>
+<2-3 sentences on what this would look like, then pro/con and why rejected (or deferred).>
+
+### 2. <name>
+<Same shape.>
+
+## Out of Scope
+<What this design does NOT cover. Defer references.>
+
+## Rollout
+<Numbered steps from "nothing exists" to "fully shipped".>
+
+## Open Questions
+<Resolved during design? Empty. Unresolved? List with owner.>

.claude/skills/document-internal/seeds/_templates/feature-note.md

@@ -0,0 +1,29 @@
+---
+title: <feature name>
+owner: <github handle>
+status: shipped | wip | deprecated
+date: YYYY-MM-DD
+prs: ["#NNN"]
+tags: [agent, browser, mcp]
+---
+
+# <feature name>
+
+## What it does
+<2-3 sentences. What can someone now do that they could not before. Lead with user-facing impact, not implementation.>
+
+## Why we built it
+<1-2 sentences. Motivation. What pain it removed or what unlocked.>
+
+## How it works
+<3-6 sentences. The flow at a high level. Name the key files.>
+
+## Key files
+- `path/to/file.ts` — what it does
+- `path/to/other.ts` — what it does
+
+## How to run / test it locally
+<bullet list of commands. Empty section if N/A — do not fake.>
+
+## Gotchas
+<known sharp edges. "If you see X, that's why." Empty if N/A.>

.github/workflows/sync-internal-docs.yml

@@ -0,0 +1,53 @@
+name: Sync internal-docs submodule
+
+on:
+  schedule:
+    - cron: '0 */4 * * *'
+  workflow_dispatch:
+
+jobs:
+  sync:
+    name: Bump internal-docs submodule pointer on dev
+    runs-on: ubuntu-latest
+    steps:
+      - name: Rewrite SSH submodule URL to HTTPS-with-token
+        env:
+          TOKEN: ${{ secrets.INTERNAL_DOCS_SYNC_TOKEN }}
+        run: |
+          git config --global "url.https://x-access-token:${TOKEN}@github.com/.insteadOf" "git@github.com:"
+
+      - uses: actions/checkout@v4
+        with:
+          token: ${{ secrets.INTERNAL_DOCS_SYNC_TOKEN }}
+          submodules: true
+          ref: dev
+          fetch-depth: 50
+
+      - name: Bump submodule pointer if internal-docs has new commits
+        env:
+          GH_TOKEN: ${{ secrets.INTERNAL_DOCS_SYNC_TOKEN }}
+        run: |
+          set -e
+
+          # Skip if submodule not yet configured (handoff window before someone adds it)
+          if ! git config --file .gitmodules --get-regexp '^submodule\..internal-docs\.path$' >/dev/null 2>&1; then
+            echo "internal-docs submodule not yet configured in .gitmodules. Skipping."
+            exit 0
+          fi
+
+          git submodule update --remote --merge .internal-docs
+
+          if git diff --quiet .internal-docs; then
+            echo "No internal-docs changes to sync."
+            exit 0
+          fi
+
+          git config user.name  "browseros-bot"
+          git config user.email "bot@browseros.ai"
+          git add .internal-docs
+          git commit -m "chore: sync internal-docs submodule"
+
+          # Rebase onto latest dev to absorb any commits that landed during the run,
+          # then push. set -e takes care of failing the run on rebase conflict.
+          git pull --rebase origin dev
+          git push origin dev