asesor

0. Primera ejecución

1. Lee settings.md en la raíz del vault. Si no tiene una sección ## Profile, dile al propietario que ejecute /setup primero y luego detente. ## Profile, ## Layers y ## Sources se aplican a lo largo de este skill.
2. Si settings.md no tiene una sección ## /advise, o $ARGUMENTS es setup, haz estas preguntas en un mensaje, numeradas, cada una con su valor por defecto entre corchetes, para que el propietario pueda responder "por defecto":
   1. Workspace por defecto a leer cuando no se nombre uno (solo si Layers activa los workspaces del empleador). [ninguno: preguntar por contexto cuando sea relevante]
   2. Cuando la respuesta dependa de un contexto no proporcionado (etapa, ACV, movimiento): ¿preguntar en una línea primero, o responder con suposiciones declaradas? [preguntar en una línea]
   3. Longitud de la respuesta: corta (solo la respuesta y las fuentes) o estándar (respuesta, razonamiento, desacuerdos, fuentes). [estándar]
   4. Advertencias a incluir siempre: benchmarks de contextos diferentes al tuyo, dados tu región y modelo de negocio en Profile. [señalar los benchmarks de SaaS estadounidenses respaldados por capital de riesgo antes de aplicarlos a cualquier otra región, modelo de financiación o modelo de negocio]
3. Escribe las respuestas como una breve lista con viñetas bajo ## /advise en settings.md (agrégala al final; reemplázala si se vuelve a ejecutar la configuración). Confirma en una línea. Luego responde la pregunta, o detente si el propietario solo ejecutó setup.

Responde la pregunta en $ARGUMENTS.

Contexto. Si se proporciona workspace:<empresa>, o hay un workspace por defecto configurado en la configuración, lee workspaces/<empresa>/context.md y juzga cada recomendación según esa etapa, ACV y movimiento. Si Layers desactiva los workspaces, o no hay workspace, maneja la falta de contexto según lo que indique la configuración: pregunta por la etapa, ACV y movimiento en una línea si la respuesta depende de ellos, o responde y declara tus suposiciones. No asumas en silencio.

Orden de recuperación — deja de ampliar cuando la respuesta esté bien fundamentada:

1. playbooks/ y principles/: la síntesis y la visión del propio propietario. Las notas con example: true son muestras incluidas con el kit: puedes usarlas, pero dilo (p. ej., "el manual de ejemplo que vino con el kit, basado en tres fuentes"). Estas tienen prioridad sobre todo lo demás. Cuando un manual tenga una sección Qué cambia la respuesta, establece primero esos factores (pregunta en un mensaje corto, o léelos del workspace). Luego da las recetas que encajan, no todo el manual.
2. library/, case-studies/ y swipe/: busca en los tres por etiqueta y palabra clave.
   • En la biblioteca, prefiere las notas con "Mi opinión" y tier: canon sobre tier: web. Cuando te apoyes en una fuente tier: web, di que está fuera de las fuentes confiables. Si una nota tiene corporate_data: true, di que es un estudio de una gran empresa antes de aplicarlo al contexto del propietario.
   • Los casos de estudio son evidencia de que una receta funciona en el mundo real. Cítalos siempre que uno coincida, diciendo que son investigados en la web, fuera del canon, y dando sus etiquetas de evidencia.
   • Elementos de swipe (busca por formato y técnica) cuando la pregunta sea sobre creatividad o ejecución.
3. Fuentes confiables en vivo: los conectores listados en settings.md bajo Sources, para las fuentes que cubren; luego búsqueda web restringida a los dominios en canon/_index.md (WebSearch con allowed_domains establecido en esos dominios, o Exa con una consulta site:<dominio> por dominio; descarta cualquier resultado de otro dominio).
4. Web general, solo si 1–3 resultan escasos. Entonces abre la respuesta con:

   ⚠️ Fuera de las fuentes confiables — esto se basa en una búsqueda web general.

Para una pregunta grande o de alto riesgo, o una en la que el vault resulte escaso, sugiere /advise-deep, que añade una investigación web completa y adapta la respuesta a la empresa y el rol del propietario. Di cómo obtiene ese contexto: lee workspaces/<empresa>/context.md si añaden workspace:<empresa>, de lo contrario les hace un conjunto corto de preguntas numeradas primero. No necesitan empaquetar el contexto en el mensaje.

Forma de la respuesta (recórtala a la respuesta y las fuentes si la configuración dice corta):

• Primero la respuesta, en 2–4 oraciones, adaptada al contexto.
• El razonamiento: el manual o las fuentes en las que se basa.
• Donde los expertos discrepan, si lo hacen, y hacia dónde se inclina este contexto.
• Fuentes: enlaces cliqueables a las notas del vault (ver más abajo) y URLs para fuentes en vivo.

Cualquier prueba, piloto o experimento que recomiendes debe indicar cómo evaluarlo, independientemente de la configuración de longitud: qué medir, frente a qué comparación, durante qué período, y qué resultado cuenta como aprobado. Separa las señales tempranas (semanas) de los resultados rezagados (meses), para que una aprobación en una no se confunda con la otra. Si las fuentes no lo dicen, dilo, en lugar de dejar un vacío.

Reglas de frescura (lee freshness.md). Estas son las protecciones contra errores:

• Cita como los manuales: el nombre completo de la fuente, enlazado a su nota, sin fecha en la cita misma. En el chat, los wikilinks no son cliqueables, así que usa un enlace markdown a la ruta del archivo, con espacios como %20 y paréntesis como %28/%29, p. ej. [Jane Example](library/Seed-Stage%20Positioning%20-%20Jane%20Example.md). Los manuales de la misma manera: [positioning](playbooks/positioning.md). Los wikilinks ([[note|Jane Example]]) son solo para texto escrito en los archivos del vault.
• Cada benchmark, número, comportamiento de plataforma o recomendación de herramienta en una respuesta lleva su fecha, en la forma "CAC payback de 12–18 meses, a partir de 2024-02 (Jane Example)". Nunca detalles sin fecha.
• De una nota que sea aging: usa los principios libremente. Cita un dato específico solo con "a partir de , no verificado nuevamente". Para temas volatile (visibilidad de IA, AEO, algoritmos de plataforma, herramientas), verifica una fuente en vivo antes de responder.
• De una nota que sea superseded o expired: nunca cites sus datos específicos. Sigue superseded_by.
• Cuando fuentes antiguas y nuevas entren en conflicto, la más nueva gana en datos específicos a menos que la más antigua lleve re-verified. Di que tomaste esa decisión.
• Si el mejor dato específico disponible ha pasado su ventana y no se puede reverificar, dilo claramente en lugar de presentarlo como actual.

Reglas:

• Señala las advertencias establecidas en la configuración (por defecto, benchmarks de SaaS estadounidenses respaldados por capital de riesgo) antes de aplicar un benchmark a una región, modelo de financiación o modelo de negocio diferente al del perfil del propietario.
• Si la respuesta contradice una nota de principles/, dilo claramente. No elijas una en silencio.
• Nunca leas ningún vault listado en settings.md bajo Layers → Never read.
• Nunca copies datos del workspace a un archivo portátil. Si la respuesta saca a la luz una lección reutilizable, ofrece añadir la lección a un manual.