@jaimevalasek/aioson 1.7.2 → 1.8.0

package/template/.aioson/skills/process/secure-tdd/references/node-express.md

@@ -0,0 +1,91 @@
+# secure-tdd reference: Node / Express
+
+Use this when the feature runs on Node.js request handlers, Express routes, or service boundaries tested with `node:test`.
+
+## Preferred runners
+
+- `node:test`
+- `supertest` when the project already exposes an HTTP app
+
+If the project is not HTTP-based, keep the same adversarial logic at the boundary-function level.
+
+## Write first
+
+Start with the smallest set of failing tests that proves the server rejects unsafe behavior.
+
+Priority order:
+1. auth bypass / missing auth
+2. cross-user access (IDOR / ownership)
+3. invalid payload beyond server-side limits
+4. unsafe external URL or redirect target
+5. concurrent mutation / race / double-submit when the feature mutates critical state
+
+## Minimum patterns
+
+### Auth bypass / ownership
+
+Write a test that proves user A cannot read, mutate, or delete user B's resource.
+
+```js
+it('returns 403 when accessing another users resource', async () => {
+  const token = await loginAs(userA);
+  const res = await request(app)
+    .get(`/api/resources/${userBResource.id}`)
+    .set('Authorization', `Bearer ${token}`);
+  assert.equal(res.status, 403);
+});
+```
+
+### Server-side validation
+
+Write a test that sends a forged payload bigger or riskier than the UI should allow.
+
+```js
+it('rejects payloads that exceed server-side limits', async () => {
+  const res = await request(app)
+    .post('/api/resources')
+    .send({ title: 'x'.repeat(10_000) });
+  assert.equal(res.status, 422);
+});
+```
+
+### External URL sanitization
+
+Write a test that sends an unsafe URL and expects rejection or strict allowlisting.
+
+```js
+it('rejects unsafe external urls', async () => {
+  const res = await request(app)
+    .post('/api/redirects')
+    .send({ target: 'javascript:alert(1)' });
+  assert.equal(res.status, 422);
+});
+```
+
+### Race condition / double-submit
+
+When the feature changes critical state, write two competing calls and assert one of them is rejected or serialized correctly.
+
+```js
+it('prevents duplicate critical mutations under concurrency', async () => {
+  const [a, b] = await Promise.all([
+    request(app).post('/api/refunds').send({ paymentId }),
+    request(app).post('/api/refunds').send({ paymentId })
+  ]);
+  assert.equal([a.status, b.status].filter((s) => s === 200).length, 1);
+});
+```
+
+## Control mapping
+
+- `SEC-SBD-01`: payload size / field limit tests
+- `SEC-SBD-03`: auth bypass and IDOR tests
+- `SEC-SBD-04`: concurrency / double-submit tests
+- `SEC-SBD-06`: external URL rejection / allowlist tests
+- `SEC-SBD-08`: generic auth error / rate-limiting tests when applicable
+
+## Avoid
+
+- trusting frontend validation as evidence
+- writing only happy-path tests for sensitive endpoints
+- creating broad fixtures when a narrow reproduction is enough

package/template/.aioson/skills/process/secure-tdd/references/planned-stacks.md

@@ -0,0 +1,33 @@
+# secure-tdd reference: planned stacks
+
+These stacks are in v1 as planned or minimal references only. They should not block the release of `secure-tdd`.
+
+## Laravel / Pest
+
+- Preferred runner: Pest
+- Minimum attacks to cover: IDOR / policy bypass, server-side validation, unsafe upload, double-submit on critical state
+- Minimal pattern: feature tests hitting routes or actions with unauthorized users and invalid payloads
+
+## Django / Pytest
+
+- Preferred runner: pytest
+- Minimum attacks to cover: auth bypass, object-level access control, forged form / serializer payloads, unsafe redirects
+- Minimal pattern: request-level tests plus service-level tests for critical state transitions
+
+## Rails / RSpec
+
+- Preferred runner: RSpec
+- Minimum attacks to cover: ownership checks, server-side validation, double-submit, redirect sanitization
+- Minimal pattern: request specs for auth/ownership and model/service specs for critical state
+
+## FastAPI / Pytest
+
+- Preferred runner: pytest
+- Minimum attacks to cover: auth bypass, Pydantic boundary validation, IDOR, external URL handling, concurrent mutation
+- Minimal pattern: TestClient request tests plus async service tests when concurrency matters
+
+## Rule for all planned stacks
+
+- Do not invent a full template until the stack is actively needed.
+- Keep the first implementation narrow: runner expectation, attacks to cover, and the minimum assertion style.
+- If a future phase expands one of these stacks, split it into its own dedicated reference file.

package/template/.aioson/skills/static/harness-validate/SKILL.md

@@ -0,0 +1,46 @@
+# Skill: Harness-Driven Validation (pt-BR)
+
+> **Uso:** Implementação e Verificação Contratual (Padrão Nautilus).
+> **Agentes:** @dev, @validator.
+> **Contexto:** Projetos MEDIUM ou com `harness-contract.json` presente.
+
+## Missão
+Garantir que o ciclo de implementação do implementador (@dev) seja fechado com uma validação imparcial do validador (@validator) antes de qualquer entrega ser considerada concluída.
+
+## Fluxo de Trabalho do @dev (Harness-Aware)
+
+### 1. Início de Tarefa
+Antes de escrever o primeiro arquivo de uma feature, verifique se o Harness está inicializado:
+```bash
+aioson harness:init . --slug=<feature-slug>
+```
+Isso criará o contrato stube em `.aioson/plans/<slug>/harness-contract.json`.
+
+### 2. Implementação com Feedback
+Sempre que concluir um slice lógico (ex: uma migration, um service, uma rota), execute a validação:
+```bash
+aioson harness:validate . --slug=<feature-slug>
+```
+O sistema invocará o `@validator` em um processo separado. O resultado será injetado no seu `progress.json`.
+
+### 3. Recuperação de Falhas (Circuit Breaker)
+Se a validação falhar:
+- Leia o campo `last_error` em `progress.json`.
+- Corrija apenas o ponto indicado pelo erro.
+- Re-valide imediatamente.
+- **Aviso:** Se falhar repetidamente (conforme `error_streak_limit`), o sistema abrirá o circuito (`OPEN`) e você não poderá continuar sem a intervenção explícita do usuário.
+
+## Done Gate
+O `@dev` não deve tentar marcar a feature como `done` em `features.md` manualmente. O gateway bloqueará a alteração se:
+1. Um `harness-contract.json` existir.
+2. E o `progress.json` não tiver `ready_for_done_gate: true`.
+
+## Melhores Práticas
+- **Commits Atômicos:** Faça commit após cada `harness:validate` bem-sucedido.
+- **Contratos Binários:** No contrato, prefira critérios que possam ser validados mecanicamente (arquivos, assinaturas, testes).
+- **Isolamento de Contexto:** Nunca tente "explicar" seu código para o `@validator` através de comentários. O validador deve julgar apenas o arquivo final e o contrato.
+
+---
+## Referências
+- [Doc] Padrão Nautilus & PBQ — `.aioson/docs/integrations/harness-engineering.md`
+- [CLI] Comandos `harness:init` e `harness:validate` — `/help`

package/template/.aioson/skills/static/web-research-cache.md

@@ -2,6 +2,7 @@
 
 > Load this file when you are about to run a web search.
 > Check the cache first. Save results after. Never search twice for the same thing.
+> Treat `researchs/` as a temporary shared evidence layer for current and nearby sessions.
 
 ## Cache location
 
@@ -93,6 +94,7 @@ If all findings are `confirmed`:
 | Agent | Reads cache | Writes cache |
 |---|---|---|
 | @sheldon | ✅ | ✅ — primary writer for PRD technical decisions |
+| @squad | ✅ | ✅ — lightweight domain/pattern scouting for squad packages |
 | @analyst | ✅ | ✅ — technology and integration validation |
 | @architect | ✅ | ✅ — infrastructure and library trade-offs |
 | @dev | ✅ | ✅ — library docs and implementation patterns |
@@ -109,4 +111,5 @@ If all findings are `confirmed`:
 - **Never show `confirmed` findings** — they add noise without value
 - **Never modify the PRD/plan without user confirmation** — surface findings, let the user decide
 - **Cache is shared across all agents** — if another agent already searched the same topic this week, use their result
+- `@product`, `@sheldon`, and `@squad` should derive short keyword phrases from the active task and scout the cache before finalizing substantial output
 - The user decides whether to act on findings. Agents surface, humans decide.

package/template/.aioson/tasks/squad-create.md

@@ -16,6 +16,12 @@
 
 ### Passo 1 — Ler blueprint
 Leia `.aioson/squads/.designs/<slug>.blueprint.json` e valide que os campos obrigatórios existem (slug, name, problem, goal, mode, executors).
+Se existirem, preserve também:
+- `locale_scope`
+- `locale_rationale`
+- `domainClassification`
+- `investigation`
+- `sourceDocs`
 
 ### Passo 2 — Criar estrutura de diretórios
 ```
@@ -48,7 +54,11 @@ Leia o campo `uiCapability` do blueprint. Se ausente, trate como `mode: none`.
 
 **Se `mode = executor`:**
 1. Execute os mesmos passos de skills acima (executor depende das skills)
-2. Gere o arquivo `.aioson/squads/{slug}/agents/ui-specialist.md` usando o template do agente `@ui-specialist` definido em `squad.md` (seção "Visual & UI capability detection → Option 2")
+2. Gere o arquivo `.aioson/squads/{slug}/agents/ui-specialist.md` seguindo `.aioson/docs/squad/package-contract.md`:
+   - usar a mesma estrutura dos demais executores permanentes
+   - missão focada em UI, layout, componentes e direção visual
+   - output esperado: `ui-spec.md` e, quando fizer sentido, HTML/entregável visual
+   - deixar explícito quando delegar contexto de negócio de volta ao `@orquestrador`
 3. Registre o executor no `squad.manifest.json` com `modelTier: powerful` e `behavioralProfile: compliant-dominant`
 4. Adicione ao routing guide do orquestrador: "Visual / UI / layout requests → @ui-specialist"
 
@@ -61,8 +71,22 @@ Em todos os casos, salve `uiCapability` no `squad.manifest.json`.
 ### Passo 3 — Gerar squad.manifest.json
 Monte o manifesto a partir do blueprint. O JSON deve seguir o schema `squad-manifest.schema.json`. Copie executors, skills, mcps, genomes, contentBlueprints do blueprint. Adicione package paths e rules.
 
+Persistência obrigatória:
+- `locale_scope`: usar `"universal"` por padrão quando o blueprint não trouxer valor explícito
+- `locale_rationale`: copiar quando existir
+- `domainClassification`: copiar quando existir
+- `investigation`: copiar quando existir
+- `sourceDocs`: copiar quando existir
+
 ### Passo 4 — Gerar agents.md (manifesto textual)
-Siga o formato existente no squad.md atual:
+Siga `.aioson/docs/squad/package-contract.md` na seção `agents/agents.md`.
+
+Regras adicionais para o manifesto textual:
+- agrupe executores por tipo quando houver workers, clones, assistants ou human-gates
+- se uma categoria não existir, omita a seção em vez de deixar placeholder
+- reflita `locale_scope`, skills, MCPs e política de revisão quando isso mudar o comportamento real do squad
+
+Formato mínimo:
 ```markdown
 # Squad <name>
 
@@ -86,28 +110,31 @@ Siga o formato existente no squad.md atual:
 ```
 
 ### Passo 5 — Gerar cada executor
-Para cada executor no blueprint, crie `.aioson/squads/<slug>/agents/<executor-slug>.md` seguindo o template atual do squad.md (seção "Step 2 — Generate each specialist agent"):
+Para cada executor no blueprint, crie `.aioson/squads/<slug>/agents/<executor-slug>.md` seguindo `.aioson/docs/squad/package-contract.md` na seção `Executor generation`:
 - Header com `# Agent @<slug>` + bloco ACTIVATED
 - Mission, Quick context, Active genomes, Focus, Response standard, Hard constraints, Output contract
+- Se `locale_scope` for locale-specific, escreva o prompt no idioma do locale; identificadores de código continuam em inglês
 
 ### Passo 6 — Gerar orquestrador
-Crie `.aioson/squads/<slug>/agents/orquestrador.md` seguindo o template atual (seção "Step 3 — Generate the orchestrator").
+Crie `.aioson/squads/<slug>/agents/orquestrador.md` seguindo `.aioson/docs/squad/package-contract.md` na seção `Orchestrator prompt`.
+Se `uiCapability.mode = executor`, inclua no routing guide que demandas visuais vão para `@ui-specialist`.
 
 ### Passo 7 — Gerar docs
 - `docs/design-doc.md`: resumo do design derivado do blueprint
 - `docs/readiness.md`: estado de readiness derivado do blueprint
 
 ### Passo 8 — Registrar nos gateways
-Atualize `CLAUDE.md` e `AGENTS.md` no root do projeto conforme as regras existentes no squad.md.
+Atualize `CLAUDE.md` e `AGENTS.md` no root do projeto conforme `.aioson/docs/squad/package-contract.md` na seção `Gateway registration`.
 
 ### Passo 9 — Salvar metadata
-Salve `.aioson/squads/<slug>/squad.md` no formato existente.
+Salve `.aioson/squads/<slug>/squad.md` conforme `.aioson/docs/squad/package-contract.md` na seção `Squad metadata`.
+Inclua `locale_scope`, `locale_rationale`, `investigation` e `sourceDocs` quando existirem.
 
 ### Passo 10 — Rodar validate
 Após criar tudo, execute mentalmente a task squad-validate (leia `.aioson/tasks/squad-validate.md`) para verificar que o pacote está consistente.
 
 ### Passo 11 — Warm-up round
-Siga as regras existentes no squad.md: mostre cada especialista com problem reading, initial recommendation, main risk, suggested next step.
+Siga `.aioson/docs/squad/workflow-quality.md` na seção `Confirmation, coverage, and warm-up`: mostre cada especialista com problem reading, initial recommendation, main risk e suggested next step.
 
 ## Saída
 - Pacote completo em `.aioson/squads/<slug>/`
@@ -116,6 +143,6 @@ Siga as regras existentes no squad.md: mostre cada especialista com problem read
 
 ## Regras
 - SEMPRE leia o blueprint antes de gerar
-- SIGA os templates de executor e orquestrador do squad.md original
+- SIGA `.aioson/docs/squad/package-contract.md` e `.aioson/docs/squad/workflow-quality.md`
 - MANTENHA o HTML deliverable após cada rodada (regra existente)
 - NÃO pule o warm-up — é mandatório

package/template/.aioson/tasks/squad-design.md

@@ -13,7 +13,25 @@
 
 ## Processo
 
-### Passo 0 — Verificar artisan input e templates disponíveis
+### Passo 0 — Verificar contexto do projeto, artisan input e templates disponíveis
+
+**0A — Artifacts do pipeline AIOSON**
+
+Antes de perguntar qualquer coisa, procure:
+- `.aioson/context/implementation-plan-*.md`
+- `.aioson/context/requirements-*.md`
+- `.aioson/context/architecture.md`
+- `.aioson/context/prd.md` e `prd-*.md`
+
+Se encontrar arquivos claramente relevantes para o squad atual:
+1. Leia primeiro o `implementation-plan` quando existir
+2. Depois leia `requirements`, `architecture` e `prd` relevantes
+3. Extraia: domain, goal, output type, constraints, expected behaviors, risks e sinais de done
+4. Registre os caminhos consumidos em `sourceDocs`
+5. NÃO repita perguntas cujas respostas já estão explícitas nesses artifacts
+6. Se houver mais de um conjunto possível de artifacts, faça uma única pergunta curta de desambiguação
+
+**0B — Artisan input**
 
 Se o usuário forneceu `--from-artisan <id>`:
 1. Procure `.aioson/squads/.artisan/<id>.md`
@@ -22,7 +40,7 @@ Se o usuário forneceu `--from-artisan <id>`:
 4. Use como base para o blueprint — pule para o Passo 5 (calcular readiness)
 5. Mostre ao usuário: "Li o PRD do Artisan. Posso gerar o blueprint com base nele — quer ajustar algo?"
 
-Caso contrário, verifique templates:
+**0C — Templates**
 Verifique se existe `.aioson/templates/squads/`. Se existir, liste os templates disponíveis e pergunte:
 "Quer partir de um template? Opções: content-basic, research-analysis, software-delivery, media-channel — ou começar do zero."
 Se o usuário escolher um template, leia o `template.json` e use como base para o blueprint (executores, content blueprints, mode).
@@ -37,6 +55,28 @@ Pergunte em um bloco só (não faça múltiplas rodadas):
 
 Se o usuário já forneceu contexto suficiente (texto, docs, imagens), infira as respostas e siga em frente. Pergunte somente se há lacunas materiais.
 
+### Passo 1.5 — Gate de classificação de domínio + locale scope
+
+Antes de definir executores, classifique o domínio usando `.aioson/docs/squad/domain-classification.md`:
+
+- **Tier 1 — regulado:** investigação via `@squad investigate` / `@orache` é obrigatória. Não finalize o blueprint sem relatório.
+- **Tier 2 — especializado:** recomende fortemente investigação. Se o usuário recusar, registre a limitação em `assumptions` e `risks`.
+- **Tier 3 — comum:** prossiga sem criar fricção desnecessária.
+
+Se já existir investigação relevante, reutilize o relatório em vez de pedir uma nova.
+
+Depois da classificação:
+- decida `locale_scope` com base em `.aioson/rules/agent-language-policy.md` quando a rule existir
+- sugira `universal` por padrão
+- se o squad for claramente local, confirme um locale específico (`pt-BR`, `es-MX`, etc.) e registre `locale_rationale`
+- capture no blueprint:
+  - `domainClassification.tier`
+  - `domainClassification.rationale`
+  - `domainClassification.regulations` quando existirem
+  - `domainClassification.investigationPolicy`
+  - `locale_scope`
+  - `locale_rationale` quando aplicável
+
 ### Passo 2 — Derivar design-doc mental
 Antes de definir executores, consolide:
 - Problema que está sendo resolvido
@@ -45,6 +85,9 @@ Antes de definir executores, consolide:
 - Risks e assumptions
 - Skills e docs que precisam entrar no contexto
 - Mode do squad (content | software | research | mixed)
+- Source docs consumidos
+- Investigation aplicada e o que ela muda no design
+- Locale scope do squad
 
 ### Passo 3 — Definir executores
 Determine 3-5 roles especializados. Para cada executor, defina:
@@ -97,6 +140,7 @@ Avalie cada dimensão:
 - contextReady: há contexto suficiente?
 - blueprintReady: o blueprint está completo?
 - generationReady: dá para gerar os executores?
+- se `domainClassification.tier = tier-1-regulated`: generationReady = false enquanto não houver `investigation`
 
 ### Passo 6 — Gerar blueprint JSON
 Salve o blueprint em `.aioson/squads/.designs/<slug>.blueprint.json`
@@ -137,6 +181,8 @@ Se tudo OK: prosseguir para Passo 7.
 Mostre ao usuário:
 - Executores propostos com roles
 - Content blueprints definidos
+- Tier de domínio e política de investigação
+- Locale scope
 - Assumptions feitas
 - Risks identificados
 - Readiness status
@@ -156,3 +202,5 @@ Pergunte se quer ajustar algo antes de criar.
 - NÃO crie o pacote do squad aqui — isso é responsabilidade da task create
 - NÃO pule o blueprint — ele é obrigatório
 - MANTENHA o blueprint leve — o LLM preenche lacunas na fase create
+- NÃO ignore `implementation-plan` / `requirements` relevantes quando existirem
+- NÃO bypass o gate de domínio regulado

package/template/.aioson/tasks/squad-investigate.md

@@ -25,6 +25,14 @@ Passe o contexto do domínio coletado pelo @squad.
 ### Passo 3 — Receber relatório
 @orache salva o relatório em `squad-searches/`.
 
+### Passo 3.5 — Extrair payload de integração
+Do relatório, extraia explicitamente:
+- regulações / obrigações
+- vocabulário de domínio
+- anti-patterns
+- benchmarks de qualidade
+- padrões estruturais / de workflow
+
 ### Passo 4 — Validar completude
 Verifique que o relatório cobre pelo menos 4 das 7 dimensões.
 Se não cobrir, pergunte ao usuário se quer aprofundar.
@@ -32,11 +40,16 @@ Se não cobrir, pergunte ao usuário se quer aprofundar.
 ### Passo 5 — Integrar com design
 Se esta task foi invocada do flow do @squad:
 - Retorne o path do relatório para o @squad
-- O @squad usa o relatório para enriquecer o blueprint
+- Registre no blueprint o objeto `investigation`
+- Use regulações para hard constraints, human gates e review criteria
+- Use anti-patterns para checklist e `vetoConditions`
+- Use benchmarks para qualidade, warm-up e score de cobertura
+- Use vocabulário e padrões estruturais para executores, workflow e content blueprints
 
 ## Saída
 - Relatório de investigação salvo em `squad-searches/`
 - Path do relatório disponível para o @squad design
+- Payload de integração disponível para blueprint/checklist/workflow
 
 ## Regras
 - NÃO gere o squad aqui — isso é responsabilidade da task create

package/template/.claude/commands/aioson/agent/committer.md

@@ -0,0 +1,5 @@
+---
+description: "AIOSON — Professional Git commit generation from changes and context"
+---
+
+Read `.aioson/agents/committer.md` and follow all instructions. $ARGUMENTS

package/template/.claude/commands/aioson/agent/copywriter.md

@@ -0,0 +1,5 @@
+---
+description: "AIOSON — Conversion-focused marketing copy"
+---
+
+Read `.aioson/agents/copywriter.md` and follow all instructions. $ARGUMENTS

package/template/.claude/commands/aioson/agent/cypher.md

@@ -0,0 +1,5 @@
+---
+description: "AIOSON — Pre-production briefings and planning"
+---
+
+Read `.aioson/agents/cypher.md` and follow all instructions. $ARGUMENTS

package/template/.claude/commands/aioson/agent/pair.md

@@ -0,0 +1,5 @@
+---
+description: "AIOSON — Pair programming partner (alias: deyvin)"
+---
+
+Read `.aioson/agents/deyvin.md` and follow all instructions. $ARGUMENTS

package/template/.claude/commands/aioson/agent/validator.md

@@ -0,0 +1,5 @@
+---
+description: "AIOSON — Technical validation against success contract"
+---
+
+Read `.aioson/agents/validator.md` and follow all instructions. $ARGUMENTS

package/template/.gemini/commands/aios-analyst.toml

@@ -1,4 +1,7 @@
-name = "aios-analyst"
 description = "Requirements analysis"
-instruction_file = ".aioson/agents/analyst.md"
-requires_context = [".aioson/context/project.context.md"]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/analyst.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-architect.toml

@@ -1,7 +1,8 @@
-name = "aios-architect"
 description = "Project architecture"
-instruction_file = ".aioson/agents/architect.md"
-requires_context = [
-  ".aioson/context/project.context.md",
-  ".aioson/context/discovery.md"
-]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/context/discovery.md }
+@{ .aioson/agents/architect.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-committer.toml

@@ -0,0 +1,7 @@
+description = "Professional Git commit generation"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/committer.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-copywriter.toml

@@ -0,0 +1,7 @@
+description = "Conversion-focused marketing copy"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/copywriter.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-cypher.toml

@@ -0,0 +1,7 @@
+description = "Pre-production briefings and planning"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/cypher.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-dev.toml

@@ -1,8 +1,9 @@
-name = "aios-dev"
 description = "Development"
-instruction_file = ".aioson/agents/dev.md"
-requires_context = [
-  ".aioson/context/project.context.md",
-  ".aioson/context/discovery.md",
-  ".aioson/context/architecture.md"
-]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/context/discovery.md }
+@{ .aioson/context/architecture.md }
+@{ .aioson/agents/dev.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-deyvin.toml

@@ -1,6 +1,7 @@
-name = "aios-deyvin"
 description = "Continuity pair programming"
-instruction_file = ".aioson/agents/deyvin.md"
-requires_context = [
-  ".aioson/context/project.context.md"
-]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/deyvin.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-discovery-design-doc.toml

@@ -1,4 +1,7 @@
-name = "aios-discovery-design-doc"
 description = "Discovery and living design doc"
-instruction_file = ".aioson/agents/discovery-design-doc.md"
-requires_context = [".aioson/context/project.context.md"]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/discovery-design-doc.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-genome.toml

@@ -0,0 +1,7 @@
+description = "Domain genome creation and application"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/genome.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-neo.toml

@@ -1,4 +1,6 @@
-name = "aios-neo"
 description = "System router — see the full picture, get guided to the right agent"
-instruction_file = ".aioson/agents/neo.md"
-requires_context = []
+prompt = """
+@{ .aioson/agents/neo.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-orache.toml

@@ -0,0 +1,7 @@
+description = "Domain investigation and strategic research"
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/orache.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-orchestrator.toml

@@ -1,8 +1,9 @@
-name = "aios-orchestrator"
 description = "Multi-agent orchestration"
-instruction_file = ".aioson/agents/orchestrator.md"
-requires_context = [
-  ".aioson/context/discovery.md",
-  ".aioson/context/architecture.md",
-  ".aioson/context/prd.md"
-]
+prompt = """
+@{ .aioson/context/discovery.md }
+@{ .aioson/context/architecture.md }
+@{ .aioson/context/prd.md }
+@{ .aioson/agents/orchestrator.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-pair.toml

@@ -1,6 +1,7 @@
-name = "aios-pair"
 description = "Compatibility alias for aios-deyvin"
-instruction_file = ".aioson/agents/deyvin.md"
-requires_context = [
-  ".aioson/context/project.context.md"
-]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/agents/deyvin.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-pm.toml

@@ -1,8 +1,9 @@
-name = "aios-pm"
 description = "Lightweight PRD"
-instruction_file = ".aioson/agents/pm.md"
-requires_context = [
-  ".aioson/context/project.context.md",
-  ".aioson/context/discovery.md",
-  ".aioson/context/architecture.md"
-]
+prompt = """
+@{ .aioson/context/project.context.md }
+@{ .aioson/context/discovery.md }
+@{ .aioson/context/architecture.md }
+@{ .aioson/agents/pm.md }
+
+{{args}}
+"""

package/template/.gemini/commands/aios-product.toml

@@ -1,4 +1,6 @@
-name = "aios-product"
 description = "Conversational product wizard — prd.md"
-instruction_file = ".aioson/agents/product.md"
-requires_context = []
+prompt = """
+@{ .aioson/agents/product.md }
+
+{{args}}
+"""