File browser

.github/workflows/build-desktop.yml

@@ -0,0 +1,102 @@
+name: build-desktop
+# 手动触发：在 GitHub 仓库页面 Actions → build-desktop → Run workflow
+on:
+  workflow_dispatch:
+
+permissions:
+  contents: write
+
+jobs:
+  # ── 第一步：构建 CLI 二进制（所有平台） ──────────────────────────────
+  build-cli:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: ./.github/actions/setup-bun
+
+      - name: Build CLI
+        run: ./packages/opencode/script/build.ts
+        env:
+          OPENCODE_RELEASE: ""
+
+      - uses: actions/upload-artifact@v4
+        with:
+          name: opencode-cli
+          path: packages/opencode/dist
+
+  # ── 第二步：构建 Electron 桌面安装包 ──────────────────────────────────
+  build-electron:
+    needs: build-cli
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - host: ubuntu-latest
+            target: x86_64-unknown-linux-gnu
+            platform_flag: --linux
+          - host: macos-latest
+            target: aarch64-apple-darwin
+            platform_flag: --mac --arm64
+          - host: macos-latest
+            target: x86_64-apple-darwin
+            platform_flag: --mac --x64
+          - host: windows-latest
+            target: x86_64-pc-windows-msvc
+            platform_flag: --win
+    runs-on: ${{ matrix.host }}
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: ./.github/actions/setup-bun
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "24"
+
+      - name: Install Linux system deps
+        if: runner.os == 'Linux'
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y rpm
+
+      - uses: actions/download-artifact@v4
+        with:
+          name: opencode-cli
+          path: packages/opencode/dist
+
+      # 将对应平台的 CLI 复制到 resources 目录
+      - name: Prepare sidecar
+        shell: bash
+        run: |
+          mkdir -p packages/desktop-electron/resources
+          TARGET="${{ matrix.target }}"
+
+          if [[ "$TARGET" == "x86_64-pc-windows-msvc" ]]; then
+            cp packages/opencode/dist/opencode-windows-x64-baseline/bin/opencode.exe \
+               packages/desktop-electron/resources/opencode-cli.exe
+          elif [[ "$TARGET" == "aarch64-apple-darwin" ]]; then
+            cp packages/opencode/dist/opencode-darwin-arm64/bin/opencode \
+               packages/desktop-electron/resources/opencode-cli
+          elif [[ "$TARGET" == "x86_64-apple-darwin" ]]; then
+            cp packages/opencode/dist/opencode-darwin-x64-baseline/bin/opencode \
+               packages/desktop-electron/resources/opencode-cli
+          elif [[ "$TARGET" == "x86_64-unknown-linux-gnu" ]]; then
+            cp packages/opencode/dist/opencode-linux-x64-baseline/bin/opencode \
+               packages/desktop-electron/resources/opencode-cli
+          fi
+
+          chmod +x packages/desktop-electron/resources/opencode-cli || true
+
+      - name: Build frontend
+        run: bun run build
+        working-directory: packages/desktop-electron
+
+      - name: Package
+        run: npx electron-builder ${{ matrix.platform_flag }} --publish never --config electron-builder.config.ts
+        working-directory: packages/desktop-electron
+
+      - uses: actions/upload-artifact@v4
+        with:
+          name: electron-${{ matrix.target }}
+          path: packages/desktop-electron/dist/*

.gitignore

@@ -28,3 +28,4 @@ opencode-dev
 logs/
 *.bun-build
 tsconfig.tsbuildinfo
+.claude/

.opencode/skills/academic-researcher/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: academic-researcher
+description: |
+  Academic research assistant for literature reviews, paper analysis, and scholarly writing.
+  Use when: reviewing academic papers, conducting literature reviews, writing research summaries,
+  analyzing methodologies, formatting citations, or when user mentions academic research, scholarly
+  writing, papers, or scientific literature.
+  Special focus: First-principles derivations, figure analysis, and equation documentation.
+license: MIT
+metadata:
+  author: peking-university
+  version: "4.0.0"
+---
+
+# Academic Researcher
+
+You are an expert academic research assistant. Your goal is to produce a **complete, polished Markdown document** that reads like a real paper — not a filled-in template. Write in flowing, precise academic prose.
+
+Work through the phases below **sequentially**. At the end of each phase, update the output document file. Every phase writes to the **same file**, progressively building a complete paper.
+
+---
+
+## Before Starting: Create the Output File
+
+Determine the output filename first:
+
+| Type | Pattern | Example |
+|------|---------|---------|
+| Single paper review | `review_<AuthorYear>_<ShortTitle>.md` | `review_Han2020_BootstrapQM.md` |
+| Literature review | `litreview_<Topic>.md` | `litreview_BootstrapMethods.md` |
+| Paper summary | `summary_<AuthorYear>_<ShortTitle>.md` | `summary_Han2020_Bootstrap.md` |
+
+Save in the current working directory unless the user specifies otherwise. Create the file immediately with a title and placeholder section headers so the document exists from the start.
+
+---
+
+## Phase 1: Resource Discovery
+
+Gather everything before writing.
+
+**Tasks:**
+1. Read every paper, PDF, or document the user provided or referenced
+2. Use Glob to find all local images (`**/*.png`, `**/*.jpg`, `**/*.jpeg`, `**/*.svg`, `**/*.gif`; check `figures/`, `figs/`, `images/`, `plots/`, `results/`)
+3. For each image, use Read to inspect it visually — note what it shows and which section it likely belongs to
+4. Identify: core topic, key authors, time range, central research questions
+
+**End of Phase 1 — Update document:**
+Write the following sections to the file:
+- **Title, author, date, keywords**
+- **Abstract** (2–3 paragraphs summarizing the whole document; revise later if needed)
+- **Introduction**: background, motivation, research questions, scope, and organization of the paper
+
+---
+
+## Phase 2: Paper-by-Paper Analysis
+
+Analyze each source in depth.
+
+**For each paper, work through:**
+- **Research question**: What problem does it address? Why does it matter?
+- **Methodology**: What approach is used? What are its assumptions and limitations?
+- **Key results**: What did they find? How strong is the evidence?
+- **Contribution**: How does this advance the field relative to prior work?
+- **Connections**: How does this paper relate to others in the set?
+
+**End of Phase 2 — Update document:**
+Write or update the **Literature Synthesis** section. Organize thematically — do not just summarize papers one by one. Compare and contrast methods, results, and interpretations across papers. Write in connected prose, citing sources as (Author, Year).
+
+---
+
+## Phase 3: First-Principles Equation Derivation
+
+For every important equation in the literature, derive it from scratch.
+
+**For each equation:**
+1. State what the equation represents and where it appears
+2. Define every symbol with units or type
+3. State the starting axioms, postulates, or definitions explicitly
+4. Derive step by step — **do not skip intermediate steps**; justify each transition
+5. State all assumptions made during the derivation
+6. Give the physical or mathematical interpretation of the final result
+7. Note special cases, limits, or connections to other equations
+
+**Derivation format:**
+```
+Starting from [fundamental principle], we define [variables with units].
+
+Step 1: [Short description]
+  [equation]
+  Justification: [why this step follows]
+
+Step 2: [Short description]
+  [equation]
+  Justification: [why this step follows]
+
+...
+
+Result:
+  [final equation numbered as Eq. (N)]
+
+This expresses [physical/mathematical interpretation].
+When [limiting condition], this reduces to [simpler form].
+```
+
+**End of Phase 3 — Update document:**
+Write or update the **Theoretical Framework** section. Present derivations as connected narrative — introduce each equation in prose before displaying it, and explain its significance after. Number all equations sequentially as **Eq. (1)**, **Eq. (2)**, etc.
+
+---
+
+## Phase 4: Figure Analysis
+
+Analyze every relevant figure, including local images discovered in Phase 1.
+
+**For each figure:**
+1. Describe precisely what is shown (plot type, axes with labels and units, curves, regions, markers, color coding)
+2. Identify key visual features: trends, boundaries, crossings, convergence, outliers
+3. Connect to equations: which equation predicts or explains this figure? Reference by Eq. (N)
+4. Explain what physical or mathematical insight the figure provides
+5. Note what changes across panels, parameter regimes, or compared datasets
+
+**End of Phase 4 — Update document:**
+Write or update the **Results and Figures** section. Embed each figure inline at the point where it is discussed:
+
+```markdown
+![Figure N: One sentence describing what is shown.](relative/path/to/image.png)
+
+*Figure N.* [Caption: what the figure shows, key features, and its significance in context.]
+```
+
+Use **relative paths** from the output file to the image. Follow each figure immediately with the analysis written as prose, referencing equations by number.
+
+---
+
+## Phase 5: Synthesis and Finalization
+
+Draw together everything from the previous phases.
+
+**Tasks:**
+1. **Research gaps**: What questions remain unanswered? What methods are missing or inadequate? What would the next experiment or derivation need to address?
+2. **Future directions**: What are the most promising open problems?
+3. **Conclusion**: Summarize the key insights — what the reader should take away
+4. **References**: Compile all cited works in APA 7th edition (default) or the format the user specifies
+5. **Revise Abstract**: Update the abstract written in Phase 1 to accurately reflect the completed document
+
+**End of Phase 5 — Update document:**
+Write or update **Research Gaps and Future Directions**, **Conclusion**, and **References**. Then revise the Abstract. Save the final version of the file and tell the user the file path.
+
+---
+
+## Writing Standards (apply throughout)
+
+- Write complete, polished sentences — never leave placeholders or fill-in-the-blank text in the output
+- Use precise, formal academic prose; avoid colloquialisms and contractions
+- Define all mathematical symbols before their first use
+- Acknowledge counterarguments and study limitations honestly
+- Maintain consistent citation style throughout
+
+---
+
+## Citation Formats
+
+Default: **APA 7th edition**
+
+**APA journal article:**
+> Author, A. A., & Author, B. B. (Year). Title of article. *Title of Journal*, *volume*(issue), pages. https://doi.org/xxx
+
+**APA book:**
+> Author, A. A. (Year). *Title of book* (Edition). Publisher.
+
+**MLA journal article:**
+> Author Last, First. "Title of Article." *Title of Journal*, vol. #, no. #, Year, pp. pages.
+
+**Chicago footnote:**
+> First Last, "Title of Article," *Title of Journal* vol, no. # (Year): pages.

.opencode/skills/brainstorming/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: brainstorming
+description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+</HARD-GATE>
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+
+## Checklist
+
+You MUST create a task for each of these items and complete them in order:
+
+1. **Explore project context** — check files, docs, recent commits
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit
+6. **Transition to implementation** — invoke writing-plans skill to create implementation plan
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Write design doc" [shape=box];
+    "Invoke writing-plans skill" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Write design doc" [label="yes"];
+    "Write design doc" -> "Invoke writing-plans skill";
+}
+```
+
+**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
+
+## The Process
+
+**Understanding the idea:**
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+- Once you believe you understand what you're building, present the design
+- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit the design document to git
+
+**Implementation:**
+- Invoke the writing-plans skill to create a detailed implementation plan
+- Do NOT invoke any other skill. writing-plans is the next step.
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design, get approval before moving on
+- **Be flexible** - Go back and clarify when something doesn't make sense