Cómo aislar sus reglas de Amazon Q escritas a mano del Memory Bank que genera (Guía de 2026)

Las reglas de proyecto de Amazon Q son archivos Markdown en la carpeta .amazonq/rules de un proyecto. La documentación es directa sobre su propósito: las reglas "describen los estándares de codificación y las mejores prácticas en todo su equipo", y almacenarlas en el proyecto significa que usted "garantiza la coherencia entre los desarrolladores, independientemente de su nivel de experiencia".

El memory bank es una característica independiente con un propósito diferente. Amazon Q "puede generar automáticamente archivos de memory bank que proporcionan un índice rápido de la estructura de su proyecto, la pila tecnológica y la información del producto", analizando archivos clave para que pueda comprender la base de código "sin tener que analizar todo el proyecto cada vez que hace una pregunta".

Ambas características comparten una ubicación. Cuando realiza la generación, "Amazon Q crea una subcarpeta memory-bank bajo .amazonq/rules" que contiene cuatro archivos: product.md para una descripción general del proyecto y sus capacidades, structure.md para la arquitectura y organización de carpetas, tech.md para la pila tecnológica y las dependencias, y guidelines.md para los estándares y patrones de desarrollo.

Ese último nombre de archivo es donde las cosas se ponen interesantes. guidelines.md es contenido generado que describe "los estándares y patrones de desarrollo para su proyecto", lo cual es, palabra por palabra, el trabajo que hacían sus reglas escritas a mano. Ambos están ahora en el mismo árbol, y ambos "se utilizan automáticamente como contexto cuando chatea con Amazon Q".

Esto no es un defecto. Es un diseño donde el contenido creado por humanos y el contenido derivado ocupan el mismo espacio de nombres, y el costo de ese diseño es que la autoría se vuelve invisible exactamente en el momento en que más importa. Es el mismo tipo de problema que las capas de instrucciones en conflicto que ningún diff le mostrará, excepto que aquí una de las capas se escribió sola.

Asumir que el memory bank reemplaza a las reglas. No lo hace. Ambos se utilizan como contexto. Generar un memory bank añade archivos; no retira los que usted escribió.

Asumir que Regenerate solo afecta a los archivos generados. Esta es una suposición que vale la pena probar en lugar de darla por sentada. La acción documentada es Regenerate Memory Bank, y lo que regenera son los archivos del memory bank. La razón para verificar en lugar de asumir es que el límite es una subcarpeta dentro de una carpeta en la que usted también escribe, y lo único que marca sus archivos como suyos es dónde los coloca.

Colocar los estándares del equipo en guidelines.md porque el nombre encaja. El nombre encaja y el archivo es generado. Cualquier cosa escrita allí es contenido expuesto a ser sobrescrito en una regeneración.

Desactivar el memory bank para estar seguros. Esto cambia un beneficio real por un problema de organización de archivos. El índice existe para que Amazon Q no vuelva a leer todo el proyecto para cada pregunta, y eso es algo que vale la pena tener.

Desactivar archivos en el panel y darlo por resuelto. El botón Rules enumera las reglas disponibles y le permite hacer clic en una para activarla o desactivarla en la sesión de chat actual. Los archivos con una marca de verificación "están activos y se aplicarán a su conversación"; los archivos sin ella "están inactivos para la sesión actual". Ese es un interruptor por sesión, no una decisión de organización de archivos, y no cambia lo que hay en la carpeta.

Confiar en que el panel muestre quién escribió qué. Muestra nombres y marcas de verificación. Los archivos generados se encuentran bajo la subcarpeta memory bank, por lo que la ruta es la señal, y la ruta es la única señal.

El mecanismo le ofrece un único límite: la subcarpeta memory-bank. Todo lo demás es una convención que usted impone, y las convenciones solo se mantienen si algo las comprueba.

Paso 1: Nombre sus propios archivos de reglas para que la autoría sea legible desde el nombre del archivo

Revise .amazonq/rules y cambie el nombre de lo que escribió su equipo para que el nombre del archivo lo indique. Un prefijo funciona: team-api-conventions.md, team-testing-policy.md, team-security-baseline.md. La convención específica importa menos que el hecho de que tenga una sola palabra de longitud y se aplique sin excepción.

El objetivo no es la decoración. Cuando aparecen cuatro archivos generados en el mismo árbol, la pregunta "¿es esto nuestro?" debe responderse únicamente a partir de la lista de archivos, por parte de alguien que no estaba allí cuando se configuró la carpeta. Un prefijo responde a esto; un nombre de archivo bien pensado no lo hace, porque los nombres de archivo generados también están bien pensados.

Mientras está allí, mueva cualquier cosa que pertenezca a un archivo generado fuera de los suyos. Si una de sus reglas describe la distribución de las carpetas, para eso está structure.md, y duplicarlo significa mantenerlo dos veces y hacer que eventualmente no coincidan.

Paso 2: Escriba una regla que gobierne lo que produce el generador

Esta es la parte que la mayoría de los equipos pasan por alto, y está documentada. Puede "personalizar cómo se generan los archivos del memory bank creando reglas de proyecto personalizadas". El ejemplo proporcionado es una regla que especifica el idioma y el formato de los archivos generados.

Por lo tanto, el generador es direccionable, y esa dirección vive en la misma carpeta que todo lo demás. Escriba un archivo —llámelo team-memory-bank-policy.md bajo su prefijo— que indique qué deben y qué no deben contener los archivos generados. Dos instrucciones aportan la mayor parte del valor: mantenga los archivos generados descriptivos en lugar de prescriptivos, y no vuelva a enunciar los estándares del equipo que ya residen en los archivos con prefijo.

Esa segunda instrucción es la barrera. No impide nada a nivel del sistema de archivos. Le dice al generador que un tipo de contenido ya pertenece a otra parte, que es el único lugar en este diseño donde puede expresar eso.

Paso 3: Haga commit, regenere y lea el diff

Haga commit de los archivos renombrados y de la regla de política primero, para tener una línea base limpia. Luego ejecute Regenerate Memory Bank desde el botón Rules y lea el diff resultante antes de aceptar cualquier cosa.

Está comprobando tres cosas. Que sus archivos con prefijo no hayan sido tocados. Que los cuatro archivos del memory bank hayan cambiado solo dentro de la subcarpeta memory bank. Y que guidelines.md no haya vuelto a derivar una versión de los estándares que su regla de política le indicó que dejara en paz.

Haga esto una vez deliberadamente, con un commit para comparar, y conocerá el límite por observación en lugar de por suposición. Hágalo de nuevo después de una refactorización importante, porque ahí es cuando el generador tiene la mayor cantidad de material nuevo y la mayor oportunidad de volver a enunciar cosas.

Mantenga accesible el commit de la línea base. Los archivos generados están destinados a ser regenerados; la capacidad de ver qué cambió en una regeneración es lo que hace que eso sea seguro.

Los archivos con prefijo del Paso 1 son la mitad duradera de esto: acuerdos a los que llegó su equipo, en palabras de su equipo, que ningún generador produjo y ninguna regeneración debería alterar. MemoryLake es un lugar para guardar esa mitad de modo que no esté definida únicamente por el lugar donde se encuentra en la carpeta de una sola herramienta.

Usted mismo escribe las entradas, con sus propias palabras. No se lee nada, ni se escribe, ni se elimina de .amazonq/rules, de un memory bank de Amazon Q o de la tienda de cualquier proveedor.

Paso 1: Cree una clave API

Inicie sesión y genere una clave desde el panel de control. La clave es lo que permite a un agente leer las entradas que ha escrito, independientemente del editor o repositorio en el que se encuentre.

Paso 2: Suba sus primeras memorias

Agregue los acuerdos de sus archivos con prefijo, una decisión por entrada, con el motivo adjunto. El motivo es la parte que sobrevive a una reescritura de la regla, porque es lo que le dice a la siguiente persona si la regla aún se aplica.

Paso 3: Conecte su IA y agentes

Apunte sus agentes al espacio de trabajo. Las decisiones acordadas del equipo estarán disponibles en herramientas que no tienen ninguna carpeta .amazonq, que es lo que las convierte en acuerdos de equipo en lugar de una configuración de Amazon Q.

El primer cambio es que una lista de archivos responde a la pregunta de autoría. Antes del prefijo, saber "si escribimos esto" requería conocer la historia de la carpeta. Después de él, la lista es la respuesta, y un nuevo miembro del equipo lo entiende correctamente a la primera.

El segundo es que el generador se convierte en algo que usted configura en lugar de algo que le sorprende. La regla de política es un archivo pequeño con un efecto enorme, porque es la forma documentada de decir para qué sirven los archivos generados y, una vez que existe, el memory bank deja de derivar hacia la repetición de estándares.

El tercero es que la regeneración se vuelve rutinaria. La mayoría de los equipos evitan Regenerate porque no están seguros de qué tocará. Con un commit de línea base y una convención de prefijo, el diff responde a eso en segundos, y un memory bank que se actualiza después de una refactorización vale considerablemente más que uno generado una sola vez y dejado de lado hasta que quede obsoleto.

También aclara para qué sirve el interruptor por sesión. Desactivar una regla es una decisión sobre esta conversación, no sobre el proyecto, y no sobrevive a la sesión. Los equipos que esperan que el panel exprese la política del proyecto terminan con una política que dura un solo chat, una distinción que vale la pena hacer explícita, y la razón por la cual saber qué directrices están realmente vigentes es un ejercicio independiente de escribirlas.

Si ha utilizado un patrón de memory-bank en otra herramienta, la cuestión de la organización de archivos es la misma. Cline mantiene su banco en su propio directorio, razón por la cual configurar uno allí se trata principalmente de lo que va en cada archivo en lugar de quién es el propietario de la carpeta, y las alternativas que la gente compara cuando se les queda corto un solo banco difieren principalmente en este punto exacto.

Use un solo prefijo y nunca haga una excepción. El valor de la convención es que un archivo sin el prefijo, por definición, no es suyo. Una sola excepción destruye esa propiedad.

Mantenga la regla de política corta y sobre la forma, no sobre el contenido. Debe indicar qué tipo de cosas pertenecen a un archivo generado. Si comienza a contener los estándares en sí mismos, habrá trasladado sus estándares a la entrada del generador.

Regenere siempre contra un commit. El diff es la única observación que obtiene. Sin una línea base, no está disponible.

Deje que los archivos generados describan y sus archivos prescriban. Un archivo generado que dice "la capa de API vive en src/api" es útil y económico de actualizar. Un archivo generado que dice "todos los endpoints deben validar la entrada" es un estándar que nadie acordó con esa redacción.

Escriba el motivo en cada regla escrita a mano. Una regla sin un motivo no se puede evaluar más adelante, por lo que se sigue para siempre o se elimina por frustración. Esta es la misma razón por la cual las reglas que se ignoran suelen ser reglas que nadie puede justificar.

Recuerde que la carpeta viaja a otras plataformas. La misma carpeta .amazonq/rules es la ubicación documentada para las reglas de proyecto utilizadas con Amazon Q en GitLab o GitHub, donde las reglas se convierten "automáticamente" en contexto para el proyecto. Lo que usted hace commit es lo que se ejecuta allí.

Revise la carpeta cuando alguien se vaya. Una regla escrita a mano es el juicio de una persona. Cuando la persona se va, la regla necesita un propietario o ser eliminada, que es el tipo de cosas que una auditoría de lo que recuerdan sus herramientas saca a la luz antes de que se convierta en arqueología.

El memory bank de Amazon Q es una característica útil archivada en un lugar incómodo. Escribe cuatro archivos en la carpeta que contiene los acuerdos de su equipo, uno de ellos nombrado para el mismo trabajo que hacían sus acuerdos, y el panel que gestiona ambos los trata por igual.

La solución no es evitar la característica. Consiste en hacer que la autoría sea legible en el nombre del archivo, utilizar la ruta documentada para decirle al generador para qué sirven sus archivos y regenerar una vez contra un commit para conocer el límite por observación en lugar de por suposición.

Luego, guarde los acuerdos en sí en un lugar más amplio que la carpeta de configuración de una sola herramienta. Las reglas son la forma en que se aplica una decisión en un editor en particular. La decisión es lo que vale la pena conservar, y sobrevive a la carpeta, razón por la cual los equipos que se mueven entre herramientas descubren que llevar las reglas es fácil y llevar el razonamiento es el verdadero trabajo.