Project a partir de template

Uma pergunta por vez. Nada é criado antes do preview final e de um "sim" explícito.

GHP="<plugin-root>/scripts/ghp.py" — detalhes dos presets em <plugin-root>/references/project-templates.md.

1. Pré-requisitos

Leia .planning/github.json. Sem ele, ou sem o scope project, siga a skill github-init primeiro.

2. Origem do template

python3 "$GHP" preset list

Apresente:

Qual template usar?
1. roadmap-produto — {summary}
2. kanban          — {summary}
3. scrum           — {summary}
4. Copiar um Project-modelo existente (preserva views, workflows e campos)

Opção 4 (cópia): pergunte o dono do modelo (usuário/org) e liste os Projects dele (gh project list --owner <dono> --format json -q '.projects[] | "\(.number) \(.title) \(.template // false)"', marcando os que são template). Depois pergunte o título e siga direto para o passo 5 com o comando project copy. --drafts só se o usuário quiser os rascunhos do modelo.

3. Mostrar o preset

python3 "$GHP" preset show <nome> e apresente como tabela:

Template: roadmap-produto
| Campo       | Tipo           | Opções / uso                                    |
|-------------|----------------|-------------------------------------------------|
| Status      | Seleção        | Backlog · Pronto · Em andamento · Em revisão · Concluído |
| Tipo        | Seleção        | Épico · Feature · Task                          |
| Prioridade  | Seleção        | Must · Should · Could · Won't                   |
| Estimativa  | Seleção        | P · M · G                                       |
| Fase        | Texto          | preenchido pelo publish (F01 Fundação)          |
| Onda        | Número         | preenchido pelo publish (paralelismo)           |
| Requisitos  | Texto          | FR-xx de origem                                 |
| Início, Fim | Data           | para a view Roadmap                             |
Views sugeridas: Quadro (por Status) · Por onda (tabela) · Linha do tempo (Roadmap)

4. Personalização

Pergunte: Quer personalizar? (n = usar como está). Se sim, ofereça o menu e repita até o usuário dizer que terminou:

1. Nome do Project            (padrão: os argumentos ou "<produto> — Roadmap")
2. Dono                       (@me ou organização)
3. Visibilidade               (PRIVATE padrão | PUBLIC)
4. Repositório vinculado      (padrão: repo do .planning/github.json)
5. Descrição e README do Project
6. Renomear um campo
7. Editar opções de um campo de seleção (nome, cor, descrição)
8. Adicionar campo            (Texto · Número · Data · Seleção · Iteração)
9. Remover campo
10. Iterações (scrum): início, duração em dias, quantidade
0. Pronto

Regras ao editar:

• Mantenha o role do campo ao renomear (é o que o publish usa para achar o campo); campos novos não têm role e o publish não os preenche.
• Remover um campo com role avisa o que o publish deixará de preencher.
• Cores válidas: GRAY, BLUE, GREEN, YELLOW, ORANGE, RED, PINK, PURPLE.
• O campo Status já existe em todo Project novo; o preset só troca as opções dele.

Grave a spec efetiva em .planning/github/project-spec.draft.json (o JSON do preset com as mudanças, mais title e visibility).

5. Preview e confirmação

Vou criar:
  Project: "{título}" em {dono} · {visibilidade}
  Campos:  {N} ({lista curta}) · Status: {opções}
  Vínculo: {owner/repo | nenhum}
Confirmar? (s/n)

6. Criação

# preset (editado ou não)
python3 "$GHP" project create --owner "<dono>" --spec .planning/github/project-spec.draft.json \
  --title "<título>" --repo "<owner/repo>"
# ou cópia de modelo
python3 "$GHP" project copy --source-owner "<dono-modelo>" --number <n> --owner "<dono>" \
  --title "<título>" --repo "<owner/repo>"

A saída é JSON com number, url, os campos criados e as views sugeridas. Em seguida:

• renomeie a spec para .planning/github/project-<number>.spec.json;
• grave em .planning/github.json → project: {number, url, spec} (merge);
• se o script falhar no meio, mostre o erro: o Project pode ter sido criado parcialmente — ofereça rodar python3 "$GHP" project fields --owner <dono> --number <n> para ver o que existe. Nunca apague o Project sem pedido explícito.

7. Views (passo manual guiado)

A API do GitHub Projects não cria views. Liste as views do preset como checklist, com o link do Project:

Abra {url} e crie:
- [ ] "Quadro"         layout Board   · Agrupar colunas por Status; filtro Tipo:Feature
- [ ] "Por onda"       layout Table   · Agrupar por Onda; ordenar por Prioridade
- [ ] "Linha do tempo" layout Roadmap · Datas Início/Fim; agrupar por Fase
Dica: marque o Project como template (`gh project mark-template <n> --owner <org>`, só
organizações) para reutilizá-lo depois pela opção 4, já com as views.

8. Próximo

👉 github-publish <roadmap.json>   → popular com issues e dependências
👉 prd-publish <slug> (pwdev-prd)           → a partir de um PRD aprovado

Idioma: responda no idioma de .planning/config.json (lang); sem config, no idioma do usuário. Caminhos <plugin-root>/..., references/, scripts/ e templates/ são relativos à raiz do plugin; nomes de ferramentas e a forma de citar comandos dependem do runtime (references/runtime.md).