@vpxa/aikit 0.1.141 → 0.1.142

package/scaffold/dist/definitions/skills/multi-agents-development.mjs

@@ -83,14 +83,14 @@ You are performing an architecture review. Focus on structural decisions, not co
 
 Use this template when dispatching **Code-Reviewer-Alpha** and **Code-Reviewer-Beta** for dual code quality review. Both reviewers get the same prompt — different models catch different issues.
 
-This review runs AFTER spec compliance passes.
+This review runs as part of the code review stage. Reviewers gather evidence first; the FORGE gate runs only after code review and any conditional reviews complete.
 
 ---
 
 ## Prompt Template
 
 \`\`\`markdown
-You are performing a code quality review. The code has already passed spec compliance — it does what was asked. Your job is to evaluate HOW it does it.
+You are performing a code review. Your job is to evaluate HOW the implementation works while cross-checking that it still matches what was requested.
 
 ## Task Context
 [Brief description of what was implemented and why]
@@ -165,7 +165,8 @@ You are performing a code quality review. The code has already passed spec compl
 
 ## Usage Notes
 
-- Both Alpha and Beta reviewers get this same template — multi-model cross-validation
+- Run this during the code review stage, before any architecture/security review and before the FORGE gate
+- Both Alpha and Beta reviewers can use this template for multi-model cross-validation, or one reviewer can use the spec-alignment-focused template below
 - Combine findings from both reviewers before deciding on action
 - **Blocker** findings = REQUEST_CHANGES (must fix)
 - **Major** findings = usually REQUEST_CHANGES unless truly optional
@@ -397,29 +398,21 @@ STATUS PROTOCOL: DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED
 
 ## Step 5: Review Pipeline
 
-Both agents return DONE. Orchestrator runs review:
+Both agents return DONE. Orchestrator runs the ordered review cycle:
 
-1. **Spec Review** (Code-Reviewer-Alpha as spec reviewer):
-   - Backend: PASS — all acceptance criteria met
-   - Frontend: PASS_WITH_NOTES — missing keyboard accessibility on toggles
+1. **Code Review** (Alpha + Beta in parallel):
+  - Alpha: PASS_WITH_NOTES — acceptance criteria met; add keyboard accessibility on toggles
+  - Beta: APPROVE_WITH_SUGGESTIONS — extract validation schema to shared file
 
-2. **Code Quality Review** (Alpha + Beta in parallel):
-   - Alpha: APPROVE_WITH_SUGGESTIONS — extract validation schema to shared file
-   - Beta: APPROVE — clean implementation
+2. **Architecture Review** (not triggered — no boundary changes)
 
-3. **Architecture Review** (not triggered — no boundary changes)
+3. **Security Review** (not triggered — no auth, crypto, or risky input handling)
 
-4. **FORGE Gate**: \`evidence_map({ action: "gate" })\` → YIELD (all evidence collected)
+4. **FORGE Gate**: \`evidence_map({ action: "gate" })\` → YIELD (all review evidence collected)
 
-## Step 6: Commit
+## Step 6: Present Results
 
-\`\`\`
-feat: add notification preferences page
-
-- Backend: CRUD API for notification preferences per category
-- Frontend: Settings page with toggle grid, auto-save
-- Migration: notification_preferences table
-\`\`\`
+Stop here and present the review findings and gate result before any commit or merge action.
 
 ---
 
@@ -428,7 +421,7 @@ feat: add notification preferences page
 1. **Define shared contracts FIRST** — paste into all agent prompts
 2. **Independence check takes 30 seconds** — prevents hours of merge conflicts
 3. **Each agent gets ONLY its files** — focused context = better output
-4. **Review is sequential** — spec first, then quality, then architecture (conditional)
+4. **Review happens before the gate** — code review first, then architecture/security (conditional), then FORGE
 5. **FORGE gates at the end** — not between every step
 `},{file:`SKILL.md`,content:`---
 name: multi-agents-development
@@ -701,9 +694,9 @@ Every implementer (Implementer, Frontend, Refactor) MUST end their response with
 
 | Status | Meaning | Orchestrator Action |
 |--------|---------|-------------------|
-| **DONE** | All tasks complete, self-review passed | → Automated gate → Review pipeline |
-| **DONE_WITH_CONCERNS** | Complete but flagging issues: [list] | → Surface concerns as \`Assumed\` claims in evidence_map → Likely HOLD → Address before review |
-| **NEEDS_CONTEXT** | Cannot proceed without: [specific question] | → Provide missing context → Re-dispatch same task (counts as retry) |
+| **DONE** | All tasks complete, self-review passed | → Code review → Conditional architecture/security review → \`evidence_map\` gate → Present results |
+| **DONE_WITH_CONCERNS** | Complete but flagging issues: [list] | → Surface concerns in review and as \`Assumed\` claims in \`evidence_map\` → Likely HOLD at gate |
+| **NEEDS_CONTEXT** | Cannot proceed without: [specific question] | → Provide missing context → Re-dispatch same task (counts toward **Max 2 retries** per task) |
 | **BLOCKED** | Hit a wall: [description] | → Diagnose (see below) |
 
 ### BLOCKED Diagnosis Tree
@@ -735,48 +728,46 @@ Status protocol and FORGE are **independent but composable**:
 - **FORGE** = objective quality evidence ("the evidence says it's done")
 
 \`\`\`
-DONE              → proceed to automated gate → FORGE evidence_map
-DONE_WITH_CONCERNS → concerns become 'Assumed' claims → evidence_map likely HOLDs
-NEEDS_CONTEXT     → provide context, re-dispatch (no FORGE yet)
-BLOCKED           → diagnose:
-                     contract/security issue → HARD_BLOCK
-                     resource/scope issue → re-plan, no FORGE
+DONE               → proceed to code review → conditional architecture/security review → FORGE evidence_map → present results
+DONE_WITH_CONCERNS → concerns become 'Assumed' claims → reviewers validate them → evidence_map likely HOLDs
+NEEDS_CONTEXT      → provide context, re-dispatch (no FORGE yet)
+BLOCKED            → diagnose:
+                      contract/security issue → HARD_BLOCK
+                      resource/scope issue → re-plan, no FORGE
 \`\`\`
 
-**Critical rule**: Every \`DONE\` status MUST be followed by \`evidence_map({ action: "gate" })\` before proceeding to review. No shortcuts.
+**Critical rule**: Every \`DONE\` status MUST complete code review and any conditional architecture/security review BEFORE \`evidence_map({ action: "gate" })\`. No shortcuts.
 
 ---
 
 ## §8 Review Pipeline
 
-### Four-Stage Pipeline
+### Ordered Review Pipeline
 
 \`\`\`
 Stage 1: Implementer Self-Review (embedded in agent output)
   └─ Checklist: scope respected, tests pass, conventions followed
       │
-Stage 2: Orchestrator Automated Gate
-  └─ check({}) + test_run({}) MUST pass
-  └─ Validate self-review checklist present in output
-  └─ FAIL → bounce back to implementer with specific gap
-  └─ PASS ↓
-      │
-Stage 3: Dual Code Review (parallel)
+Stage 2: Dual Code Review (parallel)
   ├─ Code-Reviewer-Alpha (GPT-5.4): code quality + Spec Alignment
   └─ Code-Reviewer-Beta (Opus 4.6): code quality + Spec Alignment
       │ Both review same code, different model perspectives
       │ Spec Alignment = "Does this match what was asked?"
       │
-Stage 4: Conditional Reviews (parallel if both needed)
-  ├─ Architecture Review — if boundary changes, new modules, pattern shifts
-  └─ Security Review — if auth, crypto, input handling, or external data
+Stage 3: Architecture Review (conditional)
+  └─ Trigger only for boundary changes, new modules, or pattern shifts
+      │
+Stage 4: Security Review (conditional)
+  └─ Trigger for auth, crypto, input handling, or external data
       │
-FORGE Gate: evidence_map({ action: "gate" })
-  └─ YIELD → proceed to commit
-  └─ HOLD → address flagged items → re-gate (max 3 rounds)
+Stage 5: FORGE Gate — evidence_map({ action: "gate" })
+  └─ YIELD → stop and present results
+  └─ HOLD → address flagged items → re-gate (**Max 2 retries** per task)
   └─ HARD_BLOCK → escalate to user
 \`\`\`
 
+Use \`check({})\` + \`test_run({})\` to gather evidence for reviewers, but they are not the gate.
+
 ### Spec Alignment Dimension (for Code Reviewers)
 
 Both Code-Reviewer-Alpha and Code-Reviewer-Beta evaluate an explicit **Spec Alignment** dimension:
@@ -802,7 +793,7 @@ This catches spec drift that automated tests might miss.
 
 ### Retry Policy
 
-- **Max 2 retries per agent per task** — after that, re-plan or escalate
+- **Max 2 retries** per task — after that, re-plan or escalate
 - Each retry MUST include the specific failure reason in the new prompt
 - Never retry with the same prompt — always add diagnostic context
 
@@ -852,7 +843,7 @@ DOCUMENT → remember what went wrong, update plan
 | **Skipping reviews** — "it's a small change" | Small changes cause big regressions | ALWAYS run automated gate minimum |
 | **Parallel on shared files** — "both agents edit config.ts" | Merge conflicts, lost changes | Sequential, or merge into one task |
 | **Trusting the report** — "agent said DONE so it's done" | Agents are optimistic, miss edge cases | Automated gate + dual code review catches this |
-| **Brute-force retries** — same prompt 3 times | If it failed twice, it'll fail a third time | Diagnose, change approach, then retry |
+| **Brute-force retries** — same prompt beyond **Max 2 retries** per task | Repeating without diagnosis will not change the outcome | Diagnose, change approach, then retry within the limit |
 | **Orchestrator implements** — "just this one small fix" | Breaks the delegation contract, no review | ALWAYS delegate, no matter how small |
 
 ### Red Flags in Agent Output
@@ -957,13 +948,13 @@ Detailed prompt templates are provided as sidecar files:
 | Template | File | Use When |
 |----------|------|----------|
 | Implementer dispatch | [\`implementer-prompt.md\`](implementer-prompt.md) | Dispatching Implementer, Frontend, or Refactor agents |
-| Spec compliance review | [\`spec-review-prompt.md\`](spec-review-prompt.md) | Adversarial spec alignment check (Code-Reviewer-Alpha) |
-| Code quality review | [\`code-quality-review-prompt.md\`](code-quality-review-prompt.md) | Dual code quality review (Code-Reviewer-Beta) |
+| Code review (spec alignment focus) | [\`spec-review-prompt.md\`](spec-review-prompt.md) | Bias one code reviewer toward acceptance criteria, scope, and contract alignment |
+| Code review (quality focus) | [\`code-quality-review-prompt.md\`](code-quality-review-prompt.md) | Bias one or both code reviewers toward maintainability, quality, and security within the same review stage |
 | Architecture review | [\`architecture-review-prompt.md\`](architecture-review-prompt.md) | Boundary changes, pattern adherence review |
 | Parallel dispatch example | [\`parallel-dispatch-example.md\`](parallel-dispatch-example.md) | Worked example of decomposing a feature into parallel tasks |
-`},{file:`spec-review-prompt.md`,content:`# Spec Compliance Review Prompt Template
+`},{file:`spec-review-prompt.md`,content:`# Spec Alignment Review Prompt Template
 
-Use this template when dispatching **Code-Reviewer-Alpha** for adversarial spec compliance review. This review runs BEFORE code quality review.
+Use this template when dispatching a code reviewer who should emphasize spec alignment during the code review stage. This runs as part of code review, not before a separate gate.
 
 **Mindset: "Don't trust the report."** The implementer says it's done — verify independently.
 
@@ -972,7 +963,7 @@ Use this template when dispatching **Code-Reviewer-Alpha** for adversarial spec
 ## Prompt Template
 
 \`\`\`markdown
-You are performing an adversarial spec compliance review. Your job is to verify that the implementation matches what was requested — nothing more, nothing less.
+You are performing an adversarial spec alignment review. Your job is to verify that the implementation matches what was requested — nothing more, nothing less.
 
 **Do NOT trust the implementer's self-assessment.** Verify independently.
 
@@ -1038,8 +1029,8 @@ For EACH acceptance criterion in the task spec:
 
 ## Usage Notes
 
-- Run this BEFORE code quality review — no point reviewing quality if spec is wrong
+- Run this during the code review stage — gather this evidence before any conditional architecture/security review and before the FORGE gate
 - Paste the ORIGINAL task spec, not a summary — the reviewer needs exact acceptance criteria
-- If verdict is FAIL, bounce back to implementer with specific gaps before proceeding
-- PASS_WITH_NOTES can proceed to code quality review, but notes should be tracked
+- If verdict is FAIL, bounce back to implementer with specific gaps before moving to later reviews or the gate
+- PASS_WITH_NOTES can proceed to the remaining reviews, but notes should be tracked
 `}];export{e as default};

package/scaffold/dist/definitions/skills/present.mjs

@@ -41,17 +41,17 @@ When using \`format: "browser"\`, the tool starts a local HTTP server and return
 ### Steps:
 1. Call \`present\` with \`format: "browser"\` and \`actions\` — it returns text containing \`🌐 **Dashboard opened in browser:** http://127.0.0.1:{port}\`
 2. **Extract the URL from the response**
-3. **Call \`openBrowserPage({ url: "http://127.0.0.1:{port}" })\` - Playwright MCP to open it in the integrated browser**
+3. **Call \`browser({ action: 'open', url: 'http://127.0.0.1:{port}', mode: 'ui' })\` - AI Kit browser tool to open it in the integrated browser**
 
 \`\`\`
 // Step 1: Call present
 result = present({ format: "browser", title: "...", content: [...], actions: [...] })
 
 // Step 2: MUST open in integrated browser
-openBrowserPage({ url: "http://127.0.0.1:{port}" }) // Playwright MCP - opens URL in the integrated browser
+browser({ action: 'open', url: 'http://127.0.0.1:{port}', mode: 'ui' }) // AI Kit browser tool - opens URL in the integrated browser
 \`\`\`
 
-> **Fallback**: The server also auto-opens the system browser as a safety net. But you should ALWAYS call \`openBrowserPage\` via Playwright MCP yourself so the user sees it in their environment.
+> **Fallback**: The server also auto-opens the system browser as a safety net. But you should ALWAYS call \`browser({ action: 'open' })\` via the AI Kit browser tool yourself so the user sees it in their environment.
 
 **Note:** The HTTP server auto-closes after 5 minutes. Open the page promptly after receiving the URL.
 
@@ -97,7 +97,7 @@ Compose a full dashboard by combining multiple blocks in the \`content\` array:
     { "type": "timeline", "title": "Milestones", "value": { "items": [...] } },
     { "type": "status-board", "title": "Service Health", "value": { "items": [...] } },
     { "type": "table", "title": "Tasks", "value": [...] },
-    { "type": "markdown", "value": "## Notes\\n\\nAdditional context..." }
+    { "type": "markdown", "value": "## Notes\n\nAdditional context..." }
   ],
   "actions": [
     { "type": "button", "id": "next-sprint", "label": "Plan Next Sprint", "variant": "primary" }

package/scaffold/dist/definitions/skills/repo-access.mjs

@@ -1 +1,198 @@
-var e=[{file:`references/error-patterns.md`,content:'# Repo Access Error Patterns\n\nUse this reference to distinguish missing repositories from authentication and policy failures when probing Git hosts.\n\n## HTTP Status Code Matrix\n\n| Platform | No auth (private repo) | Wrong credentials | Rate limited | SSO required |\n|---|---|---|---|---|\n| GitHub REST API | `404` (TRAP!) | `401` -> `403` | `403` + rate limit body | `403` + `X-GitHub-SSO` header |\n| GitHub Web | HTML "Page not found" or login redirect | Login redirect | - | - |\n| GitLab | `401` | `401` | `429` | `401` (PAT mandatory) |\n| Bitbucket | `403` | `403` | `429` | `403` |\n| Azure DevOps | `401` | `401` | - | `401` |\n\n## CRITICAL: The GitHub 404 Trap\n\nGitHub deliberately returns `404`, not `401`, for private repositories accessed without authentication.\nThis is by design to avoid leaking whether a repository exists.\n\n- Never conclude a GitHub repository does not exist from an unauthenticated `404`.\n- `GET https://api.github.com/repos/{owner}/{repo}` without auth returns `404` for both "repo truly missing" and "repo exists but is private".\n- The only reliable disambiguation is an authenticated probe.\n- If the same request still returns `404` with valid auth, the repository is truly missing.\n\nProbe order:\n\n1. Try the authenticated API request first.\n2. If it returns `200`, access works.\n3. If it returns `404` without auth context, treat it as ambiguous and recover.\n4. If it returns `404` with known-good auth, treat the repo as missing.\n\n## Git CLI Stderr Patterns\n\n| Error Text Pattern | Platform | Diagnosis | Action |\n|---|---|---|---|\n| `remote: Repository not found.` | GitHub | Auth failure, not proof the repo is missing | Try auth strategies |\n| `git@github.com: Permission denied (publickey).` | GitHub | SSH key not recognized | Check SSH keys, try HTTPS |\n| `remote: HTTP Basic: Access denied.` | GitLab | Auth failure, 2FA likely | Use PAT; password auth is blocked with 2FA |\n| `error: The requested URL returned error: 403` | Bitbucket | Auth failure | Try app password |\n| `TF401019: The Git repository with name or identifier X does not exist` | Azure DevOps | Auth failure or missing repo | Try PAT with Code:Read scope |\n| `fatal: Authentication failed for \'https://...\'` | Any (HTTPS) | General auth failure | Escalate through the strategy ladder |\n| `Permission denied (publickey).` | Any (SSH) | SSH key not recognized | Check `~/.ssh/`, run `ssh-add`, try HTTPS |\n| `fatal: Could not read from remote repository.` | Any (SSH) | SSH access denied | Verify the SSH key is added to the platform |\n| `unable to access \'...\': SSL certificate problem` | Any | Self-signed or enterprise CA issue | Ask about local cert config; skip to local clone if needed |\n\nTreat these stderr strings as direct signals from tool output. Do not reinterpret GitHub\'s `Repository not found` as a clean existence check.\n\n## web_fetch / http Tool Detection\n\n- `web_fetch` against a private GitHub repo URL often returns HTML with "Page not found" or a login page.\n- GitHub web responses can be `200` with a 404-looking body, so `web_fetch` is unreliable for auth diagnosis.\n- `http` against the platform API gives machine-readable bodies and real status codes, so use it for probes.\n- For `web_fetch` on `github.com`, inspect the body for `Page not found`, `Sign in`, or `/login` links. If present, assume private or auth-gated access and trigger recovery.\n\nRecommended diagnostic probe:\n\n```text\nhttp GET https://api.github.com/repos/{owner}/{repo}\n-> 404 + no auth header -> might be private\n-> 401 -> explicit auth failure\n-> 200 -> repo is public, access works\n```\n\n## Edge Cases\n\n| Edge Case | Signal | Response |\n|---|---|---|\n| GitHub.com SAML SSO | `403` + `X-GitHub-SSO: required; url=...` | PAT needs SSO authorization for the org |\n| GHE SAML SSO (web_fetch) | `200` + body contains `Initiating SAML single sign-on`, redirect to `login.microsoftonline.com` or other IdP | Repo EXISTS and is auth-gated. NOT inaccessible. Use PAT + `http` with auth headers, or `gh auth login --hostname <host>` |\n| GHE SAML SSO (http) | `302` redirect to `/login?return_to=...` or IdP URL | Same — repo exists, needs auth. Walk the Strategy Ladder |\n| GHE SAML SSO (git CLI) | `fatal: Authentication failed` or credential prompt | `gh auth login --hostname <host>` or PAT via credential helper |\n\n## SAML SSO — Detailed Pattern\n\nGitHub Enterprise instances commonly use SAML SSO via Azure AD (Entra ID), Okta, or other IdPs. When `web_fetch` hits a GHE URL without auth:\n\n1. GHE returns `200 OK` (not 401/403!) with an HTML page\n2. The HTML contains `Initiating SAML single sign-on` and a redirect URL to the IdP\n3. The redirect URL includes `SAMLRequest=`, `RelayState=`, and often `login.microsoftonline.com`\n4. The agent sees HTML content and may conclude the repo is "inaccessible" or "behind SSO"\n\n**Detection strings** (check `web_fetch` output for ANY of these):\n```\nInitiating SAML single sign-on\nlogin.microsoftonline.com\nYou are being redirected to your identity provider\n/login?return_to=\nSAMLRequest=\nRelayState=\n```\n\n**Correct response:** The repo exists. The `web_fetch` path will never work for SSO-protected GHE. Switch to:\n- `gh auth login --hostname <ghe-host>` (if `gh` CLI available)\n- PAT + `http` with `Authorization: token <PAT>` against `<ghe-host>/api/v3/repos/{owner}/{repo}/contents/{path}`\n- Ask user for local clone if no token can be obtained\n| GitLab 2FA enabled | `401` on password auth | PAT is mandatory; 2FA blocks password auth |\n| Expired token | `401` after providing a valid-looking PAT | Generate a new token and check expiry |\n| GitHub rate limit | `403` + body contains `rate limit` | Not an auth failure; wait or authenticate for a higher limit |\n| IP allowlisting | `403` + body mentions IP or org policies | Cannot be fixed programmatically; skip to local clone (Step 5) |\n| Fine-grained PAT scope | `403` + `insufficient scope` | Switch to a classic PAT for org repos |\n| SSH key not in agent | `Permission denied (publickey)` + key file exists | Run `ssh-add ~/.ssh/id_ed25519` |\n| Wrong SSH username | `Permission denied` | Use `git@host`, not `username@host` |\n| Deploy key conflict | `key is already in use` | Use a user SSH key or PAT instead |\n\n## Escalation Decision Rules\n\n- Retry the same step for transient failures such as DNS failure, timeout, or `5xx` responses.\n- Escalate to the next strategy step for `401`, `403`, `404`, `Permission denied`, `Authentication failed`, or `Access denied`.\n- Skip directly to Step 5 (local clone) for IP allowlisting, enterprise SSL certificate issues, or org policy blocks.\n\nDefault interpretation order:\n\n1. Prefer API probes over web page fetches.\n2. Treat GitHub `404` as ambiguous until valid auth disproves privacy.\n3. Treat SSH `publickey` errors as key-distribution failures, not repo absence.\n4. Separate rate limits and org policy blocks from authentication failures before escalating.'},{file:`references/platform-matrix.md`,content:"# Platform Matrix\n\nUse this reference when a repository URL reveals the hosting platform and the skill needs platform-specific authentication or cloning guidance. Prefer platform CLI login flows or OS-backed credential helpers over raw PAT handling.\n\n## Platform Detection\n\n| URL Pattern | Platform | CLI Tool (optional) | Auth Command | No-CLI Alternative |\n|---|---|---|---|---|\n| `github.com` | GitHub | `gh` | `gh auth login` | PAT + `http` with `Authorization: token <PAT>` |\n| Any custom domain (e.g. `ghe.corp.com`, `github.corp.com`) | GitHub Enterprise | `gh` | `gh auth login --hostname <host>` | PAT + `http` against `<host>/api/v3` |\n| `gitlab.com` | GitLab | `glab` | `glab auth login` | PAT + `http` with `PRIVATE-TOKEN` header |\n| Self-hosted GitLab | GitLab Self-Managed | `glab` | `glab auth login --hostname <host>` | PAT + `http` with `PRIVATE-TOKEN` header |\n| `bitbucket.org` | Bitbucket Cloud | None | N/A | App password + `http` with `Authorization: Bearer` |\n| `dev.azure.com` or `*.visualstudio.com` | Azure DevOps | `az` + GCM | `az login` | PAT + `http` with Basic auth |\n| Gitea instances | Gitea | `tea` (optional) | `tea login add` | PAT + `http` with `Authorization: token` |\n| Unknown or custom domain | Ask user which platform | N/A | N/A | Probe `http` or ask before assuming generic Git |\n\n> **Note:** Platform CLIs (`gh`, `glab`, `az`, `tea`) are native binaries, not npm packages. Do NOT use `npx` to install them — it will fail or install unrelated/unofficial packages. When the CLI is unavailable, use the No-CLI Alternative column.\n\n## GitHub / GitHub Enterprise\n\n- CLI: `gh auth login` uses a browser or device code flow and can open the browser automatically.\n- GitHub Enterprise CLI: `gh auth login --hostname <host>`.\n- PAT creation: `https://github.com/settings/tokens` for classic tokens.\n- PAT creation: `https://github.com/settings/personal-access-tokens` for fine-grained tokens.\n- Minimum scopes: `repo` for classic PATs (NOTE: `repo` grants read and write — prefer fine-grained PATs with `Contents: Read` for read-only access).\n- Minimum scopes: `Contents: Read` for fine-grained PATs.\n- SSH: `git@github.com:owner/repo.git`.\n- Credential helper: `gh auth setup-git` configures Git to use the GitHub credential flow.\n- Note: Fine-grained PATs may not cover organization-level access or every repo path; classic PATs are still required for some org repos.\n- SAML SSO: PATs often require explicit org authorization from `https://github.com/settings/tokens` after creation.\n- Enterprise note: PAT URLs and token policy can vary by host; reuse the same auth pattern with the enterprise hostname and instance settings pages.\n- Enterprise detection: GHE instances use fully custom domains (e.g. `ghe.coxautoinc.com`, `github.acme.com`). If unsure, probe `https://<host>/api/v3` — a GitHub Enterprise instance returns a JSON response with `installed_version`. Use `gh auth login --hostname <host>` with any custom GHE domain.\n\n## GitLab / GitLab Self-Managed\n\n- CLI: `glab auth login` uses a browser-backed OAuth flow.\n- Self-managed CLI: `glab auth login --hostname <host>`.\n- PAT creation: `https://gitlab.com/-/user_settings/personal_access_tokens`.\n- Minimum scopes: `read_repository`.\n- SSH: `git@gitlab.com:owner/repo.git`.\n- Credential helper: `glab auth setup-git` configures Git credential handling.\n- Note: If 2FA is enabled, username/password Git auth is blocked; a PAT is mandatory for HTTPS auth.\n- Self-managed note: PAT URL is typically `https://<host>/-/user_settings/personal_access_tokens` unless the instance customizes settings paths.\n\n## Bitbucket Cloud\n\n- CLI: No official first-party CLI OAuth flow for repo auth.\n- PAT/App Password creation: `https://bitbucket.org/{workspace}/settings/app-passwords`.\n- Minimum permissions: `Repositories: Read`.\n- SSH: `git@bitbucket.org:owner/repo.git`.\n- Note: Bitbucket Cloud uses App Passwords rather than standard PAT terminology.\n- Note: HTTPS auth requires both the Bitbucket username and the app password, delivered through a credential helper or `GIT_ASKPASS` script — never embedded in the clone URL.\n\n## Azure DevOps\n\n- CLI: `az login` authenticates to Microsoft Entra ID; Git Credential Manager then handles Git credentials automatically.\n- PAT-based auth remains the fallback when Entra ID or GCM is unavailable.\n- PAT creation: `https://dev.azure.com/{org}/_usersSettings/tokens`.\n- Minimum scopes: `Code: Read`.\n- SSH: `git@ssh.dev.azure.com:v3/{org}/{project}/{repo}`.\n- Note: Microsoft Entra ID tokens are generally preferred over PATs in enterprise environments.\n- Credential helper: Git Credential Manager via `git-credential-manager configure`.\n- Legacy host note: Azure DevOps may also appear under `*.visualstudio.com` URLs.\n\n## Gitea / Forgejo\n\n- CLI: `tea login add` is available but optional and not universally installed.\n- PAT creation: `https://{host}/user/settings/applications`.\n- Minimum scopes: `repo`.\n- SSH: `git@{host}:owner/repo.git`.\n- Note: Forgejo commonly mirrors the same applications-token path and PAT model as Gitea.\n- Note: Some self-hosted instances rename scopes or disable API token creation, so confirm the instance policy if `repo` is rejected.\n\n## Generic Git (Self-Hosted)\n\n- Platform CLI: None assumed.\n- Auth path: Prefer SSH keys first, then PAT if the host documents HTTPS token auth.\n- PAT creation: Ask the user for the platform's PAT or application-token settings URL.\n- SSH: Use the host's documented SSH remote format; do not assume GitHub-style shortcuts if the server advertises a different pattern.\n\n## API File-Read Endpoints (for web-based code access)\n\nWhen agents need to read individual files without cloning, use these authenticated API endpoints.\n\n### GitHub / GitHub Enterprise\n\n```text\n# Read file contents (returns JSON with base64 content)\nGET https://api.github.com/repos/{owner}/{repo}/contents/{path}?ref={branch}\nAuthorization: token <PAT>\n\n# GHE: replace api.github.com with <ghe-host>/api/v3\nGET https://<ghe-host>/api/v3/repos/{owner}/{repo}/contents/{path}?ref={branch}\n\n# Or use gh CLI (auto-authenticated):\ngh api repos/{owner}/{repo}/contents/{path}?ref={branch} --jq '.content' | base64 -d\n```\n\n### GitLab / GitLab Self-Managed\n\n```text\n# URL-encode the file path (/ becomes %2F)\nGET https://gitlab.com/api/v4/projects/{project-id}/repository/files/{url-encoded-path}/raw?ref={branch}\nPRIVATE-TOKEN: <PAT>\n\n# Or use project path instead of ID:\nGET https://gitlab.com/api/v4/projects/{url-encoded-namespace%2Fproject}/repository/files/{url-encoded-path}/raw?ref={branch}\n```\n\n### Azure DevOps\n\n```text\nGET https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path={path}&api-version=7.0\nAuthorization: Basic {base64(:PAT)}\n```\n\n### Bitbucket Cloud\n\n```text\nGET https://api.bitbucket.org/2.0/repositories/{workspace}/{repo}/src/{commit-or-branch}/{path}\nAuthorization: Bearer <app-password-or-token>\n```\n- Note: Self-hosted products often customize auth policy, token names, and minimum scopes.\n\n## Safe Credential Delivery Patterns\n\n| Method | Command | Safety |\n|---|---|---|\n| Platform CLI | `gh auth login` / `glab auth login` | Best — handles credential storage |\n| Git Credential Manager | `git credential-manager configure` | Good — OS keychain storage |\n| Environment variable | `GH_TOKEN=xxx gh repo clone ...` | OK — ephemeral; safer than URL tokens but visible to same-user processes |\n| Git askpass | `GIT_ASKPASS=script git clone ...` | OK — no shell history exposure |\n| Inline in URL | `git clone https://token@host/...` | FORBIDDEN — leaks in history/logs |\n\n## Operational Notes\n\n- Prefer SSH when the user already has working keys and the host advertises a stable SSH remote format.\n- Prefer platform CLI login for GitHub and GitLab because it also wires Git credential storage.\n- Prefer Git Credential Manager for Azure DevOps and other HTTPS-heavy enterprise setups.\n- When recommending PAT creation, always suggest setting a short expiry (7-30 days for task-specific work). Prefer fine-grained or short-lived tokens.\n- Never recommend pasting tokens inline into clone URLs, scripts checked into the repo, or long-lived shell profiles."},{file:`SKILL.md`,content:'---\nname: repo-access\ndescription: "Progressive repository access recovery for private and enterprise git repositories. Triggered when: (1) git clone/fetch/pull fails with auth errors (401, 403, 404, Permission denied), (2) web_fetch or http tool returns auth failure on repository URLs, (3) user mentions private repo, enterprise repo, or internal repo, (4) user asks to access code from GitHub Enterprise, GitLab Self-Managed, Bitbucket Server, Azure DevOps. Guides through 6-step progressive strategy: anonymous HTTPS, SSH keys, CLI OAuth, PAT, local clone fallback, browser-based auth recovery (via browser-use skill)."\nmetadata:\n  category: cross-cutting\n  domain: general\n  applicability: on-demand\n  inputs: [git-error, repository-url, platform-context]\n  outputs: [authenticated-access, recovery-instructions]\n  requires: []\n  relatedSkills: [aikit]\nargument-hint: "Repository URL or error message"\n---\n\n# Repository Access Recovery\n\nProgressively recover repository access for private, enterprise, and internal git hosts without leaking credentials.\n\n## When to Activate\n\n### Reactive triggers\n\n- `git clone`, `git fetch`, or `git pull` fails with `401`, `403`, `404`, `Authentication failed`, or `Permission denied (publickey)`.\n- `http` diagnostics against a repo endpoint show auth failure or ambiguous private-repo responses.\n- `web_fetch` returns login page HTML, SSO redirect, "Sign in", "Page not found", or empty/truncated content for a repo URL.\n- Any tool output contains "behind SSO", "SSO required", "SAML", "requires authentication", or similar auth-gate language about a repository.\n- A repository URL works in a browser for the user but fails from agent tools or terminal commands.\n- **You are about to declare a repo "inaccessible" or "unreachable"** — STOP and activate this skill first.\n\n### Proactive triggers\n\n- The user says the repo is private, enterprise, self-managed, internal, or SSO-protected.\n- The repo is hosted on GitHub Enterprise, GitLab Self-Managed, Bitbucket Server/Data Center, Azure DevOps, Gitea, or another custom git host.\n- The environment may need browser sign-in, SSH agent setup, or token-based recovery before any code access can work.\n\n## When NOT to Activate\n\n- Public repositories that already clone or read successfully over HTTPS.\n- Local-only repositories where no remote auth is involved.\n- Problems caused by branch protection, merge conflicts, or rate limiting rather than repository access.\n\n## Step 0: Platform Detection & Capability Gate\n\nDetect platform from the URL, then decide what recovery options are possible in this environment.\n\n| URL pattern | Platform |\n| --- | --- |\n| `github.com`, or any GHE host (e.g. `ghe.*`, `github.*`, custom domain) | GitHub / GitHub Enterprise |\n| `gitlab.com`, `gitlab.<corp-host>` | GitLab / GitLab Self-Managed |\n| `bitbucket.org`, `bitbucket.<corp-host>` | Bitbucket Cloud / Server |\n| `dev.azure.com`, `visualstudio.com`, `/_git/` | Azure DevOps |\n| anything else with git over HTTPS/SSH | Unknown — ask the user which platform before assuming generic Git |\n\n- Capability gate: has terminal, has browser, or conversation-only.\n- If terminal is unavailable, skip directly to PAT guidance or local clone fallback.\n- If browser is unavailable, prefer SSH or pre-created credentials over CLI OAuth.\n- If only the `http` tool is available (no terminal, no CLI): use PAT + authenticated API reads (see "Web-Based Code Access" below). This is the zero-dependency path — no `gh`, `glab`, or `az` installation needed.\n\nFor platform-specific details, read `references/platform-matrix.md`.\n\n## Strategy Ladder\n\n### Step 1: Try HTTPS Anonymous Access\n\n- Goal: prove the repo is public or already reachable without extra auth.\n- What to do: normalize the remote to an HTTPS URL and run `git ls-remote https://...`. If it succeeds, use HTTPS and stop. If it fails with auth-like errors, continue instead of assuming the repo is missing.\n- Verify: `git ls-remote <url>`; SUCCESS -> stop, FAIL -> Step 2.\n\n### Step 2: Check Existing SSH Keys\n\n- Goal: reuse working SSH credentials before asking for new secrets.\n- What to do: inspect `~/.ssh/` for key files, run `ssh-add -l`, then test host auth with `ssh -T git@{host}`. If SSH works, switch the remote to the SSH URL and continue with that transport.\n- Verify: `git ls-remote <ssh-url>`; SUCCESS -> stop, FAIL -> Step 3.\n\n### Step 3: Platform CLI OAuth\n\n- Goal: use the platform\'s interactive login flow with stored credentials.\n- What to do: check whether the matching CLI exists, for example `which gh`, `which glab`, or `which az` (or platform equivalent). If installed, run `{cli} auth login` and let it complete browser or device OAuth, then retry git access.\n- **If the CLI is not installed**: do NOT try `npx` — platform CLIs (`gh`, `glab`, `az`) are native binaries, not npm packages. Skip straight to Step 4 (PAT). For file-read-only tasks, the `http` tool with a PAT header is a zero-dependency alternative to any CLI.\n- Verify: `git ls-remote <url>`; SUCCESS -> stop, FAIL -> Step 4.\n\n### Step 4: Personal Access Token\n\n- Goal: recover access when SSH and CLI OAuth are unavailable or blocked.\n- What to do: ask the user to create a PAT or app password at the platform-specific URL with minimum read scopes only. Have the user provide it through an env var or credential helper, then configure git credentials without embedding the token in the remote URL.\n- Verify: `git ls-remote <url>`; SUCCESS -> stop, FAIL -> Step 5.\n\n### Step 5: Local Clone Fallback\n\n- Goal: unblock work when remote auth cannot be completed from the current environment.\n- What to do: ask the user to clone the repository on their machine using their normal workflow, then provide the local filesystem path. Use the local checkout as the source of truth for code access.\n- Verify: local repo exists and `git rev-parse --show-toplevel` succeeds; SUCCESS -> stop, FAIL -> Step 6.\n\n### Step 6: Browser-Based Auth Recovery\n\n- Goal: use Playwright MCP browser tools to authenticate through login walls, SAML SSO, or OAuth flows that block all CLI paths.\n- Prerequisite: **load the `browser-use` skill** before proceeding.\n- What to do:\n  1. `open_browser_page({ url: repoUrl })` — open the target resource in the browser.\n  2. `read_page({ pageId })` — check if login form, SSO redirect, or content appears.\n  3. If SSO/OAuth login form → interact using `click_element`, `type_in_page` (ask user for credentials, NEVER guess).\n  4. If 2FA prompt → ask user for code via elicitation → `type_in_page` to enter it.\n  5. Once authenticated → extract content via `read_page` or `run_playwright_code`.\n  6. For ongoing CLI access → extract session cookies:\n     ```javascript\n     const cookies = await page.context().cookies()\n     return cookies.filter(c => c.name.includes(\'session\') || c.name.includes(\'auth\'))\n     ```\n  7. Use extracted cookies with the `http` tool: `http({ url, headers: { Cookie: \'...\' } })`.\n- Verify: content is accessible via browser tools; SUCCESS -> stop.\n- If browser-based auth also fails → the resource genuinely requires manual user intervention outside the agent workflow. Inform the user.\n\n> **Security:** Never store extracted cookies in code, commits, or logs. Warn the user that cookies are auth tokens that expire.\n\n## Security Rules (HARD GATE)\n\n- NEVER include a PAT in a git URL; it leaks into shell history, process lists, logs, and config.\n- NEVER repeat a user\'s token value in chat output, summaries, examples, or when relaying tool output that may contain credentials.\n- Use env vars, credential helpers, or platform login tools for token delivery.\n- Recommend minimum scopes only: read-only repo scopes, not broad write/admin scopes.\n- Prefer ephemeral credentials, OAuth/device flows, or short-lived tokens over long-lived PATs.\n- When guiding PAT creation, recommend the shortest feasible expiry (7–30 days for task-specific work).\n\n## After Access Is Established\n\n- Remind the user to revoke single-use PATs once the task is complete.\n- If credentials were stored via a credential helper, note that they persist until manually removed or the token expires.\n\n## Web-Based Code Access (web_fetch / http)\n\nAgents often use `web_fetch` or `http` to read individual files without a full clone. These requests fail silently on private repos — GitHub returns `404` or login HTML, not an auth error.\n\n### Common URL Patterns That Fail on Private Repos\n\n| URL Pattern | Platform | What Happens |\n|---|---|---|\n| `raw.githubusercontent.com/{owner}/{repo}/{ref}/{path}` | GitHub | `404` — no auth header accepted |\n| `github.com/{owner}/{repo}/blob/{ref}/{path}` | GitHub web view | `200` with login HTML, not code |\n| `api.github.com/repos/{owner}/{repo}/contents/{path}` | GitHub API | `404` (the GitHub 404 trap) |\n| `<ghe-host>/{owner}/{repo}/*` (any GHE URL) | GitHub Enterprise | `200` with SAML SSO redirect page — body contains "Initiating SAML single sign-on" and redirect to `login.microsoftonline.com` or other IdP |\n| `gitlab.com/{owner}/{repo}/-/raw/{ref}/{path}` | GitLab | `401` or login redirect |\n| `dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items` | Azure DevOps | `401` or `203` non-authoritative |\n\n### SAML SSO Detection (CRITICAL)\n\nGHE instances with SAML SSO return `200 OK` with an HTML body that is NOT the requested content. **This is the most common false-"inaccessible" scenario.** Detect it by checking `web_fetch` output for ANY of these strings:\n\n- `Initiating SAML single sign-on`\n- `login.microsoftonline.com` (Azure AD / Entra ID)\n- `You are being redirected to your identity provider`\n- `/login?return_to=`\n- `SAMLRequest=`\n- `RelayState=`\n\nIf ANY of these appear → the repo exists and is accessible, it just needs authentication. This is NOT "inaccessible" — follow the Strategy Ladder.\n\n### Recovery: Authenticated API Reads\n\nWhen `web_fetch` fails on a private repo URL, switch to authenticated `http` calls:\n\n1. **Ensure auth is established first** — walk the Strategy Ladder (Steps 1-4) to get working credentials.\n2. **Use the platform API with auth headers**, not raw/web URLs:\n\n| Platform | Authenticated file-read endpoint | Auth header |\n|---|---|---|\n| GitHub / GHE | `http GET https://api.github.com/repos/{owner}/{repo}/contents/{path}?ref={branch}` | `Authorization: token <PAT>` or use `gh api` |\n| GitLab | `http GET https://gitlab.com/api/v4/projects/{id}/repository/files/{path}/raw?ref={branch}` | `PRIVATE-TOKEN: <PAT>` |\n| Azure DevOps | `http GET https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path={path}&api-version=7.0` | `Authorization: Basic <base64(:PAT)>` |\n| Bitbucket | `http GET https://api.bitbucket.org/2.0/repositories/{owner}/{repo}/src/{ref}/{path}` | `Authorization: Bearer <token>` |\n\n3. **Prefer `http` over `web_fetch`** for private repos — `http` sends proper headers and returns machine-readable JSON; `web_fetch` gets HTML login pages.\n4. **For bulk reads**, prefer `git clone --depth 1` over many individual API calls — it\'s faster and avoids rate limits.\n5. **NEVER embed tokens in URLs** — use auth headers via the `http` tool or `gh api` CLI wrapper.\n\n### Quick Decision: Clone vs API Read\n\n| Situation | Preferred method |\n|---|---|\n| Need 1-3 specific files | Authenticated API via `http` |\n| Need to browse/search the repo | `git clone --depth 1` (shallow) |\n| Need file history or blame | `git clone` |\n| No terminal available | Authenticated API via `http` with PAT |\n| Rate-limited on API | `git clone --depth 1` |\n\n## Tool Routing\n\n| Tool | Use |\n| --- | --- |\n| `git_context` | Check local repo state and confirm a clone or fallback checkout is usable |\n| `http` | Probe platform APIs for auth diagnostics AND read file contents from private repos with auth headers |\n| `web_fetch` | Only for public repos or after confirming access works; unreliable for private repos (returns HTML, not code) |\n| `web_search` | Find current platform-specific auth documentation when the host is unusual or self-managed |\n| Terminal | Run git commands, SSH tests, CLI auth flows, and credential-helper setup |\n\nFor detailed error patterns, read `references/error-patterns.md`.\n\n## CRITICAL: The GitHub 404 Trap\n\nGitHub commonly returns `404 Not Found` for private repositories when the caller is unauthenticated or under-authenticated. NEVER conclude that a GitHub repository does not exist from a `404` alone. Treat that response as an authentication signal first, then walk the ladder before declaring the repo missing.'}];export{e as default};
+var e=[{file:`references/error-patterns.md`,content:'# Repo Access Error Patterns\n\nUse this reference to distinguish missing repositories from authentication and policy failures when probing Git hosts.\n\n## HTTP Status Code Matrix\n\n| Platform | No auth (private repo) | Wrong credentials | Rate limited | SSO required |\n|---|---|---|---|---|\n| GitHub REST API | `404` (TRAP!) | `401` -> `403` | `403` + rate limit body | `403` + `X-GitHub-SSO` header |\n| GitHub Web | HTML "Page not found" or login redirect | Login redirect | - | - |\n| GitLab | `401` | `401` | `429` | `401` (PAT mandatory) |\n| Bitbucket | `403` | `403` | `429` | `403` |\n| Azure DevOps | `401` | `401` | - | `401` |\n\n## CRITICAL: The GitHub 404 Trap\n\nGitHub deliberately returns `404`, not `401`, for private repositories accessed without authentication.\nThis is by design to avoid leaking whether a repository exists.\n\n- Never conclude a GitHub repository does not exist from an unauthenticated `404`.\n- `GET https://api.github.com/repos/{owner}/{repo}` without auth returns `404` for both "repo truly missing" and "repo exists but is private".\n- The only reliable disambiguation is an authenticated probe.\n- If the same request still returns `404` with valid auth, the repository is truly missing.\n\nProbe order:\n\n1. Try the authenticated API request first.\n2. If it returns `200`, access works.\n3. If it returns `404` without auth context, treat it as ambiguous and recover.\n4. If it returns `404` with known-good auth, treat the repo as missing.\n\n## Git CLI Stderr Patterns\n\n| Error Text Pattern | Platform | Diagnosis | Action |\n|---|---|---|---|\n| `remote: Repository not found.` | GitHub | Auth failure, not proof the repo is missing | Try auth strategies |\n| `git@github.com: Permission denied (publickey).` | GitHub | SSH key not recognized | Check SSH keys, try HTTPS |\n| `remote: HTTP Basic: Access denied.` | GitLab | Auth failure, 2FA likely | Use PAT; password auth is blocked with 2FA |\n| `error: The requested URL returned error: 403` | Bitbucket | Auth failure | Try app password |\n| `TF401019: The Git repository with name or identifier X does not exist` | Azure DevOps | Auth failure or missing repo | Try PAT with Code:Read scope |\n| `fatal: Authentication failed for \'https://...\'` | Any (HTTPS) | General auth failure | Escalate through the strategy ladder |\n| `Permission denied (publickey).` | Any (SSH) | SSH key not recognized | Check `~/.ssh/`, run `ssh-add`, try HTTPS |\n| `fatal: Could not read from remote repository.` | Any (SSH) | SSH access denied | Verify the SSH key is added to the platform |\n| `unable to access \'...\': SSL certificate problem` | Any | Self-signed or enterprise CA issue | Ask about local cert config; skip to local clone if needed |\n\nTreat these stderr strings as direct signals from tool output. Do not reinterpret GitHub\'s `Repository not found` as a clean existence check.\n\n## web_fetch / http Tool Detection\n\n- `web_fetch` against a private GitHub repo URL often returns HTML with "Page not found" or a login page.\n- GitHub web responses can be `200` with a 404-looking body, so `web_fetch` is unreliable for auth diagnosis.\n- `http` against the platform API gives machine-readable bodies and real status codes, so use it for probes.\n- For `web_fetch` on `github.com`, inspect the body for `Page not found`, `Sign in`, or `/login` links. If present, assume private or auth-gated access and trigger recovery.\n\nRecommended diagnostic probe:\n\n```text\nhttp GET https://api.github.com/repos/{owner}/{repo}\n-> 404 + no auth header -> might be private\n-> 401 -> explicit auth failure\n-> 200 -> repo is public, access works\n```\n\n## Edge Cases\n\n| Edge Case | Signal | Response |\n|---|---|---|\n| GitHub.com SAML SSO | `403` + `X-GitHub-SSO: required; url=...` | PAT needs SSO authorization for the org |\n| GHE SAML SSO (web_fetch) | `200` + body contains `Initiating SAML single sign-on`, redirect to `login.microsoftonline.com` or other IdP | Repo EXISTS and is auth-gated. NOT inaccessible. Use PAT + `http` with auth headers, or `gh auth login --hostname <host>` |\n| GHE SAML SSO (http) | `302` redirect to `/login?return_to=...` or IdP URL | Same — repo exists, needs auth. Walk the Strategy Ladder |\n| GHE SAML SSO (git CLI) | `fatal: Authentication failed` or credential prompt | `gh auth login --hostname <host>` or PAT via credential helper |\n\n## SAML SSO — Detailed Pattern\n\nGitHub Enterprise instances commonly use SAML SSO via Azure AD (Entra ID), Okta, or other IdPs. When `web_fetch` hits a GHE URL without auth:\n\n1. GHE returns `200 OK` (not 401/403!) with an HTML page\n2. The HTML contains `Initiating SAML single sign-on` and a redirect URL to the IdP\n3. The redirect URL includes `SAMLRequest=`, `RelayState=`, and often `login.microsoftonline.com`\n4. The agent sees HTML content and may conclude the repo is "inaccessible" or "behind SSO"\n\n**Detection strings** (check `web_fetch` output for ANY of these):\n```\nInitiating SAML single sign-on\nlogin.microsoftonline.com\nYou are being redirected to your identity provider\n/login?return_to=\nSAMLRequest=\nRelayState=\n```\n\n**Correct response:** The repo exists. The `web_fetch` path will never work for SSO-protected GHE. Switch to:\n- `gh auth login --hostname <ghe-host>` (if `gh` CLI available)\n- PAT + `http` with `Authorization: token <PAT>` against `<ghe-host>/api/v3/repos/{owner}/{repo}/contents/{path}`\n- Ask user for local clone if no token can be obtained\n| GitLab 2FA enabled | `401` on password auth | PAT is mandatory; 2FA blocks password auth |\n| Expired token | `401` after providing a valid-looking PAT | Generate a new token and check expiry |\n| GitHub rate limit | `403` + body contains `rate limit` | Not an auth failure; wait or authenticate for a higher limit |\n| IP allowlisting | `403` + body mentions IP or org policies | Cannot be fixed programmatically; skip to local clone (Step 5) |\n| Fine-grained PAT scope | `403` + `insufficient scope` | Switch to a classic PAT for org repos |\n| SSH key not in agent | `Permission denied (publickey)` + key file exists | Run `ssh-add ~/.ssh/id_ed25519` |\n| Wrong SSH username | `Permission denied` | Use `git@host`, not `username@host` |\n| Deploy key conflict | `key is already in use` | Use a user SSH key or PAT instead |\n\n## Escalation Decision Rules\n\n- Retry the same step for transient failures such as DNS failure, timeout, or `5xx` responses.\n- Escalate to the next strategy step for `401`, `403`, `404`, `Permission denied`, `Authentication failed`, or `Access denied`.\n- Skip directly to Step 5 (local clone) for IP allowlisting, enterprise SSL certificate issues, or org policy blocks.\n\nDefault interpretation order:\n\n1. Prefer API probes over web page fetches.\n2. Treat GitHub `404` as ambiguous until valid auth disproves privacy.\n3. Treat SSH `publickey` errors as key-distribution failures, not repo absence.\n4. Separate rate limits and org policy blocks from authentication failures before escalating.'},{file:`references/platform-matrix.md`,content:"# Platform Matrix\n\nUse this reference when a repository URL reveals the hosting platform and the skill needs platform-specific authentication or cloning guidance. Prefer platform CLI login flows or OS-backed credential helpers over raw PAT handling.\n\n## Platform Detection\n\n| URL Pattern | Platform | CLI Tool (optional) | Auth Command | No-CLI Alternative |\n|---|---|---|---|---|\n| `github.com` | GitHub | `gh` | `gh auth login` | PAT + `http` with `Authorization: token <PAT>` |\n| Any custom domain (e.g. `ghe.corp.com`, `github.corp.com`) | GitHub Enterprise | `gh` | `gh auth login --hostname <host>` | PAT + `http` against `<host>/api/v3` |\n| `gitlab.com` | GitLab | `glab` | `glab auth login` | PAT + `http` with `PRIVATE-TOKEN` header |\n| Self-hosted GitLab | GitLab Self-Managed | `glab` | `glab auth login --hostname <host>` | PAT + `http` with `PRIVATE-TOKEN` header |\n| `bitbucket.org` | Bitbucket Cloud | None | N/A | App password + `http` with `Authorization: Bearer` |\n| `dev.azure.com` or `*.visualstudio.com` | Azure DevOps | `az` + GCM | `az login` | PAT + `http` with Basic auth |\n| Gitea instances | Gitea | `tea` (optional) | `tea login add` | PAT + `http` with `Authorization: token` |\n| Unknown or custom domain | Ask user which platform | N/A | N/A | Probe `http` or ask before assuming generic Git |\n\n> **Note:** Platform CLIs (`gh`, `glab`, `az`, `tea`) are native binaries, not npm packages. Do NOT use `npx` to install them — it will fail or install unrelated/unofficial packages. When the CLI is unavailable, use the No-CLI Alternative column.\n\n## GitHub / GitHub Enterprise\n\n- CLI: `gh auth login` uses a browser or device code flow and can open the browser automatically.\n- GitHub Enterprise CLI: `gh auth login --hostname <host>`.\n- PAT creation: `https://github.com/settings/tokens` for classic tokens.\n- PAT creation: `https://github.com/settings/personal-access-tokens` for fine-grained tokens.\n- Minimum scopes: `repo` for classic PATs (NOTE: `repo` grants read and write — prefer fine-grained PATs with `Contents: Read` for read-only access).\n- Minimum scopes: `Contents: Read` for fine-grained PATs.\n- SSH: `git@github.com:owner/repo.git`.\n- Credential helper: `gh auth setup-git` configures Git to use the GitHub credential flow.\n- Note: Fine-grained PATs may not cover organization-level access or every repo path; classic PATs are still required for some org repos.\n- SAML SSO: PATs often require explicit org authorization from `https://github.com/settings/tokens` after creation.\n- Enterprise note: PAT URLs and token policy can vary by host; reuse the same auth pattern with the enterprise hostname and instance settings pages.\n- Enterprise detection: GHE instances use fully custom domains (e.g. `ghe.coxautoinc.com`, `github.acme.com`). If unsure, probe `https://<host>/api/v3` — a GitHub Enterprise instance returns a JSON response with `installed_version`. Use `gh auth login --hostname <host>` with any custom GHE domain.\n\n## GitLab / GitLab Self-Managed\n\n- CLI: `glab auth login` uses a browser-backed OAuth flow.\n- Self-managed CLI: `glab auth login --hostname <host>`.\n- PAT creation: `https://gitlab.com/-/user_settings/personal_access_tokens`.\n- Minimum scopes: `read_repository`.\n- SSH: `git@gitlab.com:owner/repo.git`.\n- Credential helper: `glab auth setup-git` configures Git credential handling.\n- Note: If 2FA is enabled, username/password Git auth is blocked; a PAT is mandatory for HTTPS auth.\n- Self-managed note: PAT URL is typically `https://<host>/-/user_settings/personal_access_tokens` unless the instance customizes settings paths.\n\n## Bitbucket Cloud\n\n- CLI: No official first-party CLI OAuth flow for repo auth.\n- PAT/App Password creation: `https://bitbucket.org/{workspace}/settings/app-passwords`.\n- Minimum permissions: `Repositories: Read`.\n- SSH: `git@bitbucket.org:owner/repo.git`.\n- Note: Bitbucket Cloud uses App Passwords rather than standard PAT terminology.\n- Note: HTTPS auth requires both the Bitbucket username and the app password, delivered through a credential helper or `GIT_ASKPASS` script — never embedded in the clone URL.\n\n## Azure DevOps\n\n- CLI: `az login` authenticates to Microsoft Entra ID; Git Credential Manager then handles Git credentials automatically.\n- PAT-based auth remains the fallback when Entra ID or GCM is unavailable.\n- PAT creation: `https://dev.azure.com/{org}/_usersSettings/tokens`.\n- Minimum scopes: `Code: Read`.\n- SSH: `git@ssh.dev.azure.com:v3/{org}/{project}/{repo}`.\n- Note: Microsoft Entra ID tokens are generally preferred over PATs in enterprise environments.\n- Credential helper: Git Credential Manager via `git-credential-manager configure`.\n- Legacy host note: Azure DevOps may also appear under `*.visualstudio.com` URLs.\n\n## Gitea / Forgejo\n\n- CLI: `tea login add` is available but optional and not universally installed.\n- PAT creation: `https://{host}/user/settings/applications`.\n- Minimum scopes: `repo`.\n- SSH: `git@{host}:owner/repo.git`.\n- Note: Forgejo commonly mirrors the same applications-token path and PAT model as Gitea.\n- Note: Some self-hosted instances rename scopes or disable API token creation, so confirm the instance policy if `repo` is rejected.\n\n## Generic Git (Self-Hosted)\n\n- Platform CLI: None assumed.\n- Auth path: Prefer SSH keys first, then PAT if the host documents HTTPS token auth.\n- PAT creation: Ask the user for the platform's PAT or application-token settings URL.\n- SSH: Use the host's documented SSH remote format; do not assume GitHub-style shortcuts if the server advertises a different pattern.\n\n## API File-Read Endpoints (for web-based code access)\n\nWhen agents need to read individual files without cloning, use these authenticated API endpoints.\n\n### GitHub / GitHub Enterprise\n\n```text\n# Read file contents (returns JSON with base64 content)\nGET https://api.github.com/repos/{owner}/{repo}/contents/{path}?ref={branch}\nAuthorization: token <PAT>\n\n# GHE: replace api.github.com with <ghe-host>/api/v3\nGET https://<ghe-host>/api/v3/repos/{owner}/{repo}/contents/{path}?ref={branch}\n\n# Or use gh CLI (auto-authenticated):\ngh api repos/{owner}/{repo}/contents/{path}?ref={branch} --jq '.content' | base64 -d\n```\n\n### GitLab / GitLab Self-Managed\n\n```text\n# URL-encode the file path (/ becomes %2F)\nGET https://gitlab.com/api/v4/projects/{project-id}/repository/files/{url-encoded-path}/raw?ref={branch}\nPRIVATE-TOKEN: <PAT>\n\n# Or use project path instead of ID:\nGET https://gitlab.com/api/v4/projects/{url-encoded-namespace%2Fproject}/repository/files/{url-encoded-path}/raw?ref={branch}\n```\n\n### Azure DevOps\n\n```text\nGET https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path={path}&api-version=7.0\nAuthorization: Basic {base64(:PAT)}\n```\n\n### Bitbucket Cloud\n\n```text\nGET https://api.bitbucket.org/2.0/repositories/{workspace}/{repo}/src/{commit-or-branch}/{path}\nAuthorization: Bearer <app-password-or-token>\n```\n- Note: Self-hosted products often customize auth policy, token names, and minimum scopes.\n\n## Safe Credential Delivery Patterns\n\n| Method | Command | Safety |\n|---|---|---|\n| Platform CLI | `gh auth login` / `glab auth login` | Best — handles credential storage |\n| Git Credential Manager | `git credential-manager configure` | Good — OS keychain storage |\n| Environment variable | `GH_TOKEN=xxx gh repo clone ...` | OK — ephemeral; safer than URL tokens but visible to same-user processes |\n| Git askpass | `GIT_ASKPASS=script git clone ...` | OK — no shell history exposure |\n| Inline in URL | `git clone https://token@host/...` | FORBIDDEN — leaks in history/logs |\n\n## Operational Notes\n\n- Prefer SSH when the user already has working keys and the host advertises a stable SSH remote format.\n- Prefer platform CLI login for GitHub and GitLab because it also wires Git credential storage.\n- Prefer Git Credential Manager for Azure DevOps and other HTTPS-heavy enterprise setups.\n- When recommending PAT creation, always suggest setting a short expiry (7-30 days for task-specific work). Prefer fine-grained or short-lived tokens.\n- Never recommend pasting tokens inline into clone URLs, scripts checked into the repo, or long-lived shell profiles."},{file:`SKILL.md`,content:`---
+name: repo-access
+description: "Progressive repository access recovery for private and enterprise git repositories. Triggered when: (1) git clone/fetch/pull fails with auth errors (401, 403, 404, Permission denied), (2) web_fetch or http tool returns auth failure on repository URLs, (3) user mentions private repo, enterprise repo, or internal repo, (4) user asks to access code from GitHub Enterprise, GitLab Self-Managed, Bitbucket Server, Azure DevOps. Guides through 6-step progressive strategy: anonymous HTTPS, SSH keys, CLI OAuth, PAT, local clone fallback, browser-based auth recovery (via browser-use skill)."
+metadata:
+  category: cross-cutting
+  domain: general
+  applicability: on-demand
+  inputs: [git-error, repository-url, platform-context]
+  outputs: [authenticated-access, recovery-instructions]
+  requires: []
+  relatedSkills: [aikit]
+argument-hint: "Repository URL or error message"
+---
+
+# Repository Access Recovery
+
+Progressively recover repository access for private, enterprise, and internal git hosts without leaking credentials.
+
+## When to Activate
+
+### Reactive triggers
+
+- \`git clone\`, \`git fetch\`, or \`git pull\` fails with \`401\`, \`403\`, \`404\`, \`Authentication failed\`, or \`Permission denied (publickey)\`.
+- \`http\` diagnostics against a repo endpoint show auth failure or ambiguous private-repo responses.
+- \`web_fetch\` returns login page HTML, SSO redirect, "Sign in", "Page not found", or empty/truncated content for a repo URL.
+- Any tool output contains "behind SSO", "SSO required", "SAML", "requires authentication", or similar auth-gate language about a repository.
+- A repository URL works in a browser for the user but fails from agent tools or terminal commands.
+- **You are about to declare a repo "inaccessible" or "unreachable"** — STOP and activate this skill first.
+
+### Proactive triggers
+
+- The user says the repo is private, enterprise, self-managed, internal, or SSO-protected.
+- The repo is hosted on GitHub Enterprise, GitLab Self-Managed, Bitbucket Server/Data Center, Azure DevOps, Gitea, or another custom git host.
+- The environment may need browser sign-in, SSH agent setup, or token-based recovery before any code access can work.
+
+## When NOT to Activate
+
+- Public repositories that already clone or read successfully over HTTPS.
+- Local-only repositories where no remote auth is involved.
+- Problems caused by branch protection, merge conflicts, or rate limiting rather than repository access.
+
+## Step 0: Platform Detection & Capability Gate
+
+Detect platform from the URL, then decide what recovery options are possible in this environment.
+
+| URL pattern | Platform |
+| --- | --- |
+| \`github.com\`, or any GHE host (e.g. \`ghe.*\`, \`github.*\`, custom domain) | GitHub / GitHub Enterprise |
+| \`gitlab.com\`, \`gitlab.<corp-host>\` | GitLab / GitLab Self-Managed |
+| \`bitbucket.org\`, \`bitbucket.<corp-host>\` | Bitbucket Cloud / Server |
+| \`dev.azure.com\`, \`visualstudio.com\`, \`/_git/\` | Azure DevOps |
+| anything else with git over HTTPS/SSH | Unknown — ask the user which platform before assuming generic Git |
+
+- Capability gate: has terminal, has browser, or conversation-only.
+- If terminal is unavailable, skip directly to PAT guidance or local clone fallback.
+- If browser is unavailable, prefer SSH or pre-created credentials over CLI OAuth.
+- If only the \`http\` tool is available (no terminal, no CLI): use PAT + authenticated API reads (see "Web-Based Code Access" below). This is the zero-dependency path — no \`gh\`, \`glab\`, or \`az\` installation needed.
+
+For platform-specific details, read \`references/platform-matrix.md\`.
+
+## Strategy Ladder
+
+### Step 1: Try HTTPS Anonymous Access
+
+- Goal: prove the repo is public or already reachable without extra auth.
+- What to do: normalize the remote to an HTTPS URL and run \`git ls-remote https://...\`. If it succeeds, use HTTPS and stop. If it fails with auth-like errors, continue instead of assuming the repo is missing.
+- Verify: \`git ls-remote <url>\`; SUCCESS -> stop, FAIL -> Step 2.
+
+### Step 2: Check Existing SSH Keys
+
+- Goal: reuse working SSH credentials before asking for new secrets.
+- What to do: inspect \`~/.ssh/\` for key files, run \`ssh-add -l\`, then test host auth with \`ssh -T git@{host}\`. If SSH works, switch the remote to the SSH URL and continue with that transport.
+- Verify: \`git ls-remote <ssh-url>\`; SUCCESS -> stop, FAIL -> Step 3.
+
+### Step 3: Platform CLI OAuth
+
+- Goal: use the platform's interactive login flow with stored credentials.
+- What to do: check whether the matching CLI exists, for example \`which gh\`, \`which glab\`, or \`which az\` (or platform equivalent). If installed, run \`{cli} auth login\` and let it complete browser or device OAuth, then retry git access.
+- **If the CLI is not installed**: do NOT try \`npx\` — platform CLIs (\`gh\`, \`glab\`, \`az\`) are native binaries, not npm packages. Skip straight to Step 4 (PAT). For file-read-only tasks, the \`http\` tool with a PAT header is a zero-dependency alternative to any CLI.
+- Verify: \`git ls-remote <url>\`; SUCCESS -> stop, FAIL -> Step 4.
+
+### Step 4: Personal Access Token
+
+- Goal: recover access when SSH and CLI OAuth are unavailable or blocked.
+- What to do: ask the user to create a PAT or app password at the platform-specific URL with minimum read scopes only. Have the user provide it through an env var or credential helper, then configure git credentials without embedding the token in the remote URL.
+- Verify: \`git ls-remote <url>\`; SUCCESS -> stop, FAIL -> Step 5.
+
+### Step 5: Local Clone Fallback
+
+- Goal: unblock work when remote auth cannot be completed from the current environment.
+- What to do: ask the user to clone the repository on their machine using their normal workflow, then provide the local filesystem path. Use the local checkout as the source of truth for code access.
+- Verify: local repo exists and \`git rev-parse --show-toplevel\` succeeds; SUCCESS -> stop, FAIL -> Step 6.
+
+### Step 6: Browser-Based Auth Recovery
+
+- Goal: use the AI Kit browser tool to authenticate through login walls, SAML SSO, or OAuth flows that block all CLI paths.
+- Prerequisite: **load the \`browser-use\` skill** before proceeding.
+- What to do:
+  1. \`browser({ action: 'open', url: repoUrl, mode: 'ui' })\` — open the target resource in the browser.
+  2. \`browser({ action: 'read', pageId })\` — check if login form, SSO redirect, or content appears.
+  3. If SSO/OAuth login form → interact using \`browser({ action: 'act', pageId, kind: 'click' | 'type', ... })\` (ask user for credentials, NEVER guess).
+  4. If 2FA prompt → ask user for code via elicitation → \`browser({ action: 'act', pageId, kind: 'type', ... })\` to enter it.
+  5. Once authenticated → extract content via \`browser({ action: 'read', pageId })\` or \`browser({ action: 'eval', pageId, code })\`.
+  6. For ongoing CLI access → extract session cookies:
+     \`\`\`javascript
+     browser({ action: 'session', sessionAction: 'cookies', pageId })
+     \`\`\`
+  7. Use extracted cookies with the \`http\` tool: \`http({ url, headers: { Cookie: '...' } })\`.
+- Verify: content is accessible via browser tools; SUCCESS -> stop.
+- If browser-based auth also fails → the resource genuinely requires manual user intervention outside the agent workflow. Inform the user.
+
+> **Security:** Never store extracted cookies in code, commits, or logs. Warn the user that cookies are auth tokens that expire.
+
+## Security Rules (HARD GATE)
+
+- NEVER include a PAT in a git URL; it leaks into shell history, process lists, logs, and config.
+- NEVER repeat a user's token value in chat output, summaries, examples, or when relaying tool output that may contain credentials.
+- Use env vars, credential helpers, or platform login tools for token delivery.
+- Recommend minimum scopes only: read-only repo scopes, not broad write/admin scopes.
+- Prefer ephemeral credentials, OAuth/device flows, or short-lived tokens over long-lived PATs.
+- When guiding PAT creation, recommend the shortest feasible expiry (7–30 days for task-specific work).
+
+## After Access Is Established
+
+- Remind the user to revoke single-use PATs once the task is complete.
+- If credentials were stored via a credential helper, note that they persist until manually removed or the token expires.
+
+## Web-Based Code Access (web_fetch / http)
+
+Agents often use \`web_fetch\` or \`http\` to read individual files without a full clone. These requests fail silently on private repos — GitHub returns \`404\` or login HTML, not an auth error.
+
+### Common URL Patterns That Fail on Private Repos
+
+| URL Pattern | Platform | What Happens |
+|---|---|---|
+| \`raw.githubusercontent.com/{owner}/{repo}/{ref}/{path}\` | GitHub | \`404\` — no auth header accepted |
+| \`github.com/{owner}/{repo}/blob/{ref}/{path}\` | GitHub web view | \`200\` with login HTML, not code |
+| \`api.github.com/repos/{owner}/{repo}/contents/{path}\` | GitHub API | \`404\` (the GitHub 404 trap) |
+| \`<ghe-host>/{owner}/{repo}/*\` (any GHE URL) | GitHub Enterprise | \`200\` with SAML SSO redirect page — body contains "Initiating SAML single sign-on" and redirect to \`login.microsoftonline.com\` or other IdP |
+| \`gitlab.com/{owner}/{repo}/-/raw/{ref}/{path}\` | GitLab | \`401\` or login redirect |
+| \`dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items\` | Azure DevOps | \`401\` or \`203\` non-authoritative |
+
+### SAML SSO Detection (CRITICAL)
+
+GHE instances with SAML SSO return \`200 OK\` with an HTML body that is NOT the requested content. **This is the most common false-"inaccessible" scenario.** Detect it by checking \`web_fetch\` output for ANY of these strings:
+
+- \`Initiating SAML single sign-on\`
+- \`login.microsoftonline.com\` (Azure AD / Entra ID)
+- \`You are being redirected to your identity provider\`
+- \`/login?return_to=\`
+- \`SAMLRequest=\`
+- \`RelayState=\`
+
+If ANY of these appear → the repo exists and is accessible, it just needs authentication. This is NOT "inaccessible" — follow the Strategy Ladder.
+
+### Recovery: Authenticated API Reads
+
+When \`web_fetch\` fails on a private repo URL, switch to authenticated \`http\` calls:
+
+1. **Ensure auth is established first** — walk the Strategy Ladder (Steps 1-4) to get working credentials.
+2. **Use the platform API with auth headers**, not raw/web URLs:
+
+| Platform | Authenticated file-read endpoint | Auth header |
+|---|---|---|
+| GitHub / GHE | \`http GET https://api.github.com/repos/{owner}/{repo}/contents/{path}?ref={branch}\` | \`Authorization: token <PAT>\` or use \`gh api\` |
+| GitLab | \`http GET https://gitlab.com/api/v4/projects/{id}/repository/files/{path}/raw?ref={branch}\` | \`PRIVATE-TOKEN: <PAT>\` |
+| Azure DevOps | \`http GET https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/items?path={path}&api-version=7.0\` | \`Authorization: Basic <base64(:PAT)>\` |
+| Bitbucket | \`http GET https://api.bitbucket.org/2.0/repositories/{owner}/{repo}/src/{ref}/{path}\` | \`Authorization: Bearer <token>\` |
+
+3. **Prefer \`http\` over \`web_fetch\`** for private repos — \`http\` sends proper headers and returns machine-readable JSON; \`web_fetch\` gets HTML login pages.
+4. **For bulk reads**, prefer \`git clone --depth 1\` over many individual API calls — it's faster and avoids rate limits.
+5. **NEVER embed tokens in URLs** — use auth headers via the \`http\` tool or \`gh api\` CLI wrapper.
+
+### Quick Decision: Clone vs API Read
+
+| Situation | Preferred method |
+|---|---|
+| Need 1-3 specific files | Authenticated API via \`http\` |
+| Need to browse/search the repo | \`git clone --depth 1\` (shallow) |
+| Need file history or blame | \`git clone\` |
+| No terminal available | Authenticated API via \`http\` with PAT |
+| Rate-limited on API | \`git clone --depth 1\` |
+
+## Tool Routing
+
+| Tool | Use |
+| --- | --- |
+| \`git_context\` | Check local repo state and confirm a clone or fallback checkout is usable |
+| \`http\` | Probe platform APIs for auth diagnostics AND read file contents from private repos with auth headers |
+| \`web_fetch\` | Only for public repos or after confirming access works; unreliable for private repos (returns HTML, not code) |
+| \`web_search\` | Find current platform-specific auth documentation when the host is unusual or self-managed |
+| Terminal | Run git commands, SSH tests, CLI auth flows, and credential-helper setup |
+
+For detailed error patterns, read \`references/error-patterns.md\`.
+
+## CRITICAL: The GitHub 404 Trap
+
+GitHub commonly returns \`404 Not Found\` for private repositories when the caller is unauthenticated or under-authenticated. NEVER conclude that a GitHub repository does not exist from a \`404\` alone. Treat that response as an authentication signal first, then walk the ladder before declaring the repo missing.`}];export{e as default};

package/scaffold/dist/definitions/tools.mjs

@@ -1 +1 @@
-const e=`analyze.audit.blast_radius.changelog.check.checkpoint.codemod.compact.config.data_transform.dead_symbols.delegate.describe_tool.diff_parse.digest.encode.env.eval.evidence_map.file_summary.find.flow.forge_classify.forge_ground.git_context.graph.guide.health.http.knowledge.lane.list_tools.lookup.measure.onboard.parse_output.present.process.produce_knowledge.queue.regex_test.reindex.rename.replay.restore.schema_validate.scope_map.search.search_tools.session_digest.stash.status.stratum_card.symbol.test_run.time.trace.watch.web_fetch.web_search.workset`.split(`.`),t={orchestrator:[`memory`,`runCommand`,`switchAgent`,`newWorkspace`,`reviewPlan`,`killTerminal`,`createTask`,`terminal`,`terminalSel`,`lastCommand`,`problems`,`readFile`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`web`,`todo`,`searchSubagent`,`textSearch`,`browser`,`askQuestions`,`resolveMemoryFileUri`],researcher:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`search`,`web`,`browser`],reviewer:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`search`,`web`,`browser`],codeAgent:[`createTask`,`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`todo`,`browser`],debugger:[`terminal`,`problems`,`readFile`,`terminalSel`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`search`,`browser`],refactor:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`browser`],explorer:[`problems`,`readFile`,`search`,`fileSearch`,`listDir`,`textSearch`,`browser`],planner:[`terminal`,`problems`,`readFile`,`reviewPlan`,`memory`,`askQuestions`,`resolveMemoryFileUri`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`web`,`todo`,`searchSubagent`,`browser`],security:[`terminal`,`problems`,`readFile`,`subagent`,`search`,`web`,`browser`],documenter:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`web`,`browser`]};export{e as AIKIT_TOOLS,t as IDE_CAPABILITIES};
+const e=`analyze.audit.blast_radius.changelog.check.checkpoint.codemod.compact.config.data_transform.dead_symbols.delegate.describe_tool.diff_parse.digest.encode.env.eval.evidence_map.file_summary.find.flow.forge_classify.forge_ground.git_context.graph.guide.health.http.knowledge.lane.list_tools.lookup.measure.onboard.parse_output.present.process.produce_knowledge.queue.regex_test.reindex.rename.replay.restore.schema_validate.scope_map.search.search_tools.session_digest.stash.status.stratum_card.symbol.test_run.time.trace.watch.web_fetch.web_search.workset`.split(`.`),t={orchestrator:[`memory`,`runCommand`,`switchAgent`,`newWorkspace`,`reviewPlan`,`killTerminal`,`createTask`,`terminal`,`terminalSel`,`lastCommand`,`problems`,`readFile`,`subagent`,`search`,`web`,`todo`,`searchSubagent`,`textSearch`,`browser`,`askQuestions`,`resolveMemoryFileUri`],researcher:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`search`,`web`,`browser`],reviewer:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`search`,`web`,`browser`],codeAgent:[`createTask`,`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`todo`,`browser`],debugger:[`terminal`,`problems`,`readFile`,`terminalSel`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`search`,`browser`],refactor:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`browser`],explorer:[`problems`,`readFile`,`search`,`fileSearch`,`listDir`,`textSearch`,`browser`],planner:[`terminal`,`problems`,`readFile`,`reviewPlan`,`memory`,`askQuestions`,`resolveMemoryFileUri`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`web`,`todo`,`searchSubagent`,`browser`],security:[`terminal`,`problems`,`readFile`,`subagent`,`search`,`web`,`browser`],documenter:[`terminal`,`problems`,`readFile`,`lastCommand`,`subagent`,`createFile`,`editFiles`,`rename`,`createDirectory`,`search`,`web`,`browser`]};export{e as AIKIT_TOOLS,t as IDE_CAPABILITIES};

package/scaffold/generated/block-docs.mjs

@@ -1,13 +0,0 @@
-// AUTO-GENERATED - do not edit manually.
-// Source: packages/server/src/tools/present/block-registry.ts
-// Generated at: 2026-05-13T00:18:34.841Z
-
-export const ALL_BLOCK_DOCS = "| Type | Description | Value Shape |\n|------|-------------|-------------|\n| `markdown` | Markdown content rendered with the marked parser. | `string` |\n| `code` | Formatted code block rendered inside pre/code tags. | `string` |\n| `mermaid` | Mermaid diagram source rendered in a mermaid pre block. | `string` |\n| `table` | Tabular data rendered from records or explicit headers and rows. | `Record<string, unknown>[] | { headers: string[]; rows: unknown[][] }` |\n| `metrics` | Metric cards showing label/value pairs with optional trend and status. | `Array<{ label: string; value: string | number; trend?: string | number; status?: string }>` |\n| `cards` | Card grid for titled items with optional body, badge, and status. | `Array<{ title: string; body?: string; badge?: string; status?: string; description?: string }>` |\n| `tree` | Hierarchical object or name/children tree rendered recursively. | `{ name: string; children?: unknown[] } | Record<string, unknown>` |\n| `graph` | Node and edge graph rendered as a Mermaid flow graph in HTML mode. | `{ nodes: Array<{ id: string; label?: string }>; edges: Array<{ from: string; to: string; label?: string }> }` |\n| `chart` | Structured chart definition rendered as SVG. | `{ chartType: string; data: Record<string, unknown>[]; xKey: string; yKeys: string[] }` |\n| `timeline` | Timeline entries rendered as a vertical sequence of events. | `Array<{ title: string; description?: string; timestamp?: string; status?: string }>` |\n| `checklist` | Checklist items with boolean checked state. | `Array<{label, checked}> | {items: Array<{label, checked}>}` |\n| `comparison` | Side-by-side comparison columns with titled item lists. | `Array<{title, items}> | {columns: Array<{title, items}>}` |\n| `status-board` | Status categories containing labeled status items. | `Array<{category, items}> | {items: Array<{category, items}>}` |\n| `prompt` | Prompt payload rendered through the prompt display helper. | `unknown` |\n| `progress` | Progress bar with current value and optional maximum. | `{label, value, max?} | {items: Array<{label, value, max?, color?}>}` |\n| `docs-browser` | Documentation file list with inline content previews for chat-safe rendering. | `{ files: Array<{ path: string; title?: string; content?: string; status?: \"current\" | \"stale\" | \"missing\" }>; title?: string }` |\n| `text` | Plain text content rendered through the markdown parser. | `string` |\n| `heading` | Single heading with configurable level from h1 to h6. | `string` |\n| `paragraph` | Single paragraph rendered inside a p tag. | `string` |\n| `separator` | Horizontal rule used to separate adjacent blocks. | `undefined` |\n| `actions` | Action bar containing button and select action definitions. | `Array<{ type: string; id: string; label: string; variant?: string; options?: Array<string | { label: string; value: string }> }>` |\n\n### Usage Examples\n\n#### `docs-browser`\n\n```typescript\n{\n  type: 'docs-browser',\n  value: {\n    title: 'Project Docs',\n    files: [\n      { path: 'docs/README.md', title: 'Overview', status: 'current' },\n      { path: 'docs/api.md', title: 'API Reference', status: 'stale' },\n    ],\n  },\n}\n```";
-
-export const BLOCK_TYPE_LIST = "  - type:\"markdown\" → value: string\n  - type:\"code\" → value: string\n  - type:\"mermaid\" → value: string\n  - type:\"table\" → value: Record<string, unknown>[] | { headers: string[]; rows: unknown[][] }\n  - type:\"metrics\" → value: Array<{ label: string; value: string | number; trend?: string | number; status?: string }>\n  - type:\"cards\" → value: Array<{ title: string; body?: string; badge?: string; status?: string; description?: string }>\n  - type:\"tree\" → value: { name: string; children?: unknown[] } | Record<string, unknown>\n  - type:\"graph\" → value: { nodes: Array<{ id: string; label?: string }>; edges: Array<{ from: string; to: string; label?: string }> }\n  - type:\"chart\" → value: { chartType: string; data: Record<string, unknown>[]; xKey: string; yKeys: string[] }\n  - type:\"timeline\" → value: Array<{ title: string; description?: string; timestamp?: string; status?: string }>\n  - type:\"checklist\" → value: Array<{label, checked}> | {items: Array<{label, checked}>}\n  - type:\"comparison\" → value: Array<{title, items}> | {columns: Array<{title, items}>}\n  - type:\"status-board\" → value: Array<{category, items}> | {items: Array<{category, items}>}\n  - type:\"prompt\" → value: unknown\n  - type:\"progress\" → value: {label, value, max?} | {items: Array<{label, value, max?, color?}>}\n  - type:\"docs-browser\" → value: { files: Array<{ path: string; title?: string; content?: string; status?: \"current\" | \"stale\" | \"missing\" }>; title?: string }\n  - type:\"text\" → value: string\n  - type:\"heading\" → value: string\n  - type:\"paragraph\" → value: string\n  - type:\"separator\" → value: undefined\n  - type:\"actions\" → value: Array<{ type: string; id: string; label: string; variant?: string; options?: Array<string | { label: string; value: string }> }>";
-
-export const BLOCK_DOCS_BY_SKILL = {
-  "present": "| Type | Description | Value Shape |\n|------|-------------|-------------|\n| `markdown` | Markdown content rendered with the marked parser. | `string` |\n| `code` | Formatted code block rendered inside pre/code tags. | `string` |\n| `mermaid` | Mermaid diagram source rendered in a mermaid pre block. | `string` |\n| `table` | Tabular data rendered from records or explicit headers and rows. | `Record<string, unknown>[] | { headers: string[]; rows: unknown[][] }` |\n| `metrics` | Metric cards showing label/value pairs with optional trend and status. | `Array<{ label: string; value: string | number; trend?: string | number; status?: string }>` |\n| `cards` | Card grid for titled items with optional body, badge, and status. | `Array<{ title: string; body?: string; badge?: string; status?: string; description?: string }>` |\n| `tree` | Hierarchical object or name/children tree rendered recursively. | `{ name: string; children?: unknown[] } | Record<string, unknown>` |\n| `graph` | Node and edge graph rendered as a Mermaid flow graph in HTML mode. | `{ nodes: Array<{ id: string; label?: string }>; edges: Array<{ from: string; to: string; label?: string }> }` |\n| `chart` | Structured chart definition rendered as SVG. | `{ chartType: string; data: Record<string, unknown>[]; xKey: string; yKeys: string[] }` |\n| `timeline` | Timeline entries rendered as a vertical sequence of events. | `Array<{ title: string; description?: string; timestamp?: string; status?: string }>` |\n| `checklist` | Checklist items with boolean checked state. | `Array<{label, checked}> | {items: Array<{label, checked}>}` |\n| `comparison` | Side-by-side comparison columns with titled item lists. | `Array<{title, items}> | {columns: Array<{title, items}>}` |\n| `status-board` | Status categories containing labeled status items. | `Array<{category, items}> | {items: Array<{category, items}>}` |\n| `prompt` | Prompt payload rendered through the prompt display helper. | `unknown` |\n| `progress` | Progress bar with current value and optional maximum. | `{label, value, max?} | {items: Array<{label, value, max?, color?}>}` |\n| `docs-browser` | Documentation file list with inline content previews for chat-safe rendering. | `{ files: Array<{ path: string; title?: string; content?: string; status?: \"current\" | \"stale\" | \"missing\" }>; title?: string }` |\n\n### Usage Examples\n\n#### `docs-browser`\n\n```typescript\n{\n  type: 'docs-browser',\n  value: {\n    title: 'Project Docs',\n    files: [\n      { path: 'docs/README.md', title: 'Overview', status: 'current' },\n      { path: 'docs/api.md', title: 'API Reference', status: 'stale' },\n    ],\n  },\n}\n```",
-  "docs": "| Type | Description | Value Shape |\n|------|-------------|-------------|\n| `markdown` | Markdown content rendered with the marked parser. | `string` |\n| `code` | Formatted code block rendered inside pre/code tags. | `string` |\n| `mermaid` | Mermaid diagram source rendered in a mermaid pre block. | `string` |\n| `table` | Tabular data rendered from records or explicit headers and rows. | `Record<string, unknown>[] | { headers: string[]; rows: unknown[][] }` |\n| `cards` | Card grid for titled items with optional body, badge, and status. | `Array<{ title: string; body?: string; badge?: string; status?: string; description?: string }>` |\n| `docs-browser` | Documentation file list with inline content previews for chat-safe rendering. | `{ files: Array<{ path: string; title?: string; content?: string; status?: \"current\" | \"stale\" | \"missing\" }>; title?: string }` |\n\n### Usage Examples\n\n#### `docs-browser`\n\n```typescript\n{\n  type: 'docs-browser',\n  value: {\n    title: 'Project Docs',\n    files: [\n      { path: 'docs/README.md', title: 'Overview', status: 'current' },\n      { path: 'docs/api.md', title: 'API Reference', status: 'stale' },\n    ],\n  },\n}\n```",
-  "c4-architecture": "| Type | Description | Value Shape |\n|------|-------------|-------------|\n| `mermaid` | Mermaid diagram source rendered in a mermaid pre block. | `string` |\n| `graph` | Node and edge graph rendered as a Mermaid flow graph in HTML mode. | `{ nodes: Array<{ id: string; label?: string }>; edges: Array<{ from: string; to: string; label?: string }> }` |"
-};