context-driven-development

Visión general de la skill context-driven-development

Qué hace la skill context-driven-development

La skill context-driven-development te ayuda a crear y mantener un pequeño conjunto de artefactos de contexto del proyecto dentro de un directorio conductor/, para que el desarrollo asistido por IA tenga una base estable y reutilizable. En lugar de volver a explicar tu proyecto en cada chat, defines documentos clave como product.md, tech-stack.md, workflow.md y tracks.md, y luego los actualizas a medida que el proyecto evoluciona.

Quién debería instalarla

Esta skill encaja especialmente bien con personas que usan flujos de trabajo al estilo Conductor, desarrollo con IA en múltiples sesiones o entornos de equipo donde la intención del proyecto, las decisiones de stack y el seguimiento del trabajo deben mantenerse consistentes entre prompts. Resulta especialmente útil para:

• puesta en marcha de proyectos nuevos
• onboarding de un agente de IA a una base de código existente
• equipos que quieren un contexto de proyecto repetible
• usuarios cansados de perder contexto entre sesiones

La necesidad real que resuelve

La mayoría de los usuarios no necesitan “más documentación”. Necesitan que las salidas de la IA dejen de desviarse. El trabajo práctico de context-driven-development es convertir conocimiento de proyecto vago y limitado a una sesión en artefactos gestionados que sobreviven entre tareas de implementación, planificación y handoffs.

Qué la diferencia del prompting habitual

Un prompt normal puede describir tu app una vez. La context-driven-development skill te da una estructura para mantener esa descripción actualizada y coherente internamente con el paso del tiempo. Su diferencia clave no es la generación de código por sí sola, sino el andamiaje de contexto y su sincronización antes y durante el desarrollo.

Qué obtienes si encaja con tu caso

Si usas context-driven-development for Context Engineering, el beneficio principal es una mejor continuidad:

• intención de producto más clara
• decisiones de stack documentadas
• expectativas de workflow explícitas
• unidades de trabajo trazadas en lugar de TODOs sueltos
• mejor onboarding de agentes en repos brownfield

Cuándo no encaja bien

Sáltate esta skill si solo necesitas un snippet puntual de código, no tienes intención de mantener documentación del proyecto o no trabajas con un flujo donde el contexto persistente mejore resultados posteriores. Aporta más valor cuando el mismo proyecto va a tocarse de forma repetida.

Cómo usar la skill context-driven-development

Contexto de instalación y dónde vive esta skill

Esta skill proviene del repositorio wshobson/agents, en plugins/conductor/skills/context-driven-development. El patrón base de instalación en entornos con Skills es:

npx skills add https://github.com/wshobson/agents --skill context-driven-development

Después de instalarla, invócala desde tu entorno de IA cuando necesites crear o actualizar contexto del proyecto, en lugar de saltar directamente a la implementación.

Lee primero estos archivos antes del primer uso

Para empezar rápido y con pocas suposiciones, lee:

1. plugins/conductor/skills/context-driven-development/SKILL.md
2. plugins/conductor/skills/context-driven-development/references/artifact-templates.md

SKILL.md explica cuándo usar la skill, cómo se relacionan los artefactos y cuál es el flujo de mantenimiento. references/artifact-templates.md es el acelerador práctico: muestra la forma esperada de product.md, tech-stack.md y archivos relacionados, para que puedas dar al agente inputs completos más deprisa.

Qué entradas necesita la skill context-driven-development

La skill funciona mejor cuando le das suficiente material fuente para generar o actualizar artefactos de contexto. Los buenos inputs suelen incluir:

• tipo de proyecto: greenfield o brownfield
• repositorio actual o estructura de carpetas
• propósito del producto y usuarios objetivo
• restricciones técnicas y decisiones de stack
• preferencias de workflow de desarrollo
• roadmap actual, hitos o work items
• documentación existente como README.md, tickets, notas de arquitectura o código

Si solo dices “set up context for my app”, la salida será genérica. Si aportas evidencia del producto, del stack, del workflow y del repositorio existente, los artefactos pasan a ser mucho más accionables.

Uso en greenfield: empezar un proyecto nuevo

Para un proyecto nuevo, usa context-driven-development para crear los artefactos principales antes de escribir demasiado código. Una buena solicitud incluye:

• qué es el producto
• a quién sirve
• qué funcionalidades entran o quedan fuera de alcance
• stack esperado
• expectativas de despliegue y testing
• cómo debe seguirse el trabajo

Aquí es donde más valor aporta la skill, porque obliga a tomar decisiones que de otro modo seguirían difusas hasta que empiece la implementación.

Uso en brownfield: extraer contexto de un repositorio existente

Para una base de código existente, pídele a la skill que infiera y organice contexto a partir del repositorio. Oriéntala hacia:

• árbol de código fuente
• archivos de dependencias
• configuración de CI
• README e historial de issues
• documentación existente
• convenciones de nombres y pistas sobre el workflow

Aquí es donde muchos usuarios obtienen valor rápidamente: la context-driven-development guide ayuda a convertir un repositorio que “funciona pero cuesta explicar” en artefactos que un agente puede reutilizar después.

Artefactos principales y para qué sirve cada uno

El repositorio se centra en unos pocos archivos persistentes dentro de conductor/:

• product.md: problema, usuarios, solución, funcionalidades, métricas, roadmap
• tech-stack.md: lenguajes, frameworks, dependencias, infraestructura, herramientas
• workflow.md: cómo se espera que ocurra el desarrollo
• tracks.md: unidades de trabajo, estado u organización continua de la entrega

La idea importante no es solo crear archivos, sino mantener relaciones entre ellos. Las decisiones de producto deben concordar con las decisiones de stack, las reglas de workflow deben reflejar la realidad del equipo y el trabajo trazado debe alinearse con el roadmap y las prioridades de implementación.

Convierte un objetivo difuso en una invocación sólida

Un prompt débil:

• “Use context-driven-development for my project.”

Un prompt más sólido:

• “Use context-driven-development to create initial conductor/ artifacts for a brownfield SaaS repo. Infer product scope from README.md, src/, and issue labels. Capture stack choices from package.json, Docker config, and CI. Create product.md, tech-stack.md, workflow.md, and tracks.md. Flag assumptions separately from confirmed facts.”

Por qué funciona mejor:

• indica el estado del repo
• nombra los artefactos objetivo
• da fuentes de evidencia
• pide separar suposiciones de hechos

Workflow recomendado para adoptar context-driven-development por primera vez

Un flujo práctico de context-driven-development usage sería:

1. Reúne la evidencia actual del repositorio y la documentación.
2. Pide a la skill que redacte los artefactos principales de conductor/.
3. Revísalos en busca de errores factuales y restricciones ausentes.
4. Resuelve contradicciones entre los documentos de producto, stack y workflow.
5. Solo entonces empieza tareas de implementación o planificación que dependan de esos artefactos.
6. Vuelve a ejecutar la skill tras cambios importantes de alcance, arquitectura o workflow.

Esta secuencia importa porque la skill está pensada para mejorar el trabajo posterior, no solo para generar documentos una vez.

Cómo aprovechar bien las plantillas de artefactos

El archivo references/artifact-templates.md resulta útil cuando la skill solo tiene información parcial. En vez de dejar que el agente invente secciones que faltan, da respuestas directas para campos de plantilla como:

• personas objetivo
• estado de funcionalidades
• métricas de éxito
• justificación de dependencias
• elección de hosting
• toolchain de test y lint

Cuanto más de la plantilla puedas completar con restricciones reales, menos limpieza tendrás que hacer después.

Consejos prácticos que mejoran de verdad la calidad de la salida

Para obtener mejores resultados con context-driven-development usage:

• pide al agente que marque explícitamente lo desconocido
• separa el estado actual del estado futuro deseado
• indícale si las decisiones están cerradas, son tentativas o siguen abiertas
• aporta ejemplos del workflow de tu equipo si workflow.md importa
• solicita comprobaciones de consistencia antes de dar por buenos los artefactos

Un patrón útil es: “Draft, then validate for cross-file contradictions.” Así detectas desajustes como un roadmap que promete apps móviles mientras el stack y el workflow implican un MVP solo web.

FAQ de la skill context-driven-development

¿Merece la pena instalar context-driven-development si ya escribo buenos prompts?

Por lo general, sí, si vuelves al mismo proyecto con frecuencia. Los buenos prompts ayudan dentro de una sesión. La context-driven-development skill ayuda a crear contexto duradero al que los prompts posteriores pueden remitirse, en lugar de reconstruirlo desde cero.

¿Es apta para principiantes?

Sí, pero solo si estás preparado para responder preguntas básicas sobre el proyecto. La skill aporta estructura, no claridad de negocio. Los principiantes con objetivos de proyecto vagos pueden seguir obteniendo artefactos genéricos hasta que definan con más precisión usuarios, funcionalidades y restricciones.

¿Solo funciona con Conductor?

Está diseñada para artefactos de contexto al estilo Conductor, así que ese es su mejor encaje. Aun así, el método subyacente es portable: documentos estructurados de producto, stack, workflow y tracking también pueden ayudar en otras configuraciones asistidas por IA.

¿Cuál es el principal límite de la skill?

No sustituye la experiencia de implementación ni la revisión de diseño de sistemas. context-driven-development es más fuerte a la hora de organizar el contexto del proyecto, sacar a la luz relaciones entre artefactos y mantener la documentación alineada con el trabajo.

¿En qué se diferencia de limitarse a mantener un README?

Un README suele ser más general y estar orientado a la audiencia. Esta skill empuja hacia contexto operativo para desarrollo: qué es el producto, cómo se eligió el stack, cómo avanza el trabajo y qué debería mantenerse consistente entre sesiones del agente.

¿Cuándo no debería usar context-driven-development?

No la uses para experimentos pequeños y desechables, scripts puntuales o proyectos en los que no vayas a mantener los artefactos. El valor viene de la reutilización continua y la sincronización, no solo del primer borrador.

Cómo mejorar la skill context-driven-development

Dale a la skill evidencia, no aspiraciones

El mayor salto de calidad llega cuando fundamentas la skill en evidencia real del repositorio y en decisiones concretas. Adjunta o referencia archivos, configuraciones y listas de funcionalidades reales. Si solo aportas aspiraciones, los artefactos sonarán a documentos genéricos de planificación en vez de a contexto útil de trabajo.

Pide hechos confirmados frente a suposiciones inferidas

Un fallo habitual es mezclar hechos observados del repositorio con conjeturas. Mejora las salidas de context-driven-development pidiendo dos capas:

• confirmado a partir de archivos o documentación
• inferido a partir de patrones o de información ausente

Eso hace que la revisión sea mucho más rápida y reduce desvíos accidentales.

Ajusta cada artefacto en torno a decisiones

A los usuarios les importa sobre todo si los artefactos ayudan en sesiones posteriores de coding. Para mejorar eso, haz que cada archivo esté orientado a decisiones:

• product.md: quién, problema, alcance, métricas de éxito
• tech-stack.md: herramientas elegidas y por qué
• workflow.md: cómo se proponen, construyen, prueban y revisan los cambios
• tracks.md: qué está activo, bloqueado, viene después o ya está hecho

Si una sección no puede guiar una decisión futura de coding, recórtala.

Valida la consistencia antes de confiar en la salida

La skill es más útil cuando le pides que compruebe contradicciones como:

• alcance de producto que excede el roadmap
• decisiones de stack que chocan con restricciones de despliegue
• expectativas de workflow que el tooling del repo no respalda
• tracks que no coinciden con las prioridades actuales

Este paso de validación es uno de los hábitos de mayor valor para context-driven-development for Context Engineering.

Mejora los prompts con instrucciones de lectura del repositorio

En lugar de decir “analyze my repo”, especifica dónde está la verdad. Por ejemplo:

• “Use package.json, Dockerfile, .github/workflows/, and README.md as primary evidence.”
• “Treat issue labels and milestone names as workflow clues.”
• “Prefer explicit config over naming heuristics.”

Esto reduce detalles inventados sobre el stack y el proceso.

Itera después del primer borrador, no antes

Un buen patrón es draft -> review -> refine. Primero pide artefactos completos y luego lanza una segunda pasada como:

• eliminar relleno genérico
• añadir restricciones que faltan
• convertir suposiciones en preguntas
• alinear tracks con el roadmap
• actualizar la justificación del stack con versiones exactas cuando se conozcan

Esa iteración suele funcionar mejor que intentar perfeccionar el primer prompt.

Mantén vivos los artefactos a medida que el proyecto cambia

La decisión de context-driven-development install solo compensa si la documentación se mantiene al día. Vuelve a ejecutar o revisar la skill cuando:

• cambie la arquitectura
• se muevan las prioridades
• cambie el tooling
• aparezca fricción en el onboarding
• las salidas del agente empiecen a desviarse de la realidad del proyecto

Un contexto desactualizado suele ser peor que no tener contexto, porque genera una falsa sensación de confianza.