manage-context-template

name

manage-context-template

description

Define and manage the structure of Nekt Context documents — the field set, fill modes, naming convention, annotation grammar, and the "reference, don't duplicate" authoring rule that every per-client (or per-domain) doc follows. Use when the user wants to see, change, or standardize what a Context document should contain, or save a reusable team template — e.g. "quais campos um documento de contexto deve ter", "mudar a estrutura dos documentos de contexto", "customizar o template de contexto", "padronizar o contexto dos clientes", "salvar um template padrão pro time", "manage the context template", "what should a context doc contain", "change the context document structure". This skill owns the canonical definition that build-context and edit-context load. Reads any saved team template via get_semantic_context and persists one (opt-in) via create_context_document / update_context_document.

Manage Context Template

A Nekt Context document follows a consistent structure — a field set, how each field is filled, a naming convention, an annotation grammar, and one core rule: reference, don't duplicate. This skill owns that definition and lets the user view, customize, and standardize it. build-context (bulk-creates docs) and edit-context (fills gaps) load this skill's reference files as their source of truth — so changing the structure here changes it everywhere, and the two skills stay consistent.

Respond in the user's language (pt-BR or English). Examples below are pt-BR because Nekt's user base is Brazilian — mirror whatever the user writes.

Prerequisite

The definition lives in this skill's reference files, so viewing and customizing the structure needs no tools. To read back or save a reusable team template, the Nekt MCP must be connected (get_semantic_context, create_context_document, update_context_document). If a save is requested and those tools aren't available, tell the user to connect the Nekt MCP and skip the save.

Reference files (read before presenting or editing the structure)

• references/response-style.md — how these skills talk to the user (brevity, summaries-not-dumps, one checkpoint). Owned here and loaded by the other skills. Read first.
• references/client-context-template.md — the default field set, how each field is filled (auto / reference / knowledge / manual), worked examples, and a skeleton.
• references/context-doc-authoring.md — the reference, don't duplicate principle, the naming convention, the annotation grammar (@table:: / @field:: / @source:: / @layer:: / …), structure rules, and a skeleton.

The default sections are a business‑immersion layout (Visão do Negócio): Imersão no Negócio (Modelo de Negócio · Produtos & Ofertas · Forças & Fraquezas · Avatar · Indicadores & KPIs), Análise de Mercado (Concorrência · Tendências do Setor · Oportunidades & Ameaças), and Diagnóstico de Marketing (Redes Sociais · Mídia Paga · Reputação Digital · Website) — treat them as a suggestion to present for approval, not a fixed schema.

Workflow

1. Show the current structure

Read the reference files first (response-style, then the template + authoring rules). Then establish what the active template is:

• Probe for a saved team template: get_semantic_context("[Template] Client Context"). If a returned documents[].name normalizes-equal to [Template] Client Context, present that as the active template.
• Otherwise present the default field set from references/client-context-template.md.

Present compactly: name the sections in one line (Imersão no Negócio · Análise de Mercado · Diagnóstico de Marketing — com subseções de modelo de negócio, avatar, KPIs, mídia paga, etc.) and offer "quer ver os campos de alguma seção em detalhe?" — don't dump the full field-by-field table unless asked. Note, where relevant, which sections the data tends to fill (paid-media tables → Mídia Paga; assinaturas / receita → Indicadores & KPIs; CRM / base → Modelo de Negócio / Avatar).

2. Customize

Let the user add, remove, rename, or reorder fields and sections; iterate until they approve ("Essa estrutura funciona ou quer ajustar algum campo?"). Keep the authoring rules valid as you go — don't let a customization break them:

• Naming convention: Cliente — <Nome> / Client — <Name>, or Domínio — <Nome> / Domain — <Name> (em dash) — so re-runs and edit-context can find docs by name.
• Annotation grammar: every annotation uses :: after the type tag (@table::Trusted::orders, @field::Raw::orders.total).
• Reference, don't duplicate: fields whose value lives in a table stay as pointers (@table:: / @field::), never copied values.

One shared structure keeps every client/domain comparable — but it stays one document per client (a shared structure, never a shared document), even when every doc is identical in shape.

3. Save as a reusable team template (opt-in)

If the user wants the whole team to reuse the agreed structure, persist it as a Context document named [Template] Client Context:

• New: create_context_document(name="[Template] Client Context", content=…, confirm=True) after showing a preview.
• Existing (a doc came back in step 1): update_context_document(doc_id=…, name="[Template] Client Context", content=…, confirm=True).

This is opt-in — skip by default to keep the semantic layer clean. Saving/updating is an explicit checkpoint: preview, then confirm.

4. Hand back to creation / completion

The template is the input to the other skills — this skill doesn't create per-client docs itself. With an approved structure:

• build-context discovers clients/domains and creates one Context document each, auto-filling what the data supports.
• edit-context <cliente> fills the judgment-call gaps (objetivos, KPIs, regras de negócio).

Offer to continue into build-context, or tell the user to run /build-context when ready.

Key behaviors

• Single source of truth. This skill's references define the Context-doc structure and the shared response style (response-style.md); build-context, edit-context, and agency-onboarding load them via ../manage-context-template/references/…. Change them here, not in those skills.
• Keep chat tight. Present the structure compactly (section names, details on request) and confirm in one checkpoint — see response-style.md.
• Reference, don't duplicate. A doc is a map to the data plus the knowledge the schema can't carry — table-backed facts are pointers, written-out values are reserved for what isn't in any table (goals, KPIs, business rules, formulas).
• Confirm before writing. Saving or updating the [Template] Client Context doc is an explicit, opt-in checkpoint.
• One entity per document. The template describes a single client/domain — never blend.