SuperAPI AI Directory
Partner中文AI newsFavorites
Skillssdd-new-session

sdd-new-session

Coding & development

View repository

Updated 10-16 01:14

About this skill

New work front (new-session)

In this skill's first response, start with this line, once only: sdd-new-session v1.0.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

One command, one task, one directory: git worktree + new branch born from the current remote state of the production branch, ready to open in the editor.

Step 0 — Confirm that you can do this

Run git remote -v.

  • If the command does not run (you are in a chat application, without access to the user's computer), stop and say exactly: "I don't have access to your repository — I'm running in the application, not on your machine. For this task you need Claude Code or Codex installed in the terminal, opened in the project folder." Then say the current installation command for the agent you are and where the official documentation is.
  • If it runs, but the folder is not a git repository (git rev-parse --show-toplevel fails), say this and stop without creating anything — the terminal was probably opened in the wrong folder, or the project does not have git yet.

⛔ Do not invent a work front based on assumptions about what the project is like. A work front created from an assumption fails the first time it is used, and the user will not know why. Stopping here is better than delivering something plausible and wrong.

Rule number one: do not ask what you can find out

Investigate and decide. Only ask what is genuinely ambiguous — and then with your recommendation and the reason, so the user only has to confirm. Everything you assume on your own goes into the section ## Suposições of sdd/ambiente.md, where they correct it in one line.

Step 1 — Find out the environment (once per repository)

The main checkout is the first path of git worktree list --porcelain (line worktree …). If <checkout principal>/sdd/ambiente.md, exists, read it and use it — do not rediscover what is already written. If it does not exist, investigate without asking — but, if the task name already came in the request, do before the collision check of Step 2 (item 2): a repeated name aborts without writing anything, not even the sdd/ambiente.md.

git remote show origin
git branch -r
git log --oneline -20
git tag --list
git worktree list

And read, if they exist: README.md, package.json, composer.json, requirements.txt, Makefile, .gitignore, .env.example, .github/workflows/, CLAUDE.md, AGENTS.md.

Extract:

  • Main branch — the "HEAD branch" of git remote show origin. It is not "the branch I am on right now".
  • Preparation — package.json versioned with node_modules in the .gitignore ⇒ npm install in the new folder (otherwise it is born broken). Same logic for requirements.txt, composer.json.
  • Local files outside git — .env in the .gitignore and .env.example versioned ⇒ the new folder needs a copy of the .env from the main checkout.
  • Agent skills outside git — each folder in .claude/skills/ or .agents/skills/ with no versioned file (git ls-files <pasta> empty, folder by folder) ⇒ it must be copied to the work front; without this, the sdd-release does not exist inside it.
  • Editor — the first one that exists from code, cursor, subl (command -v <nome> in bash/zsh, Get-Command <nome> in PowerShell).
  • Branching scenario, based on the repository evidence (criterion from the material "Git na Prática"):
Scenario How to recognize it Strategy The branch ends in
A — continuous delivery, no reviewer No develop/staging on the remote; history of direct commits on the main branch Simplified Trunk-Based direct merge into the main branch
B — delivery via Pull Request History with "Merge pull request #…"; .github/workflows/; more than one author GitHub Flow push of the branch + PR
C — multiple versions in support Version tags and branches release/* or hotfix/* on the remote GitFlow PR to develop (the branch is born from develop)

Always choose the simplest one that works. Tie between A and B ⇒ A (adding a PR later is trivial; removing ceremony that has become habit, is not). C requires the two pieces of evidence; a one-person repository almost never is C — if you concluded C, review it.

Write in <checkout principal>/sdd/ambiente.md (create the folder sdd/ if needed), in this format — one key per line, so the user can correct it by hand:

# Ambiente deste repositório

> Gerado pelas skills sdd-new-session/sdd-release. Está errado? Corrija a linha — as skills leem daqui.

- branch_principal: main
- cenario: A (Trunk-Based) — evidência: <o que você viu, ex.: "20 últimos commits diretos na main, sem develop no remoto">
- pasta_das_frentes: ../<nome-do-repo>-frentes
- editor: code
- preparacao: npm install
- arquivos_locais: .env
- deploy: <preencha só se descobriu; senão "a descobrir pelo sdd-release">
- testes: <comando, se descobriu>
- sintaxe: <comando, se descobriu>
- versionamento: nenhum

## Suposições

- assumi <X> porque <Y>

Do not commit this file: it belongs to the user, who decides whether to version it.

Step 2 — Create the branch

Receive the task name in natural language and, in order:

  1. Slug: lowercase, hyphens, no accents (e.g.: "Relatório mensal" → relatorio-mensal).
  2. Abort if the branch or the folder already exist (git show-ref --verify refs/heads/<slug>, git ls-remote --heads origin <slug>, and the folder <pasta_das_frentes>/<slug>). Do not invent another name: ask the user for another one. Nothing may have been created before this check.
  3. git fetch origin <branch-base> and git worktree add <pasta_das_frentes>/<slug> -b <slug> origin/<branch-base> — from the state remote, not the local one, which may be behind. <branch-base> is the main branch (A, B) or develop (C). Scenario C without origin/develop (git ls-remote --heads origin develop empty)? Stop before creating anything and say: the criterion points to GitFlow, but there is no develop from which the branch can be born.
  4. In the new folder: run the preparation, if there is one.
  5. Copy to the branch what git does not carry: the local files (.env) and each unversioned skill folder, always from the main checkout (absolute paths, in quotes): mkdir -p "<frente>/.claude/skills" && cp -R "<checkout principal>/.claude/skills/<skill>" "<frente>/.claude/skills/", likewise .agents/skills/. Check that <frente>/.claude/skills/sdd-release (or .agents/skills/sdd-release) exists when it exists in the main checkout — without it, the branch cannot be closed. Claude Code asks for approval to write in .claude/: if the copy is denied, do not stop — finish ahead and, in the response, deliver the ready copy command and the option to install the skills once for all projects (npx skills add robertodiasduarte/sdd-starter -a <motor> -g -y).
  6. Open in the editor (code <pasta>). Without an editor, do not abort: the front is already ready; show the path to open by hand.

The folder is outside the repository (../<repo>-frentes/<slug>): inside it, the worktree would appear as an untracked file and would dirty the git status of all the other fronts.

What this skill does NOT do: it does not commit, does not push, does not delete, does not integrate. It only creates. Everything that destroys or publishes is delivered as a command — or is left to the skill sdd-release.

Step 3 — Respond

In this order:

  1. Scenario (A, B or C) with the evidence — what you saw, not "it seems to be".
  2. Path of the folder and branch name.
  3. How to close this front, ready to copy: at the end, use the skill sdd-release from inside the new folder; or, by hand, the scenario's integration command followed by git worktree remove <pasta> and git branch -d <slug>.
  4. Assumptions that you made (if any) and where to correct them (sdd/ambiente.md).
  5. In scenario A, working alone with AI: remember to ask the AI for a code review before integrating — there is no second human looking.
  6. Last line, highlighted: ⚠️ Continue na janela nova. Esta sessão do agente continua presa à pasta onde foi aberta — nenhum cd muda isso. Build, commit e push rodam lá dentro.

Why each rule exists (do not delete without reading)

  • The branch is born from origin/<branch-base> updated (the main one; develop in scenario C) — being born from the current branch inherits work from half of another task, and the new front "already comes with strange code".
  • The same branch does not open in two worktrees — Git refuses. That is why you do not go back to the main one inside the front's folder: you integrate through the scenario's path and update in the main checkout.
  • If another front is integrated before this one, this one was born from a point that no longer exists. Before integrating: git fetch origin + git merge origin/<branch-base> + run the tests again — that is where the conflict between the two appears. (The sdd-release does this.)
  • Worktrees and orphan branches accumulate — after integrating, git worktree remove and git branch -d. The lowercase -d is protection: it only deletes what has already been integrated.
  • The agent session does not migrate — opening the new folder opens another window, but the session where the skill ran stays anchored to the source directory. Without the final warning, the entire front ends up being done in the wrong place and this only shows up at commit time.

Part of SDD Starter by RDD — https://github.com/robertodiasduarte/sdd-starter