AnpingWhale/skills

Setup Anping Skills - Iniciador de proyecto

Inicializa el repositorio actual como un entorno de proyecto adecuado para la colaboración a largo plazo con Codex. Este Skill está guiado por prompt, no es un script de instalación determinista: primero explora, luego pregunta, luego muestra un borrador y finalmente escribe.

El objetivo no es instalar todos los Skills, sino combinarlos según las necesidades del proyecto:

• Skills propios de Anping, como multi-agent-orchestrator, transfer-codex-sessions.
• Skills externos destacados, como los engineering skills de Matt Pocock.
• Archivos de reglas y conocimiento del proyecto, como AGENTS.md, CONTEXT.md, CONTEXT-MAP.md, docs/agents/, docs/adr/.

Principios de ejecución

• Explicar el medio de ejecución antes de comenzar. Las inicializaciones largas o de múltiples archivos deben seguir las reglas de orquestación multi-agente del proyecto actual; si la política de herramientas no permite la delegación, explicar que se utilizará un fallback escalonado.
• Preguntar al usuario solo una parte a la vez. No lanzar todas las decisiones al usuario de una vez.
• Cada Skill recomendado debe explicar su propósito, origen y por qué es adecuado para el proyecto actual.
• No incluir el código fuente de Skills de terceros. Los Skills externos solo se integran mediante su fuente de instalación o directorio de referencia.
• Antes de escribir archivos, mostrar los archivos que se modificarán, los bloques clave y la selección predeterminada; escribir solo después de obtener la confirmación del usuario.
• No sobrescribir el contenido existente de AGENTS.md, README.md, CONTEXT.md o docs/agents/*; actualizar bloques existentes, evitando añadidos duplicados.

Flujo de trabajo

1. Verificar Skills dependientes

Verificar primero si los Skills clave ya están disponibles en la sesión actual o en ~/.codex/skills/. Leer references/skill-catalog.md y, según las necesidades del proyecto, determinar cuáles son esenciales, recomendados u opcionales:

• Selección de Skills y aclaración de objetivos: ask-matt, grill-with-docs.
• Modelado de dominio y consolidación de conocimiento: domain-modeling.
• Orquestación del hilo principal: multi-agent-orchestrator.
• Configuración de proyectos de ingeniería: setup-matt-pocock-skills.

No instalar automáticamente todos los elementos faltantes. Primero informar al usuario sobre los Skills faltantes, su origen, propósito y nivel de recomendación; después de la confirmación del usuario, instalar usando skill-installer o el método recomendado por la fuente original.

2. Explorar el proyecto

Leer rápidamente el estado actual del repositorio, proporcionando solo una breve instantánea al usuario, sin conclusiones excesivas:

• git remote -v y .git/config: si es un proyecto de GitHub/GitLab/local.
• AGENTS.md, CLAUDE.md en la raíz: si ya existen reglas de agente o secciones relacionadas con Agent skills.
• README.md en la raíz: si ya se ha definido claramente el objetivo del proyecto.
• CONTEXT.md, CONTEXT-MAP.md en la raíz.
• docs/agents/, docs/adr/, src/*/docs/adr/.
• .scratch/: si ya existe una convención local de issues en markdown.
• ~/.codex/skills/ o Skills disponibles en la sesión actual: qué Skills propios y externos ya están instalados.

3. Mostrar hallazgos

Informar al usuario con una lista breve:

• El tipo aproximado del proyecto actual.
• Los archivos de colaboración AI existentes.
• Archivos que faltan pero que podrían ser valiosos.
• Skills clave instalados/no instalados.
• Qué decisiones se preguntarán a continuación, paso a paso.

4. Preguntar paso a paso

Cada sección debe comenzar explicando su propósito e impacto en 1-3 frases, luego dar una sugerencia predeterminada, esperar la respuesta del usuario y pasar a la siguiente sección.

A. Objetivo del proyecto

Si el objetivo del proyecto no está claro, usar primero ask-matt para seleccionar el flujo adecuado; si es necesario documentar durante entrevistas, usar grill-with-docs. Una vez acordado el objetivo, preguntar si se debe escribir o actualizar la descripción del proyecto en README.md.

B. Modo de orquestación del hilo principal

Preguntar si se desea habilitar multi-agent-orchestrator. Explicar que los beneficios son la gobernanza del contexto, la verificación independiente y la reducción de auto-validación; el costo es que las tareas cortas pueden aumentar el total de tokens. Si el usuario acepta, continuar preguntando si se debe escribir la autorización de delegación a nivel de proyecto: permitir que el hilo principal cree o use subagentes / agentes de rol con un hilo de Codex visible para el usuario, siempre que cumpla con la política de sistema/desarrollador/herramienta, las reglas del repositorio y los requisitos de aprobación. Tras la confirmación del usuario, escribir las reglas de orquestación del hilo principal y la autorización en AGENTS.md, utilizando preferentemente la plantilla del Skill instalado.

C. Diseño del contexto

Dejar que el usuario elija:

• Single-context: un CONTEXT.md en la raíz y docs/adr/. Es la opción predeterminada para la mayoría de los repositorios.
• Multi-context: un CONTEXT-MAP.md en la raíz que apunta a múltiples directorios de contexto, adecuado para monorepositorios o repositorios con múltiples productos.

Al escribir archivos específicos, leer references/project-files.md.

D. Base de conocimiento del proyecto

Preguntar si se desea crear una base de conocimiento del proyecto orientada a humanos y AI. Sugerencia predeterminada:

• docs/agents/anping-skills.md: Skills habilitados en este proyecto, propósito y límites de invocación.
• docs/agents/project-knowledge.md: Reglas para la consolidación de conocimiento del proyecto.
• docs/adr/README.md: Instrucciones de uso de ADR. Por defecto, los ADR se escriben en chino, a menos que el usuario especifique explícitamente que prefiere inglés o bilingüe.

E. Integración de Skills externos

Recomendar Skills externos según el tipo de proyecto. Por defecto, no instalar todos; solo recomendar la combinación que se usará en el proyecto actual. Antes de instalar Skills de terceros, explicar el origen y la justificación, y solicitar confirmación.

5. Mostrar borrador y confirmar

Antes de escribir, mostrar:

• La lista de archivos que se modificarán o crearán.
• Un resumen de las secciones que se añadirán/actualizarán en AGENTS.md, incluyendo si se incluye la Autorización de delegación.
• La lista de Skills que se registrarán en docs/agents/anping-skills.md.
• El diseño de CONTEXT.md o CONTEXT-MAP.md.
• Si se instalarán o recomendarán Skills externos.

Ejecutar las modificaciones solo después de la confirmación del usuario.

6. Escribir la configuración del proyecto

Escribir según las elecciones del usuario:

• La sección de colaboración Anping/Codex en AGENTS.md o en el archivo de reglas de agente existente.
• docs/agents/anping-skills.md.
• docs/agents/project-knowledge.md.
• CONTEXT.md o CONTEXT-MAP.md.
• docs/adr/README.md.
• Elementos de seguridad en .gitignore, como codex_sessions/, si el proyecto utilizará migración de sesiones.

Si el proyecto también usa setup-matt-pocock-skills, no duplicar el bloque Agent skills con el mismo significado; actualizar o fusionar las secciones existentes.

7. Validar

Después de escribir, realizar una validación ligera antes de informar la finalización:

• Volver a leer las secciones clave modificadas para confirmar que el contenido está en los archivos esperados.
• Verificar que no haya bloques duplicados de Anping / Agent skills / Multi-Agent Orchestrator.
• Confirmar que los archivos que se debían crear existen, como docs/agents/anping-skills.md, CONTEXT.md o CONTEXT-MAP.md, docs/adr/README.md.
• Si se modificaron archivos YAML, TOML, JSON u otra configuración analizable, usar un analizador local para validar el formato.
• Si alguna elección no se ejecutó, registrar el motivo y los riesgos restantes.

8. Cierre

Finalmente, informar:

• Qué capacidades se han habilitado.
• Qué archivos se modificaron.
• Qué Skills se instalaron y cuáles solo se recomendaron.
• Cómo puede el usuario activar estas capacidades con una frase en el futuro.
• Riesgos restantes, como Skills externos no instalados, credenciales de GitHub no disponibles, o el objetivo del proyecto aún no claro.

No hacer commit, push ni subir archivos automáticamente, a menos que el usuario lo solicite explícitamente.