feat: 品牌替换 + 启动优化 + AGENTS.md 模板定制

- 品牌替换：OpenCode/opencode → AirCoding/aircoding（16+ 文件）
- Logo ASCII art：修复 left/right 行数不匹配导致的启动崩溃
- 启动诊断：添加 OPENCODE_PRINT_TIMING 计时探针
- dev 模式默认 --pure 跳过外部插件加载
- AGENTS.md 模板：追加 AirCoding 多 Agent 专项段落
- architect prompt + plugin：强化 AGENTS.md 产出验证

.opencode/command/ai-deps.md

@@ -0,0 +1,24 @@
+---
+description: "Bump AI sdk dependencies minor / patch versions only"
+---
+
+Please read @package.json and @packages/opencode/package.json.
+
+Your job is to look into AI SDK dependencies, figure out if they have versions that can be upgraded (minor or patch versions ONLY no major ignore major changes).
+
+I want a report of every dependency and the version that can be upgraded to.
+What would be even better is if you can give me brief summary of the changes for each dep and a link to the changelog for each dependency, or at least some reference info so I can see what bugs were fixed or new features were added.
+
+Consider using subagents for each dep to save your context window.
+
+Here is a short list of some deps (please be comprehensive tho):
+
+- "ai"
+- "@ai-sdk/openai"
+- "@ai-sdk/anthropic"
+- "@openrouter/ai-sdk-provider"
+- etc, etc
+
+DO NOT upgrade the dependencies yet, just make a list of all dependencies and their versions that can be upgraded to minor or patch versions only.
+
+Write up your findings to ai-sdk-updates.md

.opencode/command/changelog.md

@@ -0,0 +1,49 @@
+---
+model: opencode/gpt-5.4
+---
+
+Create `UPCOMING_CHANGELOG.md` from the structured changelog input below.
+If `UPCOMING_CHANGELOG.md` already exists, ignore its current contents completely.
+Do not preserve, merge, or reuse text from the existing file.
+
+The input already contains the exact commit range since the last non-draft release.
+The commits are already filtered to the release-relevant packages and grouped into
+the release sections. Do not fetch GitHub releases, PRs, or build your own commit list.
+The input may also include a `## Community Contributors Input` section.
+
+Before writing any entry you keep, inspect the real diff with
+`git show --stat --format='' <hash>` or `git show --format='' <hash>` so you can
+understand the actual code changes and not just the commit message (they may be misleading).
+Do not use `git log` or author metadata when deciding attribution.
+
+Rules:
+
+- Write the final file with release sections in this order:
+  `## Core`, `## TUI`, `## Desktop`, `## SDK`, `## Extensions`
+- Only include sections that have at least one notable entry
+- Within each release section, keep bug fixes grouped under `### Bugfixes`
+- Keep other notable entries under `### Improvements` when a section has bug fixes too
+- Omit empty subsections
+- Keep one bullet per commit you keep
+- Skip commits that are entirely internal, CI, tests, refactors, or otherwise not user-facing
+- Start each bullet with a capital letter
+- Prefer what changed for users over what code changed internally
+- Do not copy raw commit prefixes like `fix:` or `feat:` or trailing PR numbers like `(#123)`
+- Community attribution is deterministic: only preserve an existing `(@username)` suffix from the changelog input
+- If an input bullet has no `(@username)` suffix, do not add one
+- Never add a new `(@username)` suffix from `git show`, commit authors, names, or email addresses
+- If no notable entries remain and there is no contributor block, write exactly `No notable changes.`
+- If no notable entries remain but there is a contributor block, omit all release sections and return only the contributor block
+- If the input contains `## Community Contributors Input`, append the block below that heading to the end of the final file verbatim
+- Do not add, remove, rewrite, or reorder contributor names or commit titles in that block
+- Do not derive the thank-you section from the main summary bullets
+- Do not include the heading `## Community Contributors Input` in the final file
+- Focus on writing the least words to get your point across - users will skim read the changelog, so we should be precise
+
+**Importantly, the changelog is for users (who are at least slightly technical), they may use the TUI, Desktop, SDK, Plugins and so forth. Be thorough in understanding flow on effects may not be immediately apparent. e.g. a package upgrade looks internal but may patch a bug. Or a refactor may also stabilise some race condition that fixes bugs for users. The PR title/body + commit message will give you the authors context, usually containing the outcome not just technical detail**
+
+<changelog_input>
+
+!`bun script/raw-changelog.ts $ARGUMENTS`
+
+</changelog_input>

.opencode/command/commit.md

@@ -0,0 +1,37 @@
+---
+description: git commit and push
+model: opencode/kimi-k2.5
+subtask: true
+---
+
+commit and push
+
+make sure it includes a prefix like
+docs:
+tui:
+core:
+ci:
+ignore:
+wip:
+
+For anything in the packages/web use the docs: prefix.
+
+prefer to explain WHY something was done from an end user perspective instead of
+WHAT was done.
+
+do not do generic messages like "improved agent experience" be very specific
+about what user facing changes were made
+
+if there are conflicts DO NOT FIX THEM. notify me and I will fix them
+
+## GIT DIFF
+
+!`git diff`
+
+## GIT DIFF --cached
+
+!`git diff --cached`
+
+## GIT STATUS --short
+
+!`git status --short`

.opencode/command/issues.md

@@ -0,0 +1,23 @@
+---
+description: "find issue(s) on github"
+model: opencode/claude-haiku-4-5
+---
+
+Search through existing issues in anomalyco/opencode using the gh cli to find issues matching this query:
+
+$ARGUMENTS
+
+Consider:
+
+1. Similar titles or descriptions
+2. Same error messages or symptoms
+3. Related functionality or components
+4. Similar feature requests
+
+Please list any matching issues with:
+
+- Issue number and title
+- Brief explanation of why it matches the query
+- Link to the issue
+
+If no clear matches are found, say so.

.opencode/command/learn.md

@@ -0,0 +1,42 @@
+---
+description: Extract non-obvious learnings from session to AGENTS.md files to build codebase understanding
+---
+
+Analyze this session and extract non-obvious learnings to add to AGENTS.md files.
+
+AGENTS.md files can exist at any directory level, not just the project root. When an agent reads a file, any AGENTS.md in parent directories are automatically loaded into the context of the tool read. Place learnings as close to the relevant code as possible:
+
+- Project-wide learnings → root AGENTS.md
+- Package/module-specific → packages/foo/AGENTS.md
+- Feature-specific → src/auth/AGENTS.md
+
+What counts as a learning (non-obvious discoveries only):
+
+- Hidden relationships between files or modules
+- Execution paths that differ from how code appears
+- Non-obvious configuration, env vars, or flags
+- Debugging breakthroughs when error messages were misleading
+- API/tool quirks and workarounds
+- Build/test commands not in README
+- Architectural decisions and constraints
+- Files that must change together
+
+What NOT to include:
+
+- Obvious facts from documentation
+- Standard language/framework behavior
+- Things already in an AGENTS.md
+- Verbose explanations
+- Session-specific details
+
+Process:
+
+1. Review session for discoveries, errors that took multiple attempts, unexpected connections
+2. Determine scope - what directory does each learning apply to?
+3. Read existing AGENTS.md files at relevant levels
+4. Create or update AGENTS.md at the appropriate level
+5. Keep entries to 1-3 lines per insight
+
+After updating, summarize which AGENTS.md files were created/updated and how many learnings per file.
+
+$ARGUMENTS

.opencode/command/rmslop.md

@@ -0,0 +1,15 @@
+---
+description: Remove AI code slop
+---
+
+Check the diff against dev, and remove all AI generated slop introduced in this branch.
+
+This includes:
+
+- Extra comments that a human wouldn't add or is inconsistent with the rest of the file
+- Extra defensive checks or try/catch blocks that are abnormal for that area of the codebase (especially if called by trusted / validated codepaths)
+- Casts to any to get around type issues
+- Any other style that is inconsistent with the file
+- Unnecessary emoji usage
+
+Report at the end with only a 1-3 sentence summary of what you changed

.opencode/command/spellcheck.md

@@ -0,0 +1,5 @@
+---
+description: spellcheck all markdown file changes
+---
+
+Look at all the unstaged changes to markdown (.md, .mdx) files, pull out the lines that have changed, and check for spelling and grammar errors.

.opencode/command/translate.md

@@ -0,0 +1,14 @@
+---
+description: translate English to other languages
+model: opencode/claude-opus-4-8
+---
+
+run git diff and translate changed english doc and UI copy files to other international languages. Translate all languages in parallel to save time.
+
+Requirements:
+
+- Preserve meaning, intent, tone, and formatting (including Markdown/MDX structure).
+- Preserve all technical terms and artifacts exactly: product/company names, API names, identifiers, code, commands/flags, file paths, URLs, versions, error messages, config keys/values, and anything inside inline code or code blocks.
+- Also preserve every term listed in the Do-Not-Translate glossary below.
+- Also apply locale-specific guidance from `.opencode/glossary/<locale>.md` when available (for example, `zh-cn.md`).
+- Do not modify fenced code blocks.