@iaforged/context-code 1.3.5 → 1.3.6

package/README.md

@@ -78,6 +78,44 @@ Comportamiento por defecto:
 - el idioma por defecto del dictado es espanol (`es`);
 - si quieres otro idioma o autodeteccion, puedes ajustarlo en la configuracion.
 
+## Objetivo autonomo
+
+`/objetivo` fija una condicion de fin que el agente persigue por su cuenta hasta cumplirla. Al cerrar cada turno, el mismo modelo y proveedor que tengas activos evaluan si la condicion ya se cumplio. Si no, te informan que falta y el agente sigue trabajando; si si, el objetivo se limpia y se anuncia el resultado.
+
+Inspirado en `/goal` de Claude Code, pero compatible con cualquier proveedor que soporte el CLI (Claude, OpenAI, Bedrock, Vertex, Gemini, OpenRouter, Ollama, ZAI, MiniMax, etc.) y con el modelo que tengas seleccionado en cada momento.
+
+Comandos:
+
+- `/objetivo <condicion de fin>` fija la meta y arranca la evaluacion automatica al cierre de cada turno.
+- `/objetivo` (sin argumentos) muestra el estado actual: meta, tiempo transcurrido, turnos completados y ultima razon devuelta por el evaluador.
+- `/objetivo clear` cancela el objetivo activo. Tambien valen `stop`, `off`, `reset`, `cancel`, `cancelar`, `limpiar`, `parar`, `detener` y `none`.
+- Alias del comando: `/meta` y `/mision`.
+
+Comportamiento:
+
+- Sin limite de turnos: si le diste una tarea, la termina. Cortas con `/objetivo clear` o `Ctrl+C` cuando quieras.
+- Al fijar la meta, el modo de permisos cambia automaticamente a `bypassPermissions` (equivalente a `--dangerously-skip-permissions`) para que el agente pueda ejecutar Bash/Edit/Write sin detenerse a pedir confirmacion en cada paso. Al cancelar o cumplir, se restaura el modo previo. Si el modo bypass no esta disponible en tu entorno (gate corporativo) o ya estabas en bypass, no se cambia y el comando te lo avisa.
+- Mientras hay objetivo activo, el footer del prompt muestra `o objetivo - Xm Ys - Nt` con el tiempo transcurrido (cronometro que corre en tiempo real cada segundo) y los turnos completados.
+- Entre turno y turno, antes de continuar trabajando, aparece en el chat un mensaje visible del estilo `o Continuando hacia el objetivo (turno 3 - 4m 12s) - Aun falta: <razon>`, asi siempre ves cuanto lleva, en que turno va y que falta segun el evaluador.
+- Toda la actividad del agente (mensajes, llamadas a herramientas, resultados) se ve en el chat como en cualquier conversacion normal: puedes seguir el trabajo paso a paso mientras corre.
+- Cuando el evaluador devuelve "cumplido", aparece `o Objetivo cumplido en <duracion> (<N> turnos) - <evidencia>` en el chat.
+- El estado es de sesion: no se persiste a disco. `/clear` o cerrar la sesion lo elimina.
+- Si la red o el parse del evaluador fallan en un turno, el turno termina normal y no bloquea la conversacion.
+
+Ejemplos:
+
+```text
+/objetivo todos los tests de auth pasan en pnpm test
+/objetivo el modulo src/services/db usa solo PostgreSQL, sin imports legacy de MySQL
+/objetivo
+/objetivo clear
+```
+
+Consejos:
+
+- Funciona mejor con condiciones medibles ("los tests X pasan", "el archivo Y no contiene Z") que con metas vagas.
+- Si el agente da varias vueltas sin avanzar, cancela y reformula con una condicion mas concreta.
+
 ## MCP integrados
 
 Context Code soporta MCP externos, pero tambien incluye MCP integrados para ciertos flujos del runtime.

package/dist/src/bridge/bridgeMain.js

@@ -1410,56 +1410,56 @@ async function printHelp() {
     const modes = EXTERNAL_PERMISSION_MODES.join(', ');
     const showServer = await isMultiSessionSpawnEnabled();
     const serverOptions = showServer
-        ? `  --spawn <mode>                   Spawn mode: same-dir, worktree, session
-                                   (default: same-dir)
-  --capacity <N>                   Max concurrent sessions in worktree or
-                                   same-dir mode (default: ${SPAWN_SESSIONS_DEFAULT})
-  --[no-]create-session-in-dir     Pre-create a session in the current
-                                   directory; in worktree mode this session
-                                   stays in cwd while on-demand sessions get
-                                   isolated worktrees (default: on)
+        ? `  --spawn <mode>                   Spawn mode: same-dir, worktree, session
+                                   (default: same-dir)
+  --capacity <N>                   Max concurrent sessions in worktree or
+                                   same-dir mode (default: ${SPAWN_SESSIONS_DEFAULT})
+  --[no-]create-session-in-dir     Pre-create a session in the current
+                                   directory; in worktree mode this session
+                                   stays in cwd while on-demand sessions get
+                                   isolated worktrees (default: on)
 `
         : '';
     const serverDescription = showServer
-        ? `
-  Remote Control runs as a persistent server that accepts multiple concurrent
-  sessions in the current directory. One session is pre-created on start so
-  you have somewhere to type immediately. Use --spawn=worktree to isolate
-  each on-demand session in its own git worktree, or --spawn=session for
-  the classic single-session mode (exits when that session ends). Press 'w'
-  during runtime to toggle between same-dir and worktree.
+        ? `
+  Remote Control runs as a persistent server that accepts multiple concurrent
+  sessions in the current directory. One session is pre-created on start so
+  you have somewhere to type immediately. Use --spawn=worktree to isolate
+  each on-demand session in its own git worktree, or --spawn=session for
+  the classic single-session mode (exits when that session ends). Press 'w'
+  during runtime to toggle between same-dir and worktree.
 `
         : '';
     const serverNote = showServer
-        ? `  - Worktree mode requires a git repository or WorktreeCreate/WorktreeRemove hooks
+        ? `  - Worktree mode requires a git repository or WorktreeCreate/WorktreeRemove hooks
 `
         : '';
-    const help = `
-Remote Control - Connect your local environment to claude.ai/code
-
-USAGE
-  claude remote-control [options]
-OPTIONS
-  --name <name>                    Name for the session (shown in claude.ai/code)
+    const help = `
+Remote Control - Connect your local environment to claude.ai/code
+
+USAGE
+  claude remote-control [options]
+OPTIONS
+  --name <name>                    Name for the session (shown in claude.ai/code)
 ${feature('KAIROS')
-        ? `  -c, --continue                   Resume the last session in this directory
-  --session-id <id>                Resume a specific session by ID (cannot be
-                                   used with spawn flags or --continue)
+        ? `  -c, --continue                   Resume the last session in this directory
+  --session-id <id>                Resume a specific session by ID (cannot be
+                                   used with spawn flags or --continue)
 `
-        : ''}  --permission-mode <mode>         Permission mode for spawned sessions
-                                   (${modes})
-  --debug-file <path>              Write debug logs to file
-  -v, --verbose                    Enable verbose output
-  -h, --help                       Show this help
-${serverOptions}
-DESCRIPTION
-  Remote Control allows you to control sessions on your local device from
-  claude.ai/code (https://claude.ai/code). Run this command in the
-  directory you want to work in, then connect from the Claude app or web.
-${serverDescription}
-NOTES
-  - You must be logged in with a Claude account that has a subscription
-  - Run \`claude\` first in the directory to accept the workspace trust dialog
+        : ''}  --permission-mode <mode>         Permission mode for spawned sessions
+                                   (${modes})
+  --debug-file <path>              Write debug logs to file
+  -v, --verbose                    Enable verbose output
+  -h, --help                       Show this help
+${serverOptions}
+DESCRIPTION
+  Remote Control allows you to control sessions on your local device from
+  claude.ai/code (https://claude.ai/code). Run this command in the
+  directory you want to work in, then connect from the Claude app or web.
+${serverDescription}
+NOTES
+  - You must be logged in with a Claude account that has a subscription
+  - Run \`claude\` first in the directory to accept the workspace trust dialog
 ${serverNote}`;
     // biome-ignore lint/suspicious/noConsole: intentional help output
     console.log(help);

package/dist/src/bridge/bridgeUI.js

@@ -185,7 +185,7 @@ export function createBridgeLogger(options) {
                 const actText = showAct
                     ? chalk.dim(` ${truncatePrompt(act.summary, 40)}`)
                     : '';
-                writeStatus(`    ${titleLinked}${actText}
+                writeStatus(`    ${titleLinked}${actText}
 `);
             }
         }

package/dist/src/buddy/prompt.js

@@ -2,10 +2,10 @@ import { feature } from '../recovery/bunBundleShim.js';
 import { getGlobalConfig } from '../utils/config.js';
 import { getCompanion } from './companion.js';
 export function companionIntroText(name, species) {
-    return `# Companion
-
-A small ${species} named ${name} sits beside the user's input box and occasionally comments in a speech bubble. You're not ${name} — it's a separate watcher.
-
+    return `# Companion
+
+A small ${species} named ${name} sits beside the user's input box and occasionally comments in a speech bubble. You're not ${name} — it's a separate watcher.
+
 When the user addresses ${name} directly (by name), its bubble will answer. Your job in that moment is to stay out of the way: respond in ONE line or less, or just answer any part of the message meant for you. Don't explain that you're not ${name} — they know. Don't narrate what ${name} might say — the bubble handles that.`;
 }
 export function getCompanionIntroAttachment(messages) {

package/dist/src/cli/print.js

@@ -152,18 +152,18 @@ const extractMemoriesModule = feature('EXTRACT_MEMORIES')
     ? require('../services/extractMemories/extractMemories.js')
     : null;
 /* eslint-enable @typescript-eslint/no-require-imports */
-const SHUTDOWN_TEAM_PROMPT = `<system-reminder>
-You are running in non-interactive mode and cannot return a response to the user until your team is shut down.
-
-You MUST shut down your team before preparing your final response:
-1. Use requestShutdown to ask each team member to shut down gracefully
-2. Wait for shutdown approvals
-3. Use the cleanup operation to clean up the team
-4. Only then provide your final response to the user
-
-The user cannot receive your response until the team is completely shut down.
-</system-reminder>
-
+const SHUTDOWN_TEAM_PROMPT = `<system-reminder>
+You are running in non-interactive mode and cannot return a response to the user until your team is shut down.
+
+You MUST shut down your team before preparing your final response:
+1. Use requestShutdown to ask each team member to shut down gracefully
+2. Wait for shutdown approvals
+3. Use the cleanup operation to clean up the team
+4. Only then provide your final response to the user
+
+The user cannot receive your response until the team is completely shut down.
+</system-reminder>
+
 Shut down your team and prepare your final response for the user.`;
 // Track message UUIDs received during the current session runtime
 const MAX_RECEIVED_UUIDS = 10_000;

package/dist/src/commands/commit-push-pr.js

@@ -26,14 +26,14 @@ function getPromptContent(defaultBranch, prAttribution) {
     let prefix = '';
     let reviewerArg = ' and `--reviewer anthropics/claude-code`';
     let addReviewerArg = ' (and add `--add-reviewer anthropics/claude-code`)';
-    let changelogSection = `
-
-## Changelog
-<!-- CHANGELOG:START -->
-[If this PR contains user-facing changes, add a changelog entry here. Otherwise, remove this section.]
+    let changelogSection = `
+
+## Changelog
+<!-- CHANGELOG:START -->
+[If this PR contains user-facing changes, add a changelog entry here. Otherwise, remove this section.]
 <!-- CHANGELOG:END -->`;
-    let slackStep = `
-
+    let slackStep = `
+
 5. After creating/updating the PR, check if the user's CLAUDE.md mentions posting to Slack channels. If it does, use ToolSearch to search for "slack send message" tools. If ToolSearch finds a Slack tool, ask the user if they'd like you to post the PR URL to the relevant Slack channel. Only post if the user confirms. If ToolSearch returns no results or errors, skip this step silently—do not mention the failure, do not attempt workarounds, and do not try alternative approaches.`;
     if (process.env.USER_TYPE === 'ant' && isUndercover()) {
         prefix = getUndercoverInstructions() + '\n';
@@ -42,54 +42,54 @@ function getPromptContent(defaultBranch, prAttribution) {
         changelogSection = '';
         slackStep = '';
     }
-    return `${prefix}## Context
-
-- \`SAFEUSER\`: ${safeUser}
-- \`whoami\`: ${username}
-- \`git status\`: !\`git status\`
-- \`git diff HEAD\`: !\`git diff HEAD\`
-- \`git branch --show-current\`: !\`git branch --show-current\`
-- \`git diff ${defaultBranch}...HEAD\`: !\`git diff ${defaultBranch}...HEAD\`
-- \`gh pr view --json number 2>/dev/null || true\`: !\`gh pr view --json number 2>/dev/null || true\`
-
-## Git Safety Protocol
-
-- NEVER update the git config
-- NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them
-- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it
-- NEVER run force push to main/master, warn the user if they request it
-- Do not commit files that likely contain secrets (.env, credentials.json, etc)
-- Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported
-
-## Your task
-
-Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request from the git diff ${defaultBranch}...HEAD output above).
-
-Based on the above changes:
-1. Create a new branch if on ${defaultBranch} (use SAFEUSER from context above for the branch name prefix, falling back to whoami if SAFEUSER is empty, e.g., \`username/feature-name\`)
-2. Create a single commit with an appropriate message using heredoc syntax${commitAttribution ? `, ending with the attribution text shown in the example below` : ''}:
-\`\`\`
-git commit -m "$(cat <<'EOF'
-Commit message here.${commitAttribution ? `\n\n${commitAttribution}` : ''}
-EOF
-)"
-\`\`\`
-3. Push the branch to origin
-4. If a PR already exists for this branch (check the gh pr view output above), update the PR title and body using \`gh pr edit\` to reflect the current diff${addReviewerArg}. Otherwise, create a pull request using \`gh pr create\` with heredoc syntax for the body${reviewerArg}.
-   - IMPORTANT: Keep PR titles short (under 70 characters). Use the body for details.
-\`\`\`
-gh pr create --title "Short, descriptive title" --body "$(cat <<'EOF'
-## Summary
-<1-3 bullet points>
-
-## Test plan
-[Bulleted markdown checklist of TODOs for testing the pull request...]${changelogSection}${effectivePrAttribution ? `\n\n${effectivePrAttribution}` : ''}
-EOF
-)"
-\`\`\`
-
-You have the capability to call multiple tools in a single response. You MUST do all of the above in a single message.${slackStep}
-
+    return `${prefix}## Context
+
+- \`SAFEUSER\`: ${safeUser}
+- \`whoami\`: ${username}
+- \`git status\`: !\`git status\`
+- \`git diff HEAD\`: !\`git diff HEAD\`
+- \`git branch --show-current\`: !\`git branch --show-current\`
+- \`git diff ${defaultBranch}...HEAD\`: !\`git diff ${defaultBranch}...HEAD\`
+- \`gh pr view --json number 2>/dev/null || true\`: !\`gh pr view --json number 2>/dev/null || true\`
+
+## Git Safety Protocol
+
+- NEVER update the git config
+- NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them
+- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it
+- NEVER run force push to main/master, warn the user if they request it
+- Do not commit files that likely contain secrets (.env, credentials.json, etc)
+- Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported
+
+## Your task
+
+Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request from the git diff ${defaultBranch}...HEAD output above).
+
+Based on the above changes:
+1. Create a new branch if on ${defaultBranch} (use SAFEUSER from context above for the branch name prefix, falling back to whoami if SAFEUSER is empty, e.g., \`username/feature-name\`)
+2. Create a single commit with an appropriate message using heredoc syntax${commitAttribution ? `, ending with the attribution text shown in the example below` : ''}:
+\`\`\`
+git commit -m "$(cat <<'EOF'
+Commit message here.${commitAttribution ? `\n\n${commitAttribution}` : ''}
+EOF
+)"
+\`\`\`
+3. Push the branch to origin
+4. If a PR already exists for this branch (check the gh pr view output above), update the PR title and body using \`gh pr edit\` to reflect the current diff${addReviewerArg}. Otherwise, create a pull request using \`gh pr create\` with heredoc syntax for the body${reviewerArg}.
+   - IMPORTANT: Keep PR titles short (under 70 characters). Use the body for details.
+\`\`\`
+gh pr create --title "Short, descriptive title" --body "$(cat <<'EOF'
+## Summary
+<1-3 bullet points>
+
+## Test plan
+[Bulleted markdown checklist of TODOs for testing the pull request...]${changelogSection}${effectivePrAttribution ? `\n\n${effectivePrAttribution}` : ''}
+EOF
+)"
+\`\`\`
+
+You have the capability to call multiple tools in a single response. You MUST do all of the above in a single message.${slackStep}
+
 Return the PR URL when you're done, so the user can see it.`;
 }
 const command = {

package/dist/src/commands/commit.js

@@ -12,40 +12,40 @@ function getPromptContent() {
     if (process.env.USER_TYPE === 'ant' && isUndercover()) {
         prefix = getUndercoverInstructions() + '\n';
     }
-    return `${prefix}## Context
-
-- Current git status: !\`git status\`
-- Current git diff (staged and unstaged changes): !\`git diff HEAD\`
-- Current branch: !\`git branch --show-current\`
-- Recent commits: !\`git log --oneline -10\`
-
-## Git Safety Protocol
-
-- NEVER update the git config
-- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it
-- CRITICAL: ALWAYS create NEW commits. NEVER use git commit --amend, unless the user explicitly requests it
-- Do not commit files that likely contain secrets (.env, credentials.json, etc). Warn the user if they specifically request to commit those files
-- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit
-- Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported
-
-## Your task
-
-Based on the above changes, create a single git commit:
-
-1. Analyze all staged changes and draft a commit message:
-   - Look at the recent commits above to follow this repository's commit message style
-   - Summarize the nature of the changes (new feature, enhancement, bug fix, refactoring, test, docs, etc.)
-   - Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.)
-   - Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
-
-2. Stage relevant files and create the commit using HEREDOC syntax:
-\`\`\`
-git commit -m "$(cat <<'EOF'
-Commit message here.${commitAttribution ? `\n\n${commitAttribution}` : ''}
-EOF
-)"
-\`\`\`
-
+    return `${prefix}## Context
+
+- Current git status: !\`git status\`
+- Current git diff (staged and unstaged changes): !\`git diff HEAD\`
+- Current branch: !\`git branch --show-current\`
+- Recent commits: !\`git log --oneline -10\`
+
+## Git Safety Protocol
+
+- NEVER update the git config
+- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it
+- CRITICAL: ALWAYS create NEW commits. NEVER use git commit --amend, unless the user explicitly requests it
+- Do not commit files that likely contain secrets (.env, credentials.json, etc). Warn the user if they specifically request to commit those files
+- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit
+- Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported
+
+## Your task
+
+Based on the above changes, create a single git commit:
+
+1. Analyze all staged changes and draft a commit message:
+   - Look at the recent commits above to follow this repository's commit message style
+   - Summarize the nature of the changes (new feature, enhancement, bug fix, refactoring, test, docs, etc.)
+   - Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.)
+   - Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
+
+2. Stage relevant files and create the commit using HEREDOC syntax:
+\`\`\`
+git commit -m "$(cat <<'EOF'
+Commit message here.${commitAttribution ? `\n\n${commitAttribution}` : ''}
+EOF
+)"
+\`\`\`
+
 You have the capability to call multiple tools in a single response. Stage and create the commit using a single message. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.`;
 }
 const command = {

package/dist/src/commands/init.js

@@ -1,95 +1,95 @@
 import { feature } from '../recovery/bunBundleShim.js';
 import { maybeMarkProjectOnboardingComplete } from '../projectOnboardingState.js';
 import { isEnvTruthy } from '../utils/envUtils.js';
-const OLD_INIT_PROMPT = `Analiza esta base de codigo y crea un archivo .context/CONTEXT.md para futuras sesiones de Context Code en este repositorio.
-
-Que debe incluir:
-1. Comandos realmente utiles y frecuentes: build, lint, test, desarrollo local y, si aplica, como ejecutar una sola prueba.
-2. Arquitectura y estructura de alto nivel: la vista general que normalmente requiere leer varios archivos para entenderse rapido.
-
-Notas de uso:
-- Si ya existe .context/CONTEXT.md, no lo sobrescribas a ciegas; sugiere mejoras concretas.
-- Evita repetir obviedades o reglas genericas.
-- No listes cada archivo o componente que pueda descubrirse facilmente.
-- Si existen reglas de Cursor, Copilot u otras herramientas, incorpora solo lo importante.
-- Si existe README.md, incorpora solo lo importante.
-- No inventes secciones ni informacion no respaldada por archivos reales.
-- El archivo debe comenzar exactamente con:
-
-\`\`\`
-# CONTEXT.md
-
-This file provides guidance to Context Code when working with code in this repository.
-\`\`\`
+const OLD_INIT_PROMPT = `Analiza esta base de codigo y crea un archivo .context/CONTEXT.md para futuras sesiones de Context Code en este repositorio.
+
+Que debe incluir:
+1. Comandos realmente utiles y frecuentes: build, lint, test, desarrollo local y, si aplica, como ejecutar una sola prueba.
+2. Arquitectura y estructura de alto nivel: la vista general que normalmente requiere leer varios archivos para entenderse rapido.
+
+Notas de uso:
+- Si ya existe .context/CONTEXT.md, no lo sobrescribas a ciegas; sugiere mejoras concretas.
+- Evita repetir obviedades o reglas genericas.
+- No listes cada archivo o componente que pueda descubrirse facilmente.
+- Si existen reglas de Cursor, Copilot u otras herramientas, incorpora solo lo importante.
+- Si existe README.md, incorpora solo lo importante.
+- No inventes secciones ni informacion no respaldada por archivos reales.
+- El archivo debe comenzar exactamente con:
+
+\`\`\`
+# CONTEXT.md
+
+This file provides guidance to Context Code when working with code in this repository.
+\`\`\`
 `;
-const NEW_INIT_PROMPT = `Configura un .context/CONTEXT.md minimo y, si aplica, habilidades y hooks para este repositorio. Todo debe quedar en espanol salvo nombres tecnicos, rutas y comandos.
-
-Fase 1:
-- Pregunta al usuario que desea configurar.
-- Ofrece estas opciones:
-  - "CONTEXT del proyecto"
-  - "CONTEXT personal"
-  - "Ambos"
-- Pregunta tambien si desea:
-  - "Habilidades y hooks"
-  - "Solo habilidades"
-  - "Solo hooks"
-  - "Solo CONTEXT"
-
-Fase 2:
-- Explora la base de codigo.
-- Revisa archivos clave como package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml, README, Makefile, CI, .context/rules/, AGENTS.md, .cursor/rules, .cursorrules, .github/copilot-instructions.md, .windsurfrules, .clinerules y .mcp.json.
-- Detecta:
-  - comandos de build, test y lint
-  - lenguajes, frameworks y package manager
-  - estructura general del proyecto
-  - reglas de estilo no obvias
-  - variables de entorno, gotchas o flujos especiales
-  - si ya existen .context/skills/ y .context/rules/
-  - configuracion de formatter
-  - uso de git worktree si hace falta para contenido personal
-
-Fase 3:
-- Pregunta solo lo que no puedas deducir del codigo.
-- Si el usuario quiere contexto de proyecto, pregunta por practicas del equipo, comandos no obvios, convenciones de ramas o PR y quirks reales.
-- Si el usuario quiere contexto personal, pregunta por su rol, nivel de familiaridad, preferencias de comunicacion, URLs de sandbox, cuentas de prueba o detalles locales.
-- Construye una propuesta compacta con:
-  - notas para CONTEXT.md
-  - habilidades sugeridas
-  - hooks sugeridos
-- Muestra la propuesta con AskUserQuestion usando preview compacto y en espanol.
-
-Fase 4:
-- Escribe un .context/CONTEXT.md minimo.
-- Cada linea debe responder a: "si quito esto, Context Code cometeria errores o perderia tiempo real?"
-- Incluye solo:
-  - comandos no obvios
-  - arquitectura de alto nivel
-  - reglas de estilo que se aparten de lo normal
-  - gotchas, setup o decisiones arquitectonicas importantes
-- Excluye:
-  - listados exhaustivos de archivos
-  - consejos genericos
-  - documentacion larga que pueda referenciarse aparte
-
-Fase 5:
-- Si el usuario eligio contenido personal, escribe la variante personal minima y mantenla privada.
-
-Fase 6:
-- Si el usuario eligio habilidades, crea solo habilidades utiles y especificas para este repo.
-- No sobrescribas habilidades existentes sin justificarlo.
-
-Fase 7:
-- Si el usuario eligio hooks, sugiere hooks concretos y utiles para este repo.
-- Si no eligio hooks, no insistas.
-
-Fase 8:
-- Resume en espanol que se creo, que archivos se tocaron y que pasos siguientes convienen.
-- Cierra con sugerencias breves y relevantes para mejorar la configuracion del repo.
-
-Muy importante:
-- Durante todo el flujo responde en espanol.
-- No uses mensajes de arranque en ingles como "I'll analyze..." o "Let me start...".
+const NEW_INIT_PROMPT = `Configura un .context/CONTEXT.md minimo y, si aplica, habilidades y hooks para este repositorio. Todo debe quedar en espanol salvo nombres tecnicos, rutas y comandos.
+
+Fase 1:
+- Pregunta al usuario que desea configurar.
+- Ofrece estas opciones:
+  - "CONTEXT del proyecto"
+  - "CONTEXT personal"
+  - "Ambos"
+- Pregunta tambien si desea:
+  - "Habilidades y hooks"
+  - "Solo habilidades"
+  - "Solo hooks"
+  - "Solo CONTEXT"
+
+Fase 2:
+- Explora la base de codigo.
+- Revisa archivos clave como package.json, pyproject.toml, Cargo.toml, go.mod, pom.xml, README, Makefile, CI, .context/rules/, AGENTS.md, .cursor/rules, .cursorrules, .github/copilot-instructions.md, .windsurfrules, .clinerules y .mcp.json.
+- Detecta:
+  - comandos de build, test y lint
+  - lenguajes, frameworks y package manager
+  - estructura general del proyecto
+  - reglas de estilo no obvias
+  - variables de entorno, gotchas o flujos especiales
+  - si ya existen .context/skills/ y .context/rules/
+  - configuracion de formatter
+  - uso de git worktree si hace falta para contenido personal
+
+Fase 3:
+- Pregunta solo lo que no puedas deducir del codigo.
+- Si el usuario quiere contexto de proyecto, pregunta por practicas del equipo, comandos no obvios, convenciones de ramas o PR y quirks reales.
+- Si el usuario quiere contexto personal, pregunta por su rol, nivel de familiaridad, preferencias de comunicacion, URLs de sandbox, cuentas de prueba o detalles locales.
+- Construye una propuesta compacta con:
+  - notas para CONTEXT.md
+  - habilidades sugeridas
+  - hooks sugeridos
+- Muestra la propuesta con AskUserQuestion usando preview compacto y en espanol.
+
+Fase 4:
+- Escribe un .context/CONTEXT.md minimo.
+- Cada linea debe responder a: "si quito esto, Context Code cometeria errores o perderia tiempo real?"
+- Incluye solo:
+  - comandos no obvios
+  - arquitectura de alto nivel
+  - reglas de estilo que se aparten de lo normal
+  - gotchas, setup o decisiones arquitectonicas importantes
+- Excluye:
+  - listados exhaustivos de archivos
+  - consejos genericos
+  - documentacion larga que pueda referenciarse aparte
+
+Fase 5:
+- Si el usuario eligio contenido personal, escribe la variante personal minima y mantenla privada.
+
+Fase 6:
+- Si el usuario eligio habilidades, crea solo habilidades utiles y especificas para este repo.
+- No sobrescribas habilidades existentes sin justificarlo.
+
+Fase 7:
+- Si el usuario eligio hooks, sugiere hooks concretos y utiles para este repo.
+- Si no eligio hooks, no insistas.
+
+Fase 8:
+- Resume en espanol que se creo, que archivos se tocaron y que pasos siguientes convienen.
+- Cierra con sugerencias breves y relevantes para mejorar la configuracion del repo.
+
+Muy importante:
+- Durante todo el flujo responde en espanol.
+- No uses mensajes de arranque en ingles como "I'll analyze..." o "Let me start...".
 - Cuando inicies el analisis, usa formulaciones en espanol como "Voy a revisar la base de codigo..." o similares.`;
 const command = {
     type: 'prompt',