> For the complete documentation index, see [llms.txt](https://docs.airops.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.airops.com/docs/es/acciones/playbooks/best-practices.md). # Mejores prácticas Orientación práctica para crear Playbooks confiables Usa estas prácticas para hacer que los Playbooks sean más fáciles de ejecutar, revisar y mejorar. ## Empieza con el Kit de marca y la cobertura de prompts Un Kit de marca actual y una cobertura de prompts completa son las dos palancas de calidad más importantes. Confirma ambos antes de optimizar la estructura del Playbook. ## Empieza con menos instrucciones Dale al agente la orientación suficiente para entender el objetivo y luego añade restricciones donde necesites un comportamiento predecible. Las instrucciones demasiado prescriptivas pueden reducir la capacidad del agente para razonar sobre casos límite. ## Organiza las Secciones por fase Usa fases como **Investigación**, **Borrador**, y **Revisar**. Evita organizar las Secciones en torno a personas, como "Sección del estratega" o "Sección del editor". La estructura basada en fases es más fácil de reutilizar y más fácil de revisar. ## Da formato a cada Sección de manera coherente Dale a cada Sección una estructura interna predecible para que el agente entienda el objetivo, el revisor pueda examinar el trabajo rápidamente y las Secciones posteriores sepan qué Artefacto usar. Una Sección sólida suele incluir: * **Objetivo:** Una o dos frases que definan qué debe lograr esta Sección. * **Entradas y referencias:** Los campos de Entradas, Artefactos, Kit de marca, Herramientas o Bases de conocimientos que la Sección debe usar. Insértalos con el menú de barra inclinada cuando sea posible. * **Instrucciones:** Pasos numerados para el trabajo que el agente debe realizar. Mantén el foco en las decisiones, las restricciones y las preferencias de fuentes. * **Salida:** El Artefacto que la Sección debe escribir, además del formato requerido, como un informe en Markdown, un mapa JSON o un artículo final. Usa el mismo patrón en todas las Secciones. Por ejemplo, una Sección de investigación podría indicar el objetivo, hacer referencia al prompt objetivo y al Kit de marca, enumerar los pasos de investigación y luego escribir los hallazgos en **AI & Google Results.md**. Una Sección de redacción podría hacer referencia a **Content Outline.md** y **Topic Research.md**, enumerar los requisitos de redacción y luego escribir el borrador en **Article Draft.md**. ## Usa las Secciones como puntos de control Añade una Sección cuando necesites: * Un Artefacto discreto. * Una pausa para la revisión humana. * Un punto de referencia claro para Secciones posteriores. ## Escribe Artefactos solo cuando necesites persistencia El contexto se transfiere entre Secciones automáticamente. Usa Artefactos cuando un resultado deba almacenarse, compartirse o consultarse más tarde. ## Haz referencia a las Bases de conocimientos por nombre Elige la Base de conocimientos específica en el selector de Bases de conocimientos del paso. La selección automática o la búsqueda en todas las Bases de conocimientos puede recuperar contenido de la fuente equivocada. ## Haz referencia a los Artefactos por nombre Los nombres de los Artefactos son estables. Los nombres de archivo pueden cambiar. Usa el menú de barra inclinada para insertar referencias a Artefactos por nombre en las Secciones posteriores. ## Mantén la publicación separada de la creación de contenido Usa los Playbooks para crear, actualizar, revisar y preparar contenido. Publica desde una columna de Grid, un Playbook de publicación separado o un CMS MCP después de la revisión. Esto hace que la revisión editorial, la asignación de campos del CMS y el seguimiento de publicaciones sean más fáciles de controlar. Cuando un Playbook o un CMS MCP publique o actualice una página, usa la herramienta de AirOps MCP `track_aeo_page_content_update` con la URL de la página y el tipo de actualización para que AirOps Insights pueda vincular futuros cambios en visibilidad de IA, citas, menciones y tráfico a esa actualización de contenido. ## Combina Playbooks de detección de oportunidades y de generación de resultados Deja que un Playbook supervise los datos y encuentre oportunidades, y luego deja que un Playbook de acción separado produzca el resultado. Esto hace que cada Playbook sea más fácil de razonar, revisar e iterar. ## Pide a Quill que traduzca los prompts del Workflow Cuando migres un Workflow, pega el prompt original con todo el contexto y pide [Quill](/docs/es/quill.md) que lo traduzca en una instrucción concisa para el agente. Luego, recorta el resultado. ## Mantén los cambios propuestos sujetos a revisión humana Los Playbooks bien diseñados sugieren cambios para la aprobación humana en lugar de aplicarlos automáticamente cuando el criterio importa. Este patrón genera confianza, detecta casos límite y mantiene informadas a las partes interesadas. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.airops.com/docs/es/acciones/playbooks/best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.