---
language: en
title: "Prompt for writing a tutorial or how-to"
description: "Create instructions with requirements, verifiable steps, and troubleshooting, preserving the version and evidence for the procedure."
canonical: "https://tropk.ai/en/resources/prompts/prompt-for-writing-a-tutorial-or-how-to"
last_modified: "2026-10-12T16:14:36.395Z"
---

# Prompt for writing a tutorial or how-to

Reviewed on 2026-10-06.

## Prompt to adapt and use

Enable someone to complete a task and recognize the result of each step.

### Prepare before you begin

COMPANY AND BUSINESS
company: {empresa}
domain: {dominio}
confirmed_offering: {produtos_servicos_capacidades_limites_e_fontes}
business_context: {mercado_regiao_diferenciais_comprovados_e_restricoes}

AUDIENCE AND OBJECTIVE
audience: {perfil_tarefa_conhecimento_inicial_e_restricoes}
main_question: {pergunta_do_leitor}
reader_outcome: {o_que_a_pessoa_deve_conseguir_decidir_ou_fazer}
editorial_objective: {objetivo}
intent_and_stage: {intencao_de_busca_e_etapa_da_decisao}

VOICE AND EDITORIAL CONTEXT
voice: {tom_vocabulario_exemplos_de_estilo_e_termos_a_evitar}
topic_and_entities: {tema_keyword_principal_termos_e_entidades}
inventory: {paginas_existentes_e_decisao_criar_atualizar_ou_consolidar}
contribution: {exemplo_matriz_metodo_ou_dado_proprio_autorizado}
cta: {proxima_acao_pertinente_e_destino_confirmado_ou_nao_aplicavel}

EVIDENCE AND ACCESS
sources: {id_titulo_url_autor_data_de_publicacao_consulta_e_trechos_relevantes}
authorized_data: {dados_definicoes_periodo_metodo_e_permissoes_ou_nao_disponivel}
internal_links: {url_publicada_assunto_e_funcao_do_link}
research_access: {ferramentas_realmente_habilitadas_e_acessos_autorizados_ou_sem_navegacao}
restrictions: {confidencialidade_direitos_prazos_mercado_e_escopo}

task: {tarefa_especifica}
initial_state: {estado_inicial_e_pre_requisitos}
final_result: {sinal_verificavel_de_conclusao}
environment: {sistema_versao_idioma_conta_e_permissoes}
steps_and_evidence: {acoes_locais_entradas_resultados_e_documentacao_ou_teste}
failures_and_recovery: {sintomas_verificacoes_e_correcoes_seguras}

### Delivery format

A. Tutorial in Markdown: objective, requirements, steps, example, validation, and troubleshooting.
B. Table of steps with sources or test evidence.
C. Outstanding environment and technical validation checks.

### Review criteria

• The start, end, version, and prerequisites are explicit.
• Each step specifies the action, location, input, result, and verification.
• Testing and documentation are described according to the actual evidence.
• Troubleshooting addresses relevant symptoms.
• Examples don’t reveal credentials or conceal material effects.

### Modelo

Act as a research and writing assistant for the company provided. Write in Brazilian Portuguese, clearly and in the brand’s voice, for the audience’s task. Produce a draft for human review. Use the full context below, not just the topic.

MODULE 1 — CONTEXT TO COMPLETE
COMPANY AND BUSINESS
company: {empresa}
domain: {dominio}
confirmed_offering: {produtos_servicos_capacidades_limites_e_fontes}
business_context: {mercado_regiao_diferenciais_comprovados_e_restricoes}

AUDIENCE AND OBJECTIVE
audience: {perfil_tarefa_conhecimento_inicial_e_restricoes}
main_question: {pergunta_do_leitor}
reader_outcome: {o_que_a_pessoa_deve_conseguir_decidir_ou_fazer}
editorial_objective: {objetivo}
intent_and_stage: {intencao_de_busca_e_etapa_da_decisao}

VOICE AND EDITORIAL CONTEXT
voice: {tom_vocabulario_exemplos_de_estilo_e_termos_a_evitar}
topic_and_entities: {tema_keyword_principal_termos_e_entidades}
inventory: {paginas_existentes_e_decisao_criar_atualizar_ou_consolidar}
contribution: {exemplo_matriz_metodo_ou_dado_proprio_autorizado}
cta: {proxima_acao_pertinente_e_destino_confirmado_ou_nao_aplicavel}

EVIDENCE AND ACCESS
sources: {id_titulo_url_autor_data_de_publicacao_consulta_e_trechos_relevantes}
authorized_data: {dados_definicoes_periodo_metodo_e_permissoes_ou_nao_disponivel}
internal_links: {url_publicada_assunto_e_funcao_do_link}
research_access: {ferramentas_realmente_habilitadas_e_acessos_autorizados_ou_sem_navegacao}
restrictions: {confidencialidade_direitos_prazos_mercado_e_escopo}

MODULE 2 — FORMAT INPUTS
Format: tutorial or how-to
Objective: Enable someone to complete a task and recognize the result of each step.
task: {tarefa_especifica}
initial_state: {estado_inicial_e_pre_requisitos}
final_result: {sinal_verificavel_de_conclusao}
environment: {sistema_versao_idioma_conta_e_permissoes}
steps_and_evidence: {acoes_locais_entradas_resultados_e_documentacao_ou_teste}
failures_and_recovery: {sintomas_verificacoes_e_correcoes_seguras}

MODULE 3 — EVIDENCE AND LIMITS
Read the supplied texts. If research is enabled and authorized, consult relevant primary sources and record the pages actually read. Without browsing, use the attachments and return a list of checks still pending; don’t say you opened URLs. A competitor’s page can guide research, but it doesn’t substantiate all its claims.
Don’t invent features, prices, data, clients, experiences, tests, credentials, testimonials, citations, or links. Distinguish documented facts, observations, interpretations, and hypothetical examples. Missing information is neither zero nor proof that a feature doesn’t exist. Preserve dates, versions, regions, plans, units, denominators, and material conditions.
Derived numbers require calculations checked with an actual tool or a validated result provided in the inputs. Without this, mark the check as pending; don’t claim to have recalculated.
Don’t expose private data. Use names, images, and statements only with authorization. Don’t copy the wording or the entire sequence from a reference. Preserve human authorship and identify which validations require the subject-matter owner.

MODULE 4 — PRODUCING THE FORMAT
1. Confirm the task, environment, and material requirements.
2. Reconstruct the sequence using the supplied documentation and tests actually performed.
3. Write each step with an action, location, input, expected result, and verification.
4. Present decision paths and troubleshooting by symptom.
5. Include final validation, limitations, and a version-based review trigger. Don’t invent button names, commands, screens, or compatibility.

MODULE 5 — SEO, AEO, AND GEO
Use an H1 that matches the question and body; organize H2s/H3s around reader decisions. Start sections with direct answers when helpful. Each passage should retain enough entity, context, and conditions to be understood on its own. Use terms naturally, without fixed density or artificial repetition. Cite the specific source near the fact it supports; preserve the supplied URL.
Suggest internal links only to confirmed, useful destinations. Don’t force an FAQ, word count, or special schema into every format. Don’t promise rankings or citations. Don’t add authorship, review, publication date, testing, or updates that didn’t happen. The CTA must match the offering and action provided, without a pitch unrelated to the task.

MODULE 6 — OUTPUT AND REVIEW
A. Tutorial in Markdown: objective, requirements, steps, example, validation, and troubleshooting.
B. Table of steps with sources or test evidence.
C. Outstanding environment and technical validation checks.
Also provide: proposed H1, SEO title, description, and slug; a claim map with source, section, and limitation; links used; outstanding checks with impact and next step. Keep this material separate from the publishable body. Don’t publish the draft or claim it has been approved.
Review against the criteria below and mark each as met, needs correction, or not applicable with a reason:
1. The start, end, version, and prerequisites are explicit.
2. Each step specifies the action, location, input, result, and verification.
3. Testing and documentation are described according to the actual evidence.
4. Troubleshooting addresses relevant symptoms.
5. Examples don’t reveal credentials or conceal material effects.
If essential evidence for the central promise is missing, return only the safe portion and state which input prevents completion. Don’t fill the gap with a likely conclusion.

## When to use this prompt

Use a tutorial when the goal is to carry out a specific task. The reader needs to identify a starting point, follow actions in order, and check a final result. A concept explanation can support the steps, but it cannot replace the procedure. Define the task with a verb and evidence of completion: fill in a table, review a file, or configure an option in the specified version.

The environment is part of the instructions. A sequence that is correct for one interface may be wrong for another version, account, or language. The [prompt](/en/resources/glossary/prompt) captures these limitations and distinguishes documented steps from tested ones. Don’t write “we tested” when you only read the documentation. Also, don’t ask for imagined screenshots: an illustrative image must be identified as such, and the written explanation must remain sufficient.

[SEO](/en/resources/glossary/seo) organizes the page for people who search; [AEO](/en/resources/glossary/aeo) focuses on clear answers; [GEO](/en/resources/glossary/geo) addresses discoverability in generative responses. In this resource, all three are treated as writing, research, and review practices: address the task, name entities, preserve context, and make evidence verifiable. A prompt helps prepare the draft. It doesn’t substantiate facts or guarantee rankings, recommendations, or citations by AI.

## Prepare your inputs before writing

Gather the version, permissions, initial state, required materials, and expected result. Include official documentation and execution records when available. For each step, note the action, location, input, success indicator, and how to verify it. If an action depends on access that has not yet been granted, the tutorial can explain the requirement without pretending the reader already has access.

Treat troubleshooting as part of the task. Select relevant symptoms and their evidence, such as a field missing in a particular version or a result that doesn’t match the input. Avoid a generic list of errors unrelated to the procedure. When a fix has a material effect, state the condition and the safe alternative. Keep sensitive data, tokens, and client files out of examples.

## How to create and review the content

Ask for numbered steps with intermediate checks. An instruction like “configure the report” leaves the work unclear. The step should say where to act, what information to enter, and what to look for afterward. For alternative paths, explain which condition determines each one. Include time and effort only when there’s a basis for them; an invented estimate doesn’t make the guidance more practical.

After drafting, repeat the procedure in the described environment when authorized. If that isn’t possible, check against the sources and document the status. Also check the recovery guidance: can the reader recognize a failure and know when to stop? End the tutorial with a check of the promised result and an update trigger, such as a change to the version, button, rule, or requirement.

## Example of a completed prompt

Example of a completed prompt: explaining how to fill in a table for observing [AI responses](/en/resources/glossary/ai-response). Initial state: an empty table and provided definitions. Steps: record the question, interface, date, response, and classification; separate invalid observations; check the final set. Result: complete records with sources. The example doesn’t need a fictional interface or claim that the table automatically detects why something is missing.

## How to use the complete prompt

Copy the complete prompt and replace the fields in braces before submitting it. Attach the source content as well as the URLs: a model without browsing cannot check a link on its own. Use “not available” when information is missing, and explain why. Generate a first version, check what’s outstanding, and correct the inputs before requesting a review. Keep public-facing text separate from research notes.

## Check the result

- The start, end, version, and prerequisites are explicit.
- Each step specifies the action, location, input, result, and verification.
- Testing and documentation are described according to the actual evidence.
- Troubleshooting addresses relevant symptoms.
- Examples don’t reveal credentials or conceal material effects.

## Sources and references

- [Create helpful, reliable, people-first content](<https://developers.google.com/search/docs/fundamentals/creating-helpful-content>) — Google Search Central
- [AI features and your site](<https://developers.google.com/search/docs/appearance/ai-features>) — Google Search Central
- [Guidance about content created with generative AI](<https://developers.google.com/search/docs/fundamentals/using-gen-ai-content>) — Google Search Central

## Continue a leitura

- [Prompt for writing a Q&A article](</en/resources/prompts/prompt-for-writing-a-q-and-a-article>)
- [Prompt for writing an informational article](</en/resources/prompts/prompt-for-writing-an-informational-article>)
- [Prompt for writing a guide or pillar page](</en/resources/prompts/prompt-for-writing-a-guide-or-pillar-page>)
- [AI discovery strategy](</en/product/strategy>)
- [Resources](</en/resources>)

## About the author

[Luiz Gardelin](</en/team/luiz-gardelin>)

Luiz Gardelin is the founder of Tropk.ai and works in GEO/AEO, product vision, strategy, and growth, helping brands understand and improve their presence in AI responses.

---

[All pages in Markdown](<https://tropk.ai/sitemap.md>)
