exonous 0.0.0-stage → 2.10.4

package/assets/skills/code-review/SKILL.md

@@ -0,0 +1,124 @@
+---
+description: Code review — local uncommitted/staged changes or GitHub PR (pass PR number/URL for PR mode)
+argument-hint: [pr-number | pr-url | blank for local review]
+model: sonnet
+---
+
+# Code Review
+
+**Input**: $ARGUMENTS
+
+Required by `exonous` `/commit-changes`. Run against the staged or branch diff before committing. Block the commit path if CRITICAL or HIGH findings remain unfixed.
+
+---
+
+## Mode Selection
+
+If `$ARGUMENTS` contains a PR number, PR URL, or `--pr`:
+→ Jump to **PR Review Mode** below.
+
+Otherwise:
+→ Use **Local Review Mode**.
+
+---
+
+## Local Review Mode
+
+### Phase 1 — GATHER
+
+```bash
+git status --short
+git diff --name-only HEAD
+git diff --staged --name-only
+```
+
+Prefer reviewing **staged** changes when present; otherwise review the full working-tree diff vs `HEAD`. If nothing changed, stop: "Nothing to review."
+
+### Phase 2 — REVIEW
+
+Read each changed file (full file when practical; otherwise hunks + surrounding context). Check for:
+
+**Security Issues (CRITICAL):**
+- Hardcoded credentials, API keys, tokens
+- SQL/command injection
+- XSS / unsanitized HTML
+- Missing input validation on trust boundaries
+- Path traversal / unsafe file access
+- Secrets in logs or error messages
+
+**Correctness & Quality (HIGH):**
+- Logic errors, null/edge cases, race conditions
+- Missing error handling
+- Broken TypeScript types / use of `any` where forbidden by project rules
+- Debug leftovers (`console.log`, debugger)
+
+**Best Practices (MEDIUM / LOW):**
+- Missing tests for new business logic
+- Unclear naming, deep nesting, dead code
+- Accessibility issues on UI changes
+
+### Phase 3 — REPORT
+
+Produce a compact report:
+
+| Severity | Location (file:line) | Finding | Suggested fix |
+|----------|----------------------|---------|---------------|
+
+**Decision:**
+- CRITICAL or HIGH → **BLOCK** — fix before `/commit-changes` continues
+- Only MEDIUM/LOW → **PASS** with notes
+- No findings → **PASS**
+
+Never approve code with unresolved CRITICAL/HIGH security or correctness issues.
+
+---
+
+## PR Review Mode
+
+### Phase 1 — FETCH
+
+| Input | Action |
+|---|---|
+| Number (e.g. `42`) | Use as PR number |
+| URL (`github.com/.../pull/42`) | Extract PR number |
+| Branch name | Find PR via `gh pr list --head <branch>` |
+
+```bash
+gh pr view <NUMBER> --json number,title,body,author,baseRefName,headRefName,changedFiles,additions,deletions
+gh pr diff <NUMBER>
+```
+
+### Phase 2 — REVIEW
+
+Read changed files with surrounding context. Apply the same checklist as Local Review Mode, plus:
+
+| Category | What to Check |
+|---|---|
+| **Pattern Compliance** | Matches project conventions |
+| **Completeness** | Tests, docs, migrations |
+| **Performance** | N+1, unbounded loops, large payloads |
+
+### Phase 3 — DECIDE & PUBLISH
+
+| Condition | Decision |
+|---|---|
+| Zero CRITICAL/HIGH | **APPROVE** (or approve with comments) |
+| Any HIGH or validation failures | **REQUEST CHANGES** |
+| Any CRITICAL | **BLOCK** |
+
+If `gh` is available, post with `gh pr review`. If not, report locally only and warn.
+
+### Phase 4 — OUTPUT
+
+```
+PR #<NUMBER>: <TITLE>
+Decision: <APPROVE|REQUEST_CHANGES|BLOCK>
+Issues: <critical> critical, <high> high, <medium> medium, <low> low
+```
+
+---
+
+## Notes
+
+- Prefer project rules in `CLAUDE.md`, `AGENTS.md`, and `.claude/rules/` when judging pattern compliance.
+- For `/commit-changes`, Local Review Mode is the default and must run before `exonous token commit`.

package/assets/skills/commit-changes/SKILL.md

@@ -0,0 +1,49 @@
+---
+description: Commit the current changes with semantic commits, scan for leaks, do a quick review, then push.
+model: sonnet
+---
+
+Commit the current changes with semantic commits, scan for leaks, do a quick review, then push.
+
+## Gates
+
+exonous gates `git commit`, `git push` and `gh pr create` in every gated AI tool (`exonous doctor` lists them), machine-wide:
+
+```
+/commit-changes → /security-review → /code-review → exonous token commit → git commit   (token: one commit of the staged tree, 15 min)
+force-push or push to main/master → only on the user's explicit request → exonous token push → git push
+/make-pr → ≤ 30 changed files → body at `exonous draft-path` → exonous validate-pr <file> → gh pr create --body-file <file>
+```
+
+- Run each gated command **alone** (optionally after one `cd <dir> &&`): no `&&` chains, pipes, `;`, wrappers, `sh -c`, `-a`/`-i`/`-o`/`-p` or pathspecs on `git commit`.
+- If the gate blocks you, read its reason, run `exonous workflow commit` (or `pr`), fix what it names, then retry. Never work around it.
+
+Steps:
+1. Run `git status --short` and `git branch --show-current`. If there is nothing to commit and nothing unpushed, say so and stop.
+2. **Branch guard:** if the current branch is `main` or `master`, do NOT commit there. Create a new branch first with `git checkout -b <name>`, where `<name>` follows the established pattern `type/short-kebab-description` (type ∈ feat | fix | refactor | docs | chore | test, chosen from the dominant change). Derive the description from what actually changed.
+3. **Semantic commits:** group the changes into cohesive units and commit each with a Conventional Commits message **in English** — `type: short description`, subject ≤ 100 chars, body only when the "why" isn't obvious. Prefer several small cohesive commits over one big commit.
+   - Stage only the files for each unit (`git add <paths>`), never `git add -A` blindly.
+   - NEVER use `git add -f`/`--force` on `.gitignore`d paths — if a file won't stage, ask the user.
+4. **Authorship:** commits are authored solely by the repository's configured git identity (the current user). NEVER pass `--author`, and NEVER add `Co-Authored-By`, "Generated with", Claude, Cursor, or any AI/agent mention to the message or trailer.
+5. **Leak / sensitive-data scan (before push):** use the project's available tooling to confirm nothing sensitive is going out:
+   - Run the repo's secret scanner if present (e.g. `gitleaks git --staged`; the commit gate also runs it and blocks on findings or a staged `gitleaks:allow` — respect its result).
+   - **Required:** invoke `/security-review` on the staged (or branch) diff. Do not skip. If it reports CRITICAL or HIGH findings, fix them before continuing — do not mint the commit token yet.
+   - Verify no real `.env*` file is staged (only `*.env.example`/template files with placeholder values are allowed) and that no tokens, API keys, credentials, private certs, or PII appear in the diff.
+   - If anything leaks, STOP, unstage/amend as needed, and report — do not push.
+6. **Mandatory cleanup (before push):** in every modified file, remove logs and debuggers, and remove comments that don't state a relevant business rule. Comments that stay are one terse line; any comment longer than 2 lines gets cut to one (`nomos.md` § Engineering).
+7. **Quick code review (before push):** **Required:** invoke `/code-review` on the staged (or branch) diff. Do not skip. Fix CRITICAL/HIGH findings before continuing; surface MEDIUM/LOW to the user. Do not mint the commit token until `/code-review` passes (no unresolved CRITICAL/HIGH).
+8. **Mint the commit token:** stage the unit first, then run `exonous token commit`. It allows exactly one commit of what is staged right now and expires in 15 minutes; staging anything afterwards invalidates it. Only mint it **after** `/security-review` and `/code-review` have passed.
+9. Commit with a HEREDOC message, as its own command:
+   `git commit -m "$(cat <<'EOF'`
+   `Commit message here.`
+   `EOF`
+   `)"`
+   - Mint a fresh token before **each** commit in a multi-commit run (each commit consumes its token).
+10. **Push:** `git push -u origin <current-branch>` needs no token. Never force-push and never push directly to `main`/`master`: the gate blocks both. Only when the user explicitly asked for one of them, run `exonous token push` right before that push (it allows one push of the current HEAD).
+11. **Memory drift (warn, never block):** run `exonous project-memory validate` when a vault is configured; list drifted memories in the report so they get fixed.
+12. Report: branch used, the commits created (hashes + subjects), leak-scan result, review summary, and push status.
+
+Notes:
+- If `$ARGUMENTS` is provided, use it as a hint for the branch name and/or commit grouping/scope.
+- Follow the user's global commit conventions in `~/.claude/CLAUDE.md` ("Git and organization").
+- The exonous gate enforces this flow: `git commit` without a valid token for the staged tree is blocked. This is not optional — it is the actual enforcement mechanism.

package/assets/skills/deliver/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: deliver
+description: Delivery workflow — classify → discuss → plan → execute → verify → close, run with the 12 exo-* agents, plan memories in project-memory and compact JSON reports. Use for any multi-step change ("implement", "build", "ship", "execute the plan", "fix this issue end to end", "plan this feature"), to resume a saved plan, or to see open plans. Replaces the old phase-workflow commands.
+---
+
+# deliver
+
+One loop for every delivery, sized to the work. The session is the **coordinator**: it scopes packets, picks branches, judges gates and owns memory writes. It implements inline only when the work is Trivial.
+
+```bash
+M="exonous project-memory"
+```
+
+| Call | Does |
+|---|---|
+| `/deliver <request>` | full loop |
+| `/deliver plan <request>` | stop after the plan memory is saved |
+| `/deliver resume [plan-id]` | continue a saved plan (no id → `$M list --kind plan --status open`, ask which) |
+| `/deliver status` | open plans + their next step, nothing else |
+
+## 0. Load context — cheap first
+
+- `git status --short --branch`.
+- `$M search "<topic>" --limit 5` for related plans/ADRs; `$M show` only the hits that change the work.
+- Code locations: `atlas` (`search_graph` → `get_code_snippet`) or one `exo-researcher` navigator packet. Never pass agents a broad dump.
+
+## 1. Classify — state it before any agent runs
+
+| Class | When | Runs |
+|---|---|---|
+| **Trivial** | ≤ 5 files, one domain, no shared flow, no boundary, no auth/input/secrets | inline in the main thread → verify → close. No agents. |
+| **Standard** | multi-file or cross-domain, no boundary change | plan → implementer(s) → `exo-qa` |
+| **Complex** | module boundary, data model, new dependency, shared flow, or security surface | `exo-cto` (record ADR) → plan → implementers → `exo-qa` ∥ `exo-security` ∥ `exo-designer` as gates apply |
+
+Also state the **branch strategy**: on `main`/`master` ask before creating `type/short-description`; one branch for direct/sequential work; one worktree per editing lane (`isolation: "worktree"`) for parallel work.
+
+## 2. Discuss — only when something is genuinely ambiguous
+
+Answer from code and memory first. Then ask one question at a time, each with a recommended answer. Record each decision that would be expensive to reverse as an `adr` as soon as the user settles it. Skip this step when the request is clear.
+
+## 3. Plan
+
+- Trivial: a TodoWrite list, `step → verify: <check>`. No memory.
+- Standard/Complex: `exo-pm` (Complex: after `exo-cto`) returns tasks with **owner agent, files, done-check, dependencies, parallel marks**. The plan must be self-contained — an executor with zero context of this session must succeed with it.
+- Save it: `$M add plan --title "<goal>" --body-file <plan.md> --tag <area> --link file:<main path>`. `/deliver plan` stops here and prints the plan id.
+
+## 4. Execute
+
+Pick the shape from real dependencies:
+
+- **Direct** — one lane, one implementer chain on one branch.
+- **Sequential** — tasks depend on earlier outputs; run lane by lane, gate between them.
+- **Parallel** — independent lanes, no shared files; read `references/parallel.md` first.
+
+Implementers by domain (opus): `exo-frontend`, `exo-backend` (default), `exo-mobile`, `exo-data-ai`, `exo-devops`, `exo-infra`. Independent agents go out in one message.
+
+**Packet** (coordinator → agent), nothing else:
+
+```
+Goal: <one action sentence>
+Plan: <plan-id> · task <n> — <excerpt of that task only>
+Branch/worktree: <name>
+Files in scope: <paths> · Do not touch: <paths>
+Done when: <runnable checks>
+Context: <navigator block / ADR ids that matter>
+```
+
+**Report** (agent → coordinator): first line `{"status":"done|partial|blocked","cause":"…","risks":["…"]}`, then files touched, evidence (command → result), findings `file:line — impact — fix`. The coordinator reads reports, not diffs.
+
+## 5. Verify and review
+
+Gate agents fetch the diff themselves (`git diff <base>...HEAD`) — the packet names the base and the acceptance criteria.
+
+| Gate | When |
+|---|---|
+| `exo-qa` | every Standard/Complex change; runs types, lint, affected tests, the changed path |
+| `exo-security` | auth, input handling, secrets, dependencies, data exposure changed |
+| `exo-cto` | boundaries, abstractions or shared flows changed |
+| `exo-designer` | visible UI changed |
+
+Trivial: run the checks yourself and quote the output.
+
+**Revision loop:** findings go back to the **same** implementer with `SendMessage` (its context is intact — never respawn). Stop and surface to the user, writing the blocker into the plan memory, when:
+- 2 revision rounds are spent, or
+- a round makes no progress on the gate it targeted, or
+- the same failure repeats with the same cause.
+
+## 6. Close
+
+1. Milestones: `$M update <plan-id> --status in-progress --body-file <updated plan>` so progress survives the session.
+2. Done and verified: record decisions as `adr` (with `--link`/`--evidence`); add a `doc` only when behavior genuinely needs explaining, written fresh. Then `$M remove <plan-id>`.
+3. Follow-up work found along the way → a new `plan`, never silent scope growth.
+4. `$M validate` when the change moved code that memories anchor to; fix what drifted.
+5. Commit/PR only if the user asked: `/commit-changes`, then `/make-pr`. Mid-task pause → `/session-handoff`.
+
+## Checklist
+
+- [ ] Class and branch strategy stated before the first agent.
+- [ ] Every agent got a packet, every report starts with the JSON line.
+- [ ] Required gates ran, or were skipped with a stated reason.
+- [ ] Revision rounds reused the same agent; stop conditions respected.
+- [ ] Plan memory reflects reality: updated, removed, or holding the blocker.
+- [ ] Real check output quoted — no claim without evidence.
+
+## Old workflow commands
+
+| Was | Now |
+|---|---|
+| quick task | `/deliver <request>` (classifies as Trivial) |
+| discuss / plan phase | `/deliver plan <request>` |
+| execute phase | `/deliver resume <plan-id>` |
+| progress | `/deliver status` |
+| debug | `diagnose` skill or a `exo-qa` debug packet |
+| pause / resume work | `/session-handoff` |

package/assets/skills/deliver/references/parallel.md

@@ -0,0 +1,37 @@
+# Parallel lanes
+
+Use only when lanes are independent: no shared mutable files, no lane needs another's output. Anything uncertain runs sequentially.
+
+## Before dispatch
+
+Classify each task: **independent** (run now) · **sequential** (needs another lane's output) · **shared-file risk** (merge conflict likely) · **shared-domain risk** (decisions may clash even with different files). Parallelize only the independent ones.
+
+State the lane map in the session — plan id + task numbers, worktree/branch, done-checks. Write it into the plan memory only if it must survive the session.
+
+## Lanes
+
+- One implementer per lane, `isolation: "worktree"`, named so it stays addressable. Long lanes: `run_in_background: true`.
+- Each packet is self-contained: the lane's task excerpt, owned files, do-not-touch areas, done-checks. Agents do not inherit this conversation.
+- Lanes do not talk to each other; facts one lane needs from another travel through the coordinator's next packet.
+- Follow-ups and revisions go to the same lane agent via `SendMessage`.
+
+## Safe to run in parallel
+
+- navigator lookups on different areas
+- implementation lanes on disjoint files
+- `exo-security` dependency inventory while code is still moving
+- reviews of a committed snapshot
+
+## Never in parallel
+
+- two agents editing the same file
+- reviewing code another lane is still changing
+- declaring the plan done before every lane is merged and verified together
+
+## Merge
+
+1. Collect every lane report; any `blocked` → resolve or stop before merging.
+2. Merge lane branches one at a time (git is the coordinator's job).
+3. Conflicts in source → a packet to the implementer that owns those files, with both lanes' reports; the coordinator does not hand-edit.
+4. Run the gates of `SKILL.md` §5 once more on the merged result — `exo-qa` always, the others as they apply.
+5. Close per `SKILL.md` §6.

package/assets/skills/doc/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: doc
+description: Acha o vault Obsidian de documentação do repositório atual e, com base no resumo da última sessão (ou na conversa atual), aponta o que precisa mudar na documentação e aplica o que o usuário aprovar, e fecha com commit e PR só da doc. Sem vault, alerta e sugere criar um. Genérica para qualquer projeto. Use quando o usuário pedir "/doc", "atualiza a doc", "o que mudar na documentação", "revisa o vault do projeto".
+---
+
+# Doc
+
+Mantém o vault Obsidian **do projeto** (dentro do repo, versionado com o código) em dia com o que a sessão mudou.
+
+Esta skill não conhece nenhum projeto. O vault é qualquer pasta do repo que contenha `.obsidian/`. A parte mecânica usa o comando nativo `exonous doc` e git, sem depender de Node.
+
+Não confunda os dois vaults:
+
+| | Vault do projeto | Vault de sessões |
+|---|---|---|
+| Onde | dentro do repo (ex.: `docs/<Projeto>/`) | fora de qualquer repo, definido por `exonous vault`; configs legadas entram via `exonous vault consolidate` |
+| O quê | regras, arquitetura, invariantes, armadilhas | o que aconteceu numa sessão |
+| Esta skill | **lê e edita** | **só lê** a última nota, como fonte |
+
+## 1. Localizar
+
+```bash
+exonous doc locate
+```
+
+A saída é um JSON com `repo`, `vaults` (caminho, número de notas e a nota de entrada, como `_CONTEXTO` ou `README`) e `session` (última nota de sessão do repo). Trate pelo código de saída:
+
+- **2 (fora de um repo git):** diga isso e pare.
+- **3 (nenhum vault):**
+  - se `vaultsInMainCheckout` veio preenchido, você está num worktree cuja branch saiu antes de o vault existir. Não crie vault: diga isso e sugira atualizar a branch a partir da base (`git merge` ou `rebase`);
+  - senão, vá para a seção 5.
+- **Mais de um vault:** um repo pode documentar a si mesmo e a um sistema vizinho. Escolha pelo assunto da sessão. Se não der para saber, pergunte com AskUserQuestion.
+
+## 2. Montar o resumo da sessão
+
+Fonte, nesta ordem:
+
+1. **A conversa atual**, se nela houve mudança de código, decisão ou descoberta.
+2. **A nota em `session.note`**, quando a conversa atual não tem esse conteúdo (ex.: `/doc` logo depois de um `/clear`). Diga ao usuário qual nota usou e a data dela.
+3. Nenhuma das duas: use `git log --since=<data> --stat` e peça ao usuário o período.
+
+Extraia só o que pode afetar a documentação:
+- **decisões do usuário** (mudam regra de negócio ou de arquitetura);
+- **comportamento alterado** (commits e PRs, com os arquivos tocados);
+- **armadilhas** confirmadas;
+- a seção **"Candidatos a promoção"** da nota, que já é uma lista pronta;
+- **arquivos-chave** tocados.
+
+Ignore status de tarefa, autorizações e passos de operação: isso é da sessão, não do projeto.
+
+## 3. Achar o que ficou desatualizado
+
+1. Leia a nota de entrada do vault (`vaults[].entry`) para entender a organização e as convenções: frontmatter, callouts, numeração, como cita código. Com `entry: null`, leia a lista de pastas da raiz do vault e as notas alteradas mais recentemente (`git log -5 --name-only -- "<vault>"`).
+2. Cruze as referências `arquivo:linha` das notas com o que mudou:
+   ```bash
+   exonous doc refs "<vault>" --since <git-ref ou AAAA-MM-DD do início da sessão>
+   ```
+   - `notasQueCitamArquivosAlterados`: notas que provavelmente descrevem código que mudou. O cruzamento inclui mudanças ainda não commitadas e arquivos novos. **Abra cada `arquivo:linha` citado e confira se a linha ainda diz o que a nota afirma**: estar fora de `quebradas` só prova que a linha existe, não que está certa.
+   - `quebradas`: referência a arquivo inexistente ou a uma linha além do fim do arquivo. Antes de propor correção, veja se o arquivo mora em **outro repo** que o vault também documenta; nesse caso não está quebrada.
+   - `ambiguas`: nome citado sem caminho que casa com mais de um arquivo (`candidatos`). Só mexa se a nota tocar o assunto da sessão.
+   - `ignoradasPorParecerHost`: `host:porta` e `ip:porta`, que não são arquivo. Não proponha corrigir.
+3. Memórias do projeto (`adr`/`plan`/`doc` do `project-memory`), se a skill existir: `exonous project-memory validate` aponta evidência que mudou de lugar (`moved`) ou de conteúdo (`drift`) e links que não resolvem. Inclua esses itens nas propostas.
+4. Procure no vault com `exonous project-memory search "<termos>"` (ou Grep, sem a skill) os termos do resumo: nomes de função, rota, tabela, flag, decisão. Assim aparecem as notas que falam do assunto sem citar arquivo.
+
+## 4. Propor, confirmar, aplicar
+
+**Verifique no código antes de propor.** Toda afirmação nova ou corrigida precisa de `arquivo:linha` conferido nesta sessão. O que não der para confirmar entra marcado como não verificado, no padrão do vault (ex.: `> [!todo] Não verificado`), nunca como fato.
+
+Mostre a proposta numa tabela, a mais importante primeiro:
+
+| # | Nota | Mudança | Por quê (evidência) |
+|---|---|---|---|
+| 1 | `<nota>` (exemplo) | adicionar a regra N+1: ... | decisão "..." + `src/x.ts:40` |
+
+Pergunte o que aplicar com AskUserQuestion: **"Aplicar todas"**, **"Escolher por número"** ou **"Nenhuma"**. Na escolha por número, peça os números. Sem AskUserQuestion, faça a mesma pergunta em texto e espere a resposta: não aplique nada sem ela.
+
+Antes de editar, prepare a branch (seção 6, passo 1).
+
+Ao aplicar:
+- Siga as convenções do vault: idioma, frontmatter, callouts, `[[wikilinks]]` entre notas do **próprio** vault e a numeração existente (continue a sequência, não renumere).
+- Se o vault usa um campo de data de atualização no frontmatter, atualize-o nas notas tocadas.
+- Corrija referências `arquivo:linha` que ficaram erradas nas notas que você editar.
+- Nota nova só quando nenhuma existente cobre o assunto; ligue-a na nota de entrada.
+- Nunca copie segredo, token, credencial ou dado de cliente para o vault. Cite o nome da env var ou do secret.
+- Nunca grave nota de sessão no vault do projeto.
+- Depois de aplicar, siga a seção 6: commit e PR fazem parte do `/doc`.
+
+Se a proposta usou "Candidatos a promoção" de uma nota de sessão, acrescente ao item nessa nota ` — promovido em AAAA-MM-DD para <caminho>`. É a única escrita permitida no vault de sessões.
+
+Nada a mudar: diga isso em uma linha e cite o que foi conferido (quais notas, qual intervalo do git).
+
+## 5. Sem vault
+
+Alerte o usuário:
+
+> Este repositório não tem vault Obsidian de documentação. Sem ele, decisões e armadilhas descobertas nas sessões não ficam registradas junto do código.
+
+Este vault é o do projeto, não o vault central do exonous (`exonous vault`, que guarda sessões e memória): não use um no lugar do outro.
+
+Pergunte com AskUserQuestion se quer criar agora. Se não quiser, pare. Se quiser:
+
+1. Proponha o local `docs/<Nome-Do-Repo>/`, ou use outro que o usuário indicar.
+2. Proponha a estrutura mínima abaixo. Nomes de pasta, de arquivo e o idioma são sugestão: confirme com o usuário ou siga o idioma do repo.
+   ```
+   docs/<Nome>/
+   ├── .obsidian/app.json          {}
+   ├── .gitignore                  .obsidian/workspace*.json
+   ├── 00 - Navegação/_CONTEXTO.md
+   └── 01 - Validação/
+       ├── _INVARIANTES.md
+       └── _EDGE-CASES.md
+   ```
+3. `_CONTEXTO.md`: o que o projeto é, stack, tabela "área do código → o que ler antes de mexer" e as convenções do vault. Leia antes o README, o CLAUDE.md/AGENTS.md e a estrutura de pastas. Não invente: o que não der para confirmar fica marcado como não verificado.
+4. `_INVARIANTES.md` (regras que não podem quebrar, `I-01`…) e `_EDGE-CASES.md` (comportamentos contra-intuitivos, `EC-01`…): comece com o que a sessão atual confirmou, cada item com `arquivo:linha`. Se não houver nada confirmado, deixe só o cabeçalho e a explicação do formato.
+5. Mostre a árvore criada e siga a seção 6.
+
+Frontmatter mínimo de cada nota:
+
+```yaml
+---
+title: <título>
+tags: [<área>]
+atualizado: AAAA-MM-DD
+---
+```
+
+## 6. Commit e PR
+
+A aprovação da seção 4 ("Aplicar todas" ou os números escolhidos) já autoriza commit e PR **só da doc**. Não pergunte de novo.
+
+1. **Branch, antes de editar.** Base: `develop` se `git ls-remote --exit-code --heads origin develop` responder; senão a branch padrão (`gh repo view --json defaultBranchRef -q .defaultBranchRef.name`). Crie `docs/<assunto-curto>` a partir de `origin/<base>` (`git fetch origin <base>` e `git checkout -b docs/<assunto> origin/<base>`) quando qualquer um destes valer:
+   - a branch atual é `main`, `master` ou a própria base;
+   - a PR da branch atual já foi mergeada ou fechada (`gh pr list --head <branch> --state all --json state`);
+   - a branch atual é de outro assunto e tem mudanças que não são desta doc.
+   Se a troca de branch falhar por mudança local, pare e diga qual arquivo bloqueou. Não use `stash` nem `reset` sem pedir.
+2. **Stage só o que você editou no vault** (e a nota de entrada, se ligou nota nova): `git add <caminhos>`. Nunca `git add -A`. O que não é desta doc fica de fora.
+3. **Commit:** rode `/commit-changes` (ou o fluxo de commit do projeto, conforme CLAUDE.md/AGENTS.md). Um commit `docs(...)`, no idioma de commit do projeto.
+4. **PR:** rode `/make-pr` com a base do passo 1 explícita. Se a sessão tratou de uma issue, referencie no corpo ("Relacionada a #N", nunca `Closes`) e, se o projeto pede (board no CLAUDE.md), comente o link da PR na issue.
+5. **Sem skill de commit ou PR no ambiente:** pare depois do passo 2, liste os arquivos e diga o que falta.
+6. No fim, mostre a URL da PR, a branch e os arquivos do commit.