Menu
Use when Serena setup, initialization, repair, or use is needed in a repository or worktree
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | using-serena-projects |
| description | Use when Serena setup, initialization, repair, or use is needed in a repository or worktree |
Keep Serena configuration repository-aware: shared configuration belongs to the repository, while worktree identity and other machine-local settings remain local.
Prefer a committed .serena/project.yml plus an ignored .serena/project.local.yml. Inspect and preserve existing configuration before changing or initializing Serena. Do not overwrite repository-owned setup.
When local setup is absent, follow this rule: Infer languages from project manifests. Do not guess unsupported Serena configuration keys; if the available schema or tooling does not establish a valid setting, surface the missing schema or tooling context.
Configure ignore rules for in-repo agent worktrees, external sibling worktrees, dependency directories, caches, generated environments, and Serena runtime state.
Treat nested Git repositories and submodules as separate Serena projects. Never add sibling worktrees as additional workspace folders. Give each worktree a unique local project_name in its ignored local configuration.
Use when handling any Git-backed change and safe task completion. Use when asked to implement a change in a repository and commit clean checkpoints; review a branch or repository for bugs, including review-only work; create commits or checkpoints; push and verify a remote branch; reconcile with an exact lease; integrate or discard a branch; classify or clean up a worktree; or close out Git work. If a repository task says "In Codex" or "In Claude Code," apply in either harness, even when mutation or publication is forbidden. Do not use for Git explanations or pasted summaries without repository action. Owns safe task-only commits, publication, completion choices, and provenance-aware cleanup without publishing non-task work.
Use when leading work from Cursor, Claude Code, or Codex that may need delegation across Cursor, Claude Code, Codex, Spark, browser/computer-use agents, or separate worktrees; deciding what stays local versus handed off; or coordinating multi-agent work.
Use when the user explicitly asks to get a GitHub branch or pull request merged, shipped, over the line, or closed out end to end: "get this merged", "drive it to merge", "ship this PR", "merge and close out this branch", or resume a previously stated merge/closeout workflow. Do not use for single-step PR operations, PR-description-only, review-only, status-only, issue-triage, check-only, CI-check-only, comment-only, ready-only, open-PR-only, draft-PR-only, or publish-only requests unless the user also states a merge or closeout goal. Requests to inspect checks, blockers, readiness, comments, or policy without asking to continue toward merge do not trigger this skill. Requests that say to open a PR, leave it draft, or that the PR is not ready to merge do not trigger this skill.
Use when the operator asks to get a branch, change set, draft PR, or pull request ready for review end to end: "get this PR review-ready", "make this ready for review", "prepare this draft PR for review", "mark ready for review", "tighten then publish for review", or "review-ready yeet". Do not use for review-only, status-only, PR-description-only, draft-PR-only, publish-only, merge, ship, or closeout requests unless the operator also states a ready-for-review outcome.
Use when working with Graphite `gt` stacks: creating or tracking stacked branches, navigating or reparenting a stack, restacking, submitting or updating stacked PRs, fixing Graphite metadata, or diagnosing stack ancestry and publication state.
Use when PR review loops, bot review reruns, CodeRabbit or Greptile cycles, unresolved pull request comments, ready-for-review, mark ready, merge readiness, blocked merges, stale review threads, requested reviewers, branch closeout, merge tasks, docs-only PRs, or skill-only PRs affect a pull request.
