feat: add Gleam syntax highlighting support

.github/workflows/docs-update.yml

@@ -2,13 +2,16 @@ name: Docs Update
 
 on:
   schedule:
-    # Run every 4 hours
-    - cron: "0 */4 * * *"
-  workflow_dispatch: # Allow manual trigger for testing
+    - cron: "0 */12 * * *"
+  workflow_dispatch:
+
+env:
+  LOOKBACK_HOURS: 4
 
 jobs:
   update-docs:
-    runs-on: ubuntu-latest
+    if: github.repository == 'sst/opencode'
+    runs-on: blacksmith-4vcpu-ubuntu-2404
     permissions:
       id-token: write
       contents: write
@@ -19,12 +22,15 @@ jobs:
         with:
           fetch-depth: 0 # Fetch full history to access commits
 
+      - name: Setup Bun
+        uses: ./.github/actions/setup-bun
+
       - name: Get recent commits
         id: commits
         run: |
-          COMMITS=$(git log --since="4 hours ago" --pretty=format:"- %h %s" 2>/dev/null || echo "")
+          COMMITS=$(git log --since="${{ env.LOOKBACK_HOURS }} hours ago" --pretty=format:"- %h %s" 2>/dev/null || echo "")
           if [ -z "$COMMITS" ]; then
-            echo "No commits in the last 4 hours"
+            echo "No commits in the last ${{ env.LOOKBACK_HOURS }} hours"
             echo "has_commits=false" >> $GITHUB_OUTPUT
           else
             echo "has_commits=true" >> $GITHUB_OUTPUT
@@ -44,7 +50,7 @@ jobs:
           model: opencode/gpt-5.2
           agent: docs
           prompt: |
-            Review the following commits from the last 4 hours and identify any new features that may need documentation.
+            Review the following commits from the last ${{ env.LOOKBACK_HOURS }} hours and identify any new features that may need documentation.
 
             <recent_commits>
             ${{ steps.commits.outputs.list }}
@@ -62,4 +68,5 @@ jobs:
             4. If you are creating a new documentation file be sure to update packages/web/astro.config.mjs too.
 
             Focus on user-facing features and API changes. Skip internal refactors, bug fixes, and test updates unless they affect user-facing behavior.
-            All doc related commits should start with "docs:" prefix.
+            Don't feel the need to document every little thing. It is perfectly okay to make 0 changes at all.
+            Try to keep documentation only for large features or changes that already have a good spot to be documented.

.github/workflows/publish.yml

@@ -151,12 +151,12 @@ jobs:
 
       - uses: Swatinem/rust-cache@v2
         with:
-          workspaces: packages/tauri/src-tauri
+          workspaces: packages/desktop/src-tauri
           shared-key: ${{ matrix.settings.target }}
 
       - name: Prepare
         run: |
-          cd packages/tauri
+          cd packages/desktop
           bun ./scripts/prepare.ts
         env:
           OPENCODE_VERSION: ${{ needs.publish.outputs.version }}
@@ -191,7 +191,7 @@ jobs:
           APPLE_API_KEY: ${{ secrets.APPLE_API_KEY }}
           APPLE_API_KEY_PATH: ${{ runner.temp }}/apple-api-key.p8
         with:
-          projectPath: packages/tauri
+          projectPath: packages/desktop
           uploadWorkflowArtifacts: true
           tauriScript: ${{ (contains(matrix.settings.host, 'ubuntu') && 'cargo tauri') || '' }}
           args: --target ${{ matrix.settings.target }} --config ./src-tauri/tauri.prod.conf.json --verbose

.github/workflows/review.yml

@@ -64,7 +64,7 @@ jobs:
           Please check all the code changes in this pull request against the style guide, also look for any bugs if they exist. Diffs are important but make sure you read the entire file to get proper context. Make it clear the suggestions are merely suggestions and the human can decide what to do
 
           When critiquing code against the style guide, be sure that the code is ACTUALLY in violation, don't complain about else statements if they already use early returns there. You may complain about excessive nesting though, regardless of else statement usage.
-          When critiquing code style don't be a zealot, we don't like "let" statements but sometimes they are the simpliest option, if someone does a bunch of nesting with let, they should consider using iife (see packages/opencode/src/util.iife.ts)
+          When critiquing code style don't be a zealot, we don't like "let" statements but sometimes they are the simplest option, if someone does a bunch of nesting with let, they should consider using iife (see packages/opencode/src/util.iife.ts)
 
           Use the gh cli to create comments on the files for the violations. Try to leave the comment on the exact line number. If you have a suggested fix include it in a suggestion code block.
           If you are writing suggested fixes, BE SURE THAT the change you are recommending is actually valid typescript, often I have seen missing closing "}" or other syntax errors.

.github/workflows/stale-issues.yml

@@ -0,0 +1,33 @@
+name: "Auto-close stale issues"
+
+on:
+  schedule:
+    - cron: "30 1 * * *" # Daily at 1:30 AM
+  workflow_dispatch:
+
+env:
+  DAYS_BEFORE_STALE: 90
+  DAYS_BEFORE_CLOSE: 7
+
+jobs:
+  stale:
+    runs-on: ubuntu-latest
+    permissions:
+      issues: write
+    steps:
+      - uses: actions/stale@v10
+        with:
+          days-before-stale: ${{ env.DAYS_BEFORE_STALE }}
+          days-before-close: ${{ env.DAYS_BEFORE_CLOSE }}
+          stale-issue-label: "stale"
+          close-issue-message: |
+            [automated] Closing due to ${{ env.DAYS_BEFORE_STALE }}+ days of inactivity.
+
+            Feel free to reopen if you still need this!
+          stale-issue-message: |
+            [automated] This issue has had no activity for ${{ env.DAYS_BEFORE_STALE }} days.
+
+            It will be closed in ${{ env.DAYS_BEFORE_CLOSE }} days if there's no new activity.
+          remove-stale-when-updated: true
+          exempt-issue-labels: "pinned,security,feature-request,on-hold"
+          start-date: "2025-12-27"

.github/workflows/sync-zed-extension.yml

@@ -2,8 +2,8 @@ name: "sync-zed-extension"
 
 on:
   workflow_dispatch:
-  # release:
-  #   types: [published]
+  release:
+    types: [published]
 
 jobs:
   zed:
@@ -31,4 +31,4 @@ jobs:
         run: |
           ./script/sync-zed.ts ${{ steps.get_tag.outputs.tag }}
         env:
-          GITHUB_TOKEN: ${{ secrets.SST_GITHUB_TOKEN }}
+          ZED_EXTENSIONS_PAT: ${{ secrets.ZED_EXTENSIONS_PAT }}

.gitignore

@@ -20,3 +20,7 @@ opencode.json
 a.out
 target
 .scripts
+
+# Local dev files
+opencode-dev
+logs/

.opencode/agent/docs.md

@@ -1,11 +1,14 @@
 ---
 description: ALWAYS use this when writing docs
+color: "#38A3EE"
 ---
 
 You are an expert technical documentation writer
 
 You are not verbose
 
+Use a relaxed and friendly tone
+
 The title of the page should be a word or a 2-3 word phrase
 
 The description should be one short line, should not start with "The", should

.opencode/agent/triage.md

@@ -2,6 +2,7 @@
 mode: primary
 hidden: true
 model: opencode/claude-haiku-4-5
+color: "#44BA81"
 tools:
   "*": false
   "github-triage": true

.opencode/skill/test-skill/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: test-skill
+description: use this when asked to test skill
+---
+
+woah this is a test skill

AGENTS.md

@@ -4,31 +4,4 @@
 
 ## Tool Calling
 
-- ALWAYS USE PARALLEL TOOLS WHEN APPLICABLE. Here is an example illustrating how to execute 3 parallel file reads in this chat environment:
-
-json
-{
-"recipient_name": "multi_tool_use.parallel",
-"parameters": {
-"tool_uses": [
-{
-"recipient_name": "functions.read",
-"parameters": {
-"filePath": "path/to/file.tsx"
-}
-},
-{
-"recipient_name": "functions.read",
-"parameters": {
-"filePath": "path/to/file.ts"
-}
-},
-{
-"recipient_name": "functions.read",
-"parameters": {
-"filePath": "path/to/file.md"
-}
-}
-]
-}
-}
+- ALWAYS USE PARALLEL TOOLS WHEN APPLICABLE.

CONTRIBUTING.md

@@ -53,12 +53,12 @@ your debugger via that URL. Other methods can result in breakpoints being mapped
 
 Caveats:
 
-- `*.tsx` files won't have their breakpoints correctly mapped. This seems due to Bun currently not supporting source maps on code transformed
-  via `BunPlugin`s (currently necessary due to our dependency on `@opentui/solid`). Currently, the best you can do in terms of debugging `*.tsx`
-  files is writing a `debugger;` statement. Debugging facilities like stepping won't work, but at least you will be informed if a specific code
-  is triggered.
 - If you want to run the OpenCode TUI and have breakpoints triggered in the server code, you might need to run `bun dev spawn` instead of
   the usual `bun dev`. This is because `bun dev` runs the server in a worker thread and breakpoints might not work there.
+- If `spawn` does not work for you, you can debug the server separately:
+  - Debug server: `bun run --inspect=ws://localhost:6499/ ./src/index.ts serve --port 4096`,
+    then attach TUI with `opencode attach http://localhost:4096`
+  - Debug TUI: `bun run --inspect=ws://localhost:6499/ --conditions=browser ./src/index.ts`
 
 Other tips and tricks:
 

README.md

@@ -79,7 +79,7 @@ you can switch between these using the `Tab` key.
   - Asks permission before running bash commands
   - Ideal for exploring unfamiliar codebases or planning changes
 
-Also, included is a **general** subagent for complex searches and multi-step tasks.
+Also, included is a **general** subagent for complex searches and multistep tasks.
 This is used internally and can be invoked using `@general` in messages.
 
 Learn more about [agents](https://opencode.ai/docs/agents).
@@ -98,7 +98,7 @@ If you are working on a project that's related to OpenCode and is using "opencod
 
 ### FAQ
 
-#### How is this different than Claude Code?
+#### How is this different from Claude Code?
 
 It's very similar to Claude Code in terms of capability. Here are the key differences:
 

STATS.md

@@ -178,3 +178,10 @@
 | 2025-12-20 | 1,223,000 (+19,515) | 1,146,258 (+16,560) | 2,369,258 (+36,075) |
 | 2025-12-21 | 1,242,675 (+19,675) | 1,158,909 (+12,651) | 2,401,584 (+32,326) |
 | 2025-12-22 | 1,262,522 (+19,847) | 1,169,121 (+10,212) | 2,431,643 (+30,059) |
+| 2025-12-23 | 1,286,548 (+24,026) | 1,186,439 (+17,318) | 2,472,987 (+41,344) |
+| 2025-12-24 | 1,309,323 (+22,775) | 1,203,767 (+17,328) | 2,513,090 (+40,103) |
+| 2025-12-25 | 1,333,032 (+23,709) | 1,217,283 (+13,516) | 2,550,315 (+37,225) |
+| 2025-12-26 | 1,352,411 (+19,379) | 1,227,615 (+10,332) | 2,580,026 (+29,711) |
+| 2025-12-27 | 1,371,771 (+19,360) | 1,238,236 (+10,621) | 2,610,007 (+29,981) |
+| 2025-12-28 | 1,390,388 (+18,617) | 1,245,690 (+7,454)  | 2,636,078 (+26,071) |
+| 2025-12-29 | 1,415,560 (+25,172) | 1,257,101 (+11,411) | 2,672,661 (+36,583) |