菜单
Analyzes the project codebase, documentation, and memory to identify the single highest-priority task to work on right now. Triggers on phrases like "Hey, what are we going to do today, Brain?", "What should I work on?", "What's next?", or any request for task prioritization.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | vibe-brain |
| description | Analyzes the project codebase, documentation, and memory to identify the single highest-priority task to work on right now. Triggers on phrases like "Hey, what are we going to do today, Brain?", "What should I work on?", "What's next?", or any request for task prioritization. |
When invoked, do a thorough four-phase analysis and return exactly ONE task: the most impactful thing to do right now, explained conversationally.
Invoke this skill when the user says any of:
Do all of the following in parallel where possible. You are gathering raw material, not analyzing yet.
ls -la, tree -L 2 if available)package.json, Cargo.toml, go.mod, pyproject.toml, Makefile, etc.@deprecated, DEPRECATED, BROKEN annotationsit.skip, test.skip, xtest, #[ignore], t.Skip, pytest.mark.skip// eslint-disable, # type: ignore, noqa — signs of deferred cleanupgit log --oneline --since="2 weeks ago" --name-onlyREADME.md, AGENTS.md, SECURITY.md, CONTRIBUTING.md, DEVELOPMENT.md, ARCHITECTURE.md, etcdocs/ or project-level specs, ADRs, or decision logsFrom the gathered context, build a mental list of candidate tasks. Look for:
| Signal | What it means |
|---|---|
| TODO / FIXME | Explicitly deferred work — the developer already knew it needed doing |
| Skipped test | A test that was disabled but not deleted — likely a known bug or incomplete feature |
| Empty error handler | Swallowed errors hiding real problems |
| High-churn file | Volatile code — may be unstable, under active development, or poorly designed |
| Missing tests | Untested critical paths — high risk |
| Documentation gap | Docs that reference non-existent files, outdated commands, or missing sections |
| Recent unfinished commit | A commit message like "WIP", "tmp", "checkpoint" — interrupted work |
| Open TODO in roadmap | Planned work from specs/roadmap that hasn't been started |
| Dependency warning | Deprecated APIs, security advisories, pinned outdated versions |
Score each candidate on three axes:
Tiebreakers (in order):
Pick exactly ONE task. Do not present a list of options. Commit to the single best choice.
Present the task in a natural, conversational brief. Structure it like this:
**Opening line (MANDATORY — always the very first sentence):**
"The same thing we do every night: try to take over the world…"
(Localize this phrase to match the user's language — see translations below.)
[Warm opening — acknowledge the project state if relevant, then transition to the task]
Here's what I'd tackle: **[One-line task name]**
[2-4 sentences explaining:
- What the task is, concretely
- Why it's the top priority right now (cite specific evidence you found)
- What makes it actionable]
[One sentence on how to start — the very first step]
[Optional: one sentence flagging a risk or dependency to watch out for]
Always use the localized version matching the user's language. This line MUST appear as the very first sentence of the response, verbatim:
| User language | Opening line |
|---|---|
| English | The same thing we do every night: try to take over the world… |
| Russian | Тем же, чем и всегда: попробуем завоевать мир… |
| Spanish | Lo mismo que hacemos todas las noches: ¡intentar conquistar el mundo! |
| French | La même chose que chaque nuit : essayer de conquérir le monde… |
| German | Dasselbe wie jeden Abend: Wir versuchen, die Weltherrschaft an uns zu reißen! |
| Chinese | 和每天晚上一样：试着征服世界… |
| Japanese | 毎晩同じさ：世界征服を企むのさ… |
| Korean | 매일 밤 똑같은 일이지: 세계 정복을 시도하는 거야… |
| Portuguese | A mesma coisa de todas as noites: tentar dominar o mundo… |
| Italian | La stessa cosa che facciamo ogni notte: provare a conquistare il mondo… |
| Ukrainian | Те саме, що й щоночі: спробуємо завоювати світ… |
| Other | Translate using this template: convey the Pinky and the Brain quote naturally — "the same thing we do every night: try to take over the world…" |
English request → English response:
The same thing we do every night: try to take over the world…
Alright, I've looked through the project. We're in a Go service with
gqlgen—go.modis clean, tests pass, but there's a pattern that caught my eye.Here's what I'd tackle: Fix swallowed errors in
internal/resolver/mutation.go.Four mutation handlers have bare
_ = errassignments where database write errors are silently dropped. This means failed writes return success to clients — a data-integrity issue waiting to surface in production. Two of those handlers (CreateUser,UpdateProfile) are on the critical auth path. The fix is well-bounded: add proper error wrapping and return codes in exactly those four functions, then add a table-driven test for each error path.Start by reading
internal/resolver/mutation.golines 42–118 to see the four affected handlers, then pickCreateUserfirst since it's the simplest.Worth noting: the
UpdateProfilehandler also touches the caching layer, so you'll want to decide whether a write error should invalidate the cache or leave it.
Russian request → Russian response:
Тем же, чем и всегда: попробуем завоевать мир…
Так, я посмотрел проект. У нас Go-сервис на
gqlgen—go.modв порядке, тесты проходят, но кое-что бросилось в глаза.Вот чем стоит заняться: Исправить проглоченные ошибки в
internal/resolver/mutation.go.В четырёх обработчиках мутаций ошибки записи в БД просто затираются через
_ = err. Это значит, что неудачная запись возвращает клиенту успех — бомба замедленного действия для целостности данных. Два обработчика (CreateUser,UpdateProfile) на критичном пути аутентификации. Задача чётко ограничена: обернуть ошибки и вернуть правильные коды ровно в этих четырёх функциях, а затем покрыть каждый ошибочный сценарий table-driven тестом.Начни с чтения
internal/resolver/mutation.go, строки 42–118 — там все четыре обработчика.CreateUserпроще всего, с него и стартуй.Имей в виду:
UpdateProfileзадевает ещё и слой кеширования, так что стоит сразу решить, должен ли сбой записи инвалидировать кеш или оставлять его нетронутым.
Hello World running."Explore → Plan → Implement. A thinking partner for exploring ideas, investigating problems, and clarifying requirements, that transitions into a structured roadmap specification (tasks in What/How/Where/Acceptance criteria format) for user approval, then implements the approved plan. Use when the user wants to think through something before a change, when requirements are unclear, or when discussing architecture and design decisions.
Comprehensive code review methodology for evaluating code changes. Identifies bugs, logic errors, security issues, structural problems, performance concerns, and unintended behavior changes. Use when reviewing uncommitted changes, specific commits, branch comparisons, or pull requests.
Removes signs of machine generation from Russian-language AI text, preserving its original register and communicative purpose. Does not turn everything into conversational style — scientific text remains scientific, business text remains business, and conversational remains conversational. Use when you need to remove AI markers from text for publication, bypass AI detectors, or adapt machine output to natural Russian speech in the required register.
Write secure Go applications through everyday development practices — no AppSec expertise required. Covers the 12 OWASP Top 10 categories (2021 & 2025) with idiomatic Go patterns, standard library defaults, recommended libraries, and a security-focused linter setup. Use when writing or reviewing Go backend code, designing Go APIs, configuring production deployments, setting up CI/CD security checks, or hardening existing Go services.
Guides the agent to write well-organized Go code and projects. Use when writing or reviewing Go code involving variable scoping, nested control flow, init functions, getters/setters, interfaces, generics, type embedding, functional options, package structure, utility packages, package naming, code documentation, or linter configuration. Covers the 16 most common code and project organization mistakes in Go.
Guides the agent to avoid foundational concurrency mistakes in Go: confusing concurrency with parallelism, assuming concurrency is always faster, misusing channels vs mutexes, ignoring data races and race conditions, mis-sizing worker pools for CPU- vs I/O-bound work, and misunderstanding Go contexts. Use when writing, reviewing, or refactoring any concurrent Go code, goroutines, channels, mutexes, worker pools, or context usage.