Parece que en el contexto no entra siempre todo SKILLS.md, sino que al principio se incluye de forma fija solo la parte del nombre y la descripción, como lo de abajo.
name: skill-creator
description: Guía para crear skills efectivas. Esta skill debe usarse cuando los usuarios quieran crear una skill nueva (o actualizar una existente) que amplíe las capacidades de Claude con conocimiento especializado, flujos de trabajo o integraciones de herramientas.
license: Complete terms in LICENSE.txt
Parece que están defendiendo una filosofía de software libre demasiado extrema mientras usan internet por cables de cobre tendidos por empresas o, supuestamente como alternativa, por antenas satelitales.
Incluso si se lograra todo lo que está escrito aquí, siento que igual dirían que el código abierto no ganó.
Es cierto que Livewire es entretenido, pero en cuanto la UI se vuelve un poco más compleja, se convierte en un infierno. A partir de ese momento, Phoenix pierde claramente sus ventajas. Como se vuelve más difícil cuanto más largo es el ciclo, no puedo recomendarlo mucho.
¿Skills también usa tokens? Si es así, parece que volvería a surgir el problema del consumo de tokens, pero no tengo muy claro cómo responderían en ese caso.
Yo también en algún momento fui casi un creyente del serverless y lo promovía con mucha fuerza, pero últimamente prefiero más una estructura hecha con una sola instancia de EC2 y una sola de RDS. Y luego voy separando de a poco lo que se necesita. Ahora pienso mucho más antes de adoptar serverless.
Hay varias razones, pero incluso si en el equipo hay una sola persona que no tiene conocimientos de serverless, los costos de comunicación y mantenimiento aumentan bastante. Y al volver a operar servidores, volví a sentir que el serverless no era tan barato ni tan cómodo como pensaba.
Cuando trabajas con Claude Code, terminas alimentándole instrucciones o reglas al contexto una y otra vez, y al final acabas pensando en el equilibrio entre el uso de tokens y el contexto. Entonces se me ocurrió crear una carpeta, escribir ahí los detalles en archivos .md separados por función, y dejar en claude.md solo un montón de punteros de qué mirar para hacer cada cosa; y funcionó bastante bien y a bajo costo. Si al final Skills no es más que una recopilación de algo así, entonces parece que va a ser bastante útil.
La ingeniería siempre es una batalla de costos
Al principio se usa para reducir el tiempo de prototipado o de construcción del negocio
Más adelante hay que optimizar y reducir los costos
Un texto como este en sí mismo demuestra qué tan poco ingeniero es uno
Esto
De hecho, en nuestro país los sitios grandes usaban este método —mostrar un banner al acceder con IE7— para impulsar la salida de IE7 (ya sin soporte de MS). Recuerdo que el efecto fue enorme.
Grace Hopper:
"If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission."
"Si se te ocurre una buena idea, hazla de una vez. Es mucho más fácil pedir disculpas que pedir permiso."
El mantenimiento también consume recursos, así que si ahorraron recursos, ¿no será también una ganancia para la empresa?
> Se destinaban entre 1 y 2 semanas de los principales ciclos de sprint a corregir errores de IE6
según eso, no sé cómo será el ciclo de sprint de Google, pero si asumimos que es de un mes, se ahorran al menos un 25%..
Parece que en el contexto no entra siempre todo
SKILLS.md, sino que al principio se incluye de forma fija solo la parte del nombre y la descripción, como lo de abajo.name: skill-creator
description: Guía para crear skills efectivas. Esta skill debe usarse cuando los usuarios quieran crear una skill nueva (o actualizar una existente) que amplíe las capacidades de Claude con conocimiento especializado, flujos de trabajo o integraciones de herramientas.
license: Complete terms in LICENSE.txt
Aun así, al final parece que hicieron algo bueno.
Parece que están defendiendo una filosofía de software libre demasiado extrema mientras usan internet por cables de cobre tendidos por empresas o, supuestamente como alternativa, por antenas satelitales.
Incluso si se lograra todo lo que está escrito aquí, siento que igual dirían que el código abierto no ganó.
Es cierto que Livewire es entretenido, pero en cuanto la UI se vuelve un poco más compleja, se convierte en un infierno. A partir de ese momento, Phoenix pierde claramente sus ventajas. Como se vuelve más difícil cuanto más largo es el ciclo, no puedo recomendarlo mucho.
¿Skills también usa tokens? Si es así, parece que volvería a surgir el problema del consumo de tokens, pero no tengo muy claro cómo responderían en ese caso.
Es puro escándalo exagerado, de verdad.
Yo también en algún momento fui casi un creyente del serverless y lo promovía con mucha fuerza, pero últimamente prefiero más una estructura hecha con una sola instancia de EC2 y una sola de RDS. Y luego voy separando de a poco lo que se necesita. Ahora pienso mucho más antes de adoptar serverless.
Hay varias razones, pero incluso si en el equipo hay una sola persona que no tiene conocimientos de serverless, los costos de comunicación y mantenimiento aumentan bastante. Y al volver a operar servidores, volví a sentir que el serverless no era tan barato ni tan cómodo como pensaba.
Cuando trabajas con Claude Code, terminas alimentándole instrucciones o reglas al contexto una y otra vez, y al final acabas pensando en el equilibrio entre el uso de tokens y el contexto. Entonces se me ocurrió crear una carpeta, escribir ahí los detalles en archivos
.mdseparados por función, y dejar enclaude.mdsolo un montón de punteros de qué mirar para hacer cada cosa; y funcionó bastante bien y a bajo costo. Si al finalSkillsno es más que una recopilación de algo así, entonces parece que va a ser bastante útil.MSA, OneDrive, Copilot, etc... Ojalá dejaran de metérselos a la fuerza a los usuarios.
Espero que no haya malentendidos; no quise decir que Hacker News sea una tontería.
No hace falta divagar ni decir tonterías; al final, la clave parece ser simplemente cómo manejar el contexto de forma eficiente.
Claude Skills es increíble; podría ser una innovación aún mayor que MCP
GN+ acaba de resumirlo. ¡Échenle un vistazo también!
La ingeniería siempre es una batalla de costos
Al principio se usa para reducir el tiempo de prototipado o de construcción del negocio
Más adelante hay que optimizar y reducir los costos
Un texto como este en sí mismo demuestra qué tan poco ingeniero es uno
Esto
Se parece a Copilot Spaces y da la impresión de estar más automatizado.
Alineación en el dogmatismo (
alignment in dogmatism)De hecho, en nuestro país los sitios grandes usaban este método —mostrar un banner al acceder con IE7— para impulsar la salida de IE7 (ya sin soporte de MS). Recuerdo que el efecto fue enorme.
Parece una herramienta de vibe coding hecha con vibe coding; es sorprendente que la hayan creado en solo 5 días.
Grace Hopper:
"If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission."
"Si se te ocurre una buena idea, hazla de una vez. Es mucho más fácil pedir disculpas que pedir permiso."
Windows es una mierda. Es la primera vez que insulto aquí, pero de verdad Windows es una puta mierda.
El mantenimiento también consume recursos, así que si ahorraron recursos, ¿no será también una ganancia para la empresa?
> Se destinaban entre 1 y 2 semanas de los principales ciclos de sprint a corregir errores de IE6
según eso, no sé cómo será el ciclo de sprint de Google, pero si asumimos que es de un mes, se ahorran al menos un 25%..