Init

Transforma a pasta onde a sessão foi iniciada em um cofre PARA conectado a este plugin e mantém essa configuração: uma segunda execução preenche o que está faltando e migra um esquema antigo. É o único skill que escreve a configuração do cofre e o único que é executado sem ela.

O que ele escreve

Tudo abaixo e nada mais. REPO_ROOT, PARA_DIR, PARA_ROOT conforme definidos em paths.md.

O quê	Onde	Como
as pastas PARA	`PARA_ROOT/` + `Projects`, `Areas`, `Resources`, `Archive`, `Inbox`, `Templates`	criadas quando ausentes
os modelos de anotação	`PARA_ROOT/Templates/`	semeados a partir do plugin, apenas quando ausentes («Templates»)
o diário de IDs	`PARA_ROOT/Archive/.removed-ids`	apenas seu cabeçalho, apenas quando ausente (`project-id.md` «The journal»)
configuração do cofre	`REPO_ROOT/.claude/para/vault.md`, `areas.md`; `adapter.md` apenas quando `TASKS` é `mcp`	a partir de `config.example/`; nunca sobrescrito
o bloco do plugin	`REPO_ROOT/CLAUDE.md`	entre os marcadores apenas («CLAUDE.md»)
as permissões dos skills	`REPO_ROOT/.claude/settings.json`	mesclado, nunca substituído («Settings»)
configurações do Obsidian	`REPO_ROOT/.obsidian/app.json`, `templates.json`	mesclado («Obsidian»)
as anotações e pastas do usuário (apenas B)	de onde estão para as pastas PARA	movidas, nunca editadas — apenas os movimentos listados no plano aprovado («Scenario B»)
visões gerais de projetos (apenas B)	`PARA_ROOT/Projects/PROJ-xxxx <title>/`	novas, para uma pasta que o usuário chamou de projeto («Scenario B»)
a chave de par em visões gerais (apenas C)	`PARA_ROOT/Projects/`, `PARA_ROOT/Archive/`	apenas a chave de frontmatter renomeada, nada mais (`scenario-c.md`)
o arquivo de planejamento do cofre (apenas C)	`REPO_ROOT/.claude/local/planning.md`	novo, extraído das ferramentas antigas (`scenario-c.md`)
as ferramentas antigas incorporadas (apenas C)	`REPO_ROOT/.claude/`, `CLAUDE.md`, a documentação do modelo antigo	para a Lixeira do macOS, Tier 2 (`scenario-c.md`)

Camada base

Leia antes de agir, cada um como ../../para/<arquivo>.md relativo ao diretório base deste skill (e ../../config.example/, ../../lang/, ../../templates/ da mesma forma):

../../para/paths.md — sempre: as duas raízes, «Language», o adaptador para TASKS. Tudo o que init escreve deve concordar com ele.
../../para/tasks.md — as operações, «Pairing», «Backend missing»
../../para/adapters/mcp-generic.md — quando TASKS é mcp; o adaptador para qualquer outro valor é nomeado por paths.md
../../para/note-format.md — o esquema de frontmatter que os modelos devem corresponder
../../para/migrations.md — o SCHEMA atual do plugin e como uma migração é executada
../../para/claude-md-block.md — o bloco para CLAUDE.md
../../para/confirm.md — os tiers; o plano abaixo é como init os atende
../../para/project-id.md — «The journal»: o cabeçalho do diário de IDs (Passo 5.1)
../../config.example/vault.md, areas.md, adapter.md — a forma da configuração
cenário B apenas: ../../para/move.md (como um movimento mantém links), project-id.md (emitindo um ID), ../../para/thresholds.md (o limite de obsolescência de área e «The limit of mtime»), paths.md «IGNORE»
../../lang/<LANG>.md quando LANG é conhecido: as strings init.*
cenário C apenas, e os resquícios de C em uma reexecução: scenario-c.md no diretório base deste skill — tudo sobre o layout antigo; também ../../para/move.md (a Lixeira)

SKILL_DIR abaixo é o diretório base deste skill, conforme anunciado pelo harness.

Regras para toda a execução

REPO_ROOT é o diretório de trabalho da sessão, como um caminho absoluto (pwd). Este é o único lugar onde o plugin obtém uma raiz do diretório de trabalho: init é o que a escreve para todos os outros skills. O plano diz qual pasta é, para que uma sessão iniciada no lugar errado seja detectada antes que algo seja escrito.
Nada é escrito antes do «sim» do plano. Inspeção, perguntas e investigação do backend de tarefas são somente leitura.
vault.md é escrito por último. É o que marca um cofre como configurado; uma execução interrompida não deixa vault.md e a próxima execução recomeça, encontrando o trabalho já feito.
Cada passo é idempotente: criar quando ausente, mesclar quando presente, nunca sobrescrever. Executar init duas vezes seguidas não muda nada na segunda vez.
Coloque cada caminho entre aspas (paths.md «Rules»). REPO_ROOT pode conter espaços.
Idioma. Até que LANG seja escolhido, fale o idioma que o usuário usou (inglês quando não há nada por onde escolher — um /para:init simples). A partir de então, tudo está em LANG conforme paths.md «Language», incluindo as perguntas restantes; os cabeçalhos do plano e do relatório são as strings init.*.

Respostas fornecidas antecipadamente

$ARGUMENTS já pode conter respostas: o idioma, PARA_DIR («the default» significa o proposto), o backend de tarefas, o modelo de Áreas, no cenário B as respostas de classificação (por pasta ou anotação raiz, e para os nomes duplicados), a resposta do snapshot e uma aprovação do plano. Aceite cada resposta fornecida e não a pergunte novamente; pergunte apenas o que está faltando. Uma resposta que não é uma escolha válida é perguntada novamente, explicando o porquê.

Uma aprovação fornecida antecipadamente significa: mostre o plano, depois aplique-o sem esperar — mas apenas enquanto cada linha do plano adiciona algo (uma pasta, um arquivo, uma chave, uma entrada). Uma linha que altera ou substitui algo que já existe (um valor diferente do Obsidian, um bloco CLAUDE.md diferente, um modelo em uma migração, REPO_ROOT em um vault.md existente) é Tier 2 (confirm.md): o plano é mostrado e init espera por um «sim» mesmo assim.

Os movimentos do cenário B são de dois tipos, e esta é a única declaração de como uma aprovação antecipada os cobre. Um movimento que o usuário decidiu em suas próprias respostas (B3, ou as respostas de classificação em $ARGUMENTS) muda onde uma anotação está, nunca o que ela diz, e confirm.md coloca a movimentação no Tier 1: o «sim» do plano, dado então ou antecipadamente, o cobre. Um movimento decidido apenas pelas regras (B2: para Archive/ ou Resources/) é o próprio julgamento de init sobre as anotações do usuário: precisa de um «sim» ao vivo para o plano que o mostra, mesmo quando uma aprovação foi fornecida antecipadamente. De qualquer forma, o snapshot é oferecido antes dos movimentos (Passo 4). Uma pergunta de classificação respondida antecipadamente não é feita; uma deixada sem resposta é feita, e nada é aplicado antes de sua resposta, aprovação ou não.

Passo 1 — Inspecionar

Somente leitura. Descubra o que a pasta é e nomeie o cenário.

REPO_ROOT=$(pwd)
ls -A "$REPO_ROOT"
ls "$REPO_ROOT/.claude" "$REPO_ROOT/.claude/para" "$REPO_ROOT/.claude/skills" 2>/dev/null
# o layout antigo incorporado (cenário C): sua pasta de configuração ou sua camada base
ls -d "$REPO_ROOT/.claude/para/local" "$REPO_ROOT/.claude/para/paths.md" 2>/dev/null   # old-layout
# pastas de skill nomeadas como os skills antigos incorporados: relatadas, nunca C por si só
for s in inbox projects areas resources archive remove vault-lint; do
  [ -f "$REPO_ROOT/.claude/skills/$s/SKILL.md" ] && echo "old skill: $s"; done
# anotações: todo .md não abaixo de uma entrada de ponto de REPO_ROOT, exceto os próprios arquivos do repositório
# e modelos (entradas de ponto são podadas em relação a REPO_ROOT, então um cofre que vive abaixo de um diretório ponto ainda é visto)
find "$REPO_ROOT" -mindepth 1 -name '.*' -prune -o -name "*.md" -not -path "*/Templates/*" \
  ! -path "$REPO_ROOT/CLAUDE.md" ! -path "$REPO_ROOT/README.md" ! -path "$REPO_ROOT/CHANGELOG.md" -print | head -50
# um cofre acima desta pasta: init foi iniciado em uma subpasta
d=$(dirname "$REPO_ROOT")
while [ "$d" != "/" ] && [ "$d" != "$HOME" ]; do
  { [ -e "$d/.claude/para/vault.md" ] || [ -d "$d/.obsidian" ]; } && echo "vault above: $d"
  d=$(dirname "$d")
done

Pare antes de qualquer outra coisa quando:

REPO_ROOT é $HOME ou / — não é um cofre; diga isso.
um cofre foi encontrado acima — diga «execute /para:init de <aquela pasta>» e pare; nunca configure um cofre dentro de outro.

Em seguida, decida, nesta ordem, e diga o que foi encontrado e qual é o caso:

Configurar — .claude/para/vault.md existe → «Reexecução e migração» abaixo.
Cenário C — as ferramentas antigas incorporadas, reconhecidas por sua camada base ou configuração antiga (a linha old-layout acima): sua pasta de configuração local/ ou seu arquivo de camada base paths.md dentro de .claude/para/. → «Cenário C». Uma pasta de skill nomeada como um dos skills antigos (as linhas old skill:) sem nenhum deles não é C: vá para B ou A pelas regras abaixo. Diga qual pasta foi encontrada e que init a deixa em paz; o «não feito» do plano a nomeia novamente. Um .claude/para/ contendo apenas os arquivos de configuração deste plugin (areas.md, adapter.md) e nenhum vault.md não é C: é uma primeira execução de init que foi interrompida ou recusada antes de vault.md. Vá para B ou A abaixo como se não estivesse lá, exceto que esses arquivos são a configuração do cofre — nunca sobrescritos — e uma pergunta que eles já respondem (pergunta 4 para areas.md) não é feita novamente. A execução preenche o resto.
Cenário B — anotações foram encontradas (o find acima imprimiu algo). → «Cenário B».
Cenário A — caso contrário: uma pasta vazia, ou uma contendo apenas arquivos que não são anotações (um .obsidian/ de um novo cofre do Obsidian, um CLAUDE.md). → Passo 2.

Passo 2 — Perguntas

Uma de cada vez, nesta ordem, pulando todas que foram respondidas antecipadamente. Cada pergunta mostra suas escolhas e, quando houver, o padrão.

Idioma (LANG). As escolhas são os idiomas que o plugin fornece: um código com ambos lang/<code>.md e templates/<code>/ (paths.md «Language»):
```
for f in "$SKILL_DIR"/../../lang/*.md; do l=$(basename "$f" .md)
  [ -d "$SKILL_DIR/../../templates/$l" ] && echo "$l"; done
```
Pasta PARA (PARA_DIR). Padrão por cenário: A — PARA, uma subpasta, para que as ferramentas e as anotações fiquem separadas; B — ., para que as pastas PARA fiquem ao lado das pastas do próprio usuário, exceto conforme «Scenario B» diz. . coloca as pastas PARA diretamente em REPO_ROOT. Válido: . ou um nome de pasta — sem /, não começando com ., não sendo um dos próprios nomes de pastas PARA.
Backend de tarefas (TASKS). As escolhas são todoist, files ou mcp; a primeira é recomendada. Diga em uma linha o que cada uma significa: a caixa de entrada e projetos de um aplicativo; anotações de tarefas no cofre, sem aplicativo; qualquer outro aplicativo de tarefas conectado via MCP. Em seguida, investigue — «Investigando o backend» abaixo. Um valor cuja investigação falhou nunca é registrado.

Modelo de Áreas (areas.md). Uma pergunta: as Áreas são agrupadas — none, ou os nomes dos grupos (por exemplo Trabalho, Casa)? Todo o resto é derivado e mostrado no plano, onde o usuário pode alterá-lo:

Chave	Agrupado	`none`
`GROUPING`	o nome do campo, `sphere` a menos que o usuário tenha nomeado um (a chave dos modelos de semente)	`none`
`GROUPS`	os nomes fornecidos	vazio
`PLACEMENT`	`Areas/<GROUP>/<titulo>.md`	`Areas/<titulo>.md`
`REVIEW_GROUPING`	um bloco por grupo, grupos com nada a relatar descartados	uma lista plana
`PLACEMENT_CHECK`	o campo `GROUPING` de uma anotação deve nomear a pasta de nível superior onde ela está	`none`
`AREA_TASK_PROJECTS`	os nomes de `GROUPS`	um nome: a string `areas.review.heading`

Investigando o backend

A investigação é inbox.list, executada conforme o adaptador para o valor escolhido (paths.md). É somente leitura; uma caixa de entrada vazia é um sucesso. Imprima apenas a contagem, nunca as capturas.

files — nada para investigar: o adaptador é o disco, e «Backend missing» não pode acontecer (tasks.md).
mcp — execute os passos 1–6 de adapters/mcp-generic.md agora. O passo 1 não encontrar ferramentas é uma investigação falha. O passo 6 é a investigação quando o usuário concorda com ela e o aplicativo tem uma caixa de entrada; caso contrário, o plano diz que o mapeamento não foi verificado. Os passos 7–8 pertencem ao plano e ao «Passo 5» abaixo.
Qualquer outro valor — execute inbox.list conforme seu adaptador. Se as ferramentas do adaptador não estão nesta sessão, ou a chamada falha: diga em uma linha (tasks.md «Backend missing»), não registre o valor e ofereça files como alternativa — ou conectar o aplicativo e executar /para:init novamente. Nunca escreva um valor de TASKS cuja investigação não teve sucesso e nunca registre um valor enquanto promete mudar depois.

Passo 3 — O plano

Uma lista de tudo que será criado, mesclado ou alterado, encabeçada pela string init.plan.heading. É uma proposta que o usuário edita, não um anúncio: uma edição gera um novo plano, mostrado novamente. Termina com a string init.plan.approve, e nada é aplicado antes de um «sim» (ou a aprovação fornecida antecipadamente, dentro do limite que «Respostas fornecidas antecipadamente» estabelece).

O plano nomeia, nesta ordem:

REPO_ROOT (esta pasta) e PARA_ROOT.
As pastas a criar e o diário de IDs quando estiver ausente.
Os modelos a copiar, cada um com as alterações que «Templates» faz a ele. No cenário B, aqui: os movimentos, os projetos, IGNORE, os duplicados retidos e os links que serão quebrados («Scenario B», «The plan's B part»).
A configuração: cada chave de vault.md e areas.md com seu valor; para mcp, a tabela do adaptador (mcp-generic.md passo 7 — o «sim» do plano é o «sim» dessa tabela).
CLAUDE.md, .claude/settings.json, .obsidian/app.json, .obsidian/templates.json: o que é adicionado a cada um. Cada valor existente que mudaria é uma linha própria, mostrando o valor antigo e o novo.
O resultado da investigação: o backend respondeu (com a contagem da caixa de entrada), ou files.
O que não será feito e por quê (um modelo já presente, um valor mantido).

Passo 4 — Snapshot (apenas B e C)

Antes de aplicar um plano que toca um cofre existente, ofereça uma cópia zip ao lado dele — sempre perguntado, recusa aceita, uma resposta fornecida antecipadamente é aceita. É perguntado na mesma mensagem que a aprovação do plano (a string init.snapshot), para que o usuário responda uma vez:

zip_path="$(dirname "$REPO_ROOT")/$(basename "$REPO_ROOT")-backup-$(date +%Y-%m-%d).zip"
ditto -c -k --keepParent "$REPO_ROOT" "$zip_path"

O cenário A não tem nada a salvar e pula isso.

Passo 5 — Aplicar

«Sim» foi dado (ou a aprovação antecipada cobre o plano). Execute cada linha na ordem que o plano lista. Escreva apenas o que o plano diz. Uma operação que falha (um arquivo que não pôde ser criado, um movimento que não pôde ser feito) para a execução e relata a falha.

5.1 — Pastas e o diário de IDs

Crie as pastas PARA_ROOT/ e PARA_ROOT/Projects, Areas, Resources, Archive, Inbox, Templates. Crie PARA_ROOT/Archive/.removed-ids se ausente com apenas seu cabeçalho (project-id.md «The journal»).

5.2 — Modelos

Copie de ../../templates/<LANG>/ para PARA_ROOT/Templates/, cada um apenas quando o arquivo de destino não existe. Para cada modelo, faça as seguintes substituições (nunca em um modelo existente):

<<PARA_ROOT>> → PARA_ROOT conforme paths.md
<<LANG>> → LANG
<<TASKS>> → TASKS
<<BASE>> → o URL base para links do plugin (de paths.md)
<<ADAPTER>> → o nome do adaptador (de paths.md)
chaves específicas de areas.md (<<GROUPING>>, <<GROUPS>>, <<PLACEMENT>>, <<REVIEW_GROUPING>>, <<PLACEMENT_CHECK>>, <<AREA_TASK_PROJECTS>>)

5.3 — Movimentos (apenas B)

Execute cada movimento listado no plano, na ordem que o plano lista. Use a função de movimento de move.md; nunca edite o conteúdo de uma anotação. Se um movimento falha (arquivo de destino já existe com conteúdo diferente), pare e reporte.

5.4 — Projetos (apenas B)

Para cada pasta que o usuário chamou de projeto e que não tem uma visão geral: crie PARA_ROOT/Projects/PROJ-xxxx <titulo>/ com um README.md do modelo de projeto.

5.5 — Configuração

Escreva REPO_ROOT/.claude/para/vault.md, areas.md e, se TASKS é mcp, adapter.md. Use os valores do plano. Nunca sobrescreva; se existirem, mescle apenas as chaves ausentes.

5.6 — `CLAUDE.md` e configurações

Adicione o bloco do plugin a CLAUDE.md entre os marcadores (claude-md-block.md). Mescle as configurações ausentes em .claude/settings.json, .obsidian/app.json, .obsidian/templates.json.

5.7 — Migração (apenas C)

Execute scenario-c.md na íntegra: mova as ferramentas incrustadas para a Lixeira, renomeie a chave de par nas visões gerais, crie o arquivo de planejamento.

5.8 — `vault.md`

Escreva vault.md por último. Isto sela a configuração.

Passo 6 — Relatório

Imprima, encabeçado pela string init.report.heading, o que foi feito: pastas criadas, modelos copiados, configurações escritas, movimentos executados. Se algo foi pulado porque já existia, liste-o como «já presente». Se algo falhou, pare e reporte a falha; o relatório só é impresso após uma aplicação bem-sucedida.

Reexecução e migração

Quando vault.md já existe, init:

Lê vault.md e areas.md atuais.
Compara o SCHEMA atual do plugin com o do cofre. Se são diferentes, executa a migração (migrations.md).
Preenche o que está faltando (pastas, modelos, configurações) sem sobrescrever nada.
Pergunta apenas o que está faltando e que não pode ser derivado (por exemplo, um novo modelo de Áreas se o plugin foi atualizado).
Mostra um plano de apenas itens faltantes, não de tudo.
Aplica após aprovação.
Reporta o que foi adicionado ou migrado.

Uma migração de esquema é Tier 3 (confirm.md): o plano é mostrado e init espera por um «sim» mesmo com aprovação antecipada.

qbarev/para-plugin

O que é para-plugin?

Perguntar na sua IA favorita

Documentação