Spec-Driven Development en React Native: un MVP que lista los sismos del mundo, especificado antes de escribir código

Here's a thinking process:

1. Analyze User Request:
   • Role: Expert editor for DevPlace (social network for software developers)
   • Task: Reformat raw article body into clean, readable Markdown for technical audience
   • Rules:
   • Break into short, well-structured paragraphs separated by blank lines
   • Add Markdown section headings (## Heading) where topic clearly shifts
   • Use bullet/numbered lists for enumerations, inline code/fenced code blocks for code/commands/identifiers
   • Preserve every fact, name, number, quotation exactly as given - never invent, add, remove, or reorder information
   • Only restructure and lightly polish wording for flow/grammar; no introduction, conclusion, opinion, or commentary
   • Do not repeat article title as heading, do not wrap whole answer in code fence
   • Output only reformatted article body as Markdown, nothing else

• Input: Article text with title: "Spec-Driven Development en React Native: un MVP que lista los sismos del mundo, especificado antes de escribir código"
• Current date: 06/09/2026 (not directly relevant to formatting)

2. Deconstruct the Article Text:
   Let me carefully go through the article and identify sections, topics, enumerations, code/commands, etc. I need to preserve every fact, name, number, quotation exactly.

Key parts:

• Title is given separately, I should not repeat it as a heading in the output (rule: "Do not repeat the article title as a heading")
• The article body starts with: "Un agente de código ya escribe una app funcional en una tarde..."
• It goes on with various paragraphs
• There are lists, commands, headings structure implied
• There's a TL;DR section
• There's a comparison between prompt and specification
• There's a hierarchy: Specification → Plan técnico → Tareas → Implementación
• There's mention of Spec Kit, GitHub, commands like uvx --from git+https://github.com/github/spec-kit.git specify init sismos-app
• There are markdown commands: # /constitution, # /specify, etc.
• Ends with: "Sigue leyendo Hasta aquí la primera mitad. El recorrido completo - con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción - está en mi blog: Lee el artículo completo en ramonchancay.me → Publicado originalmente en www.ramonchancay.me/es/blog/spec-driven-development-react-native-app-sismos. Top comments (0)"

I need to structure this into Markdown with:

• Section headings (##) where topic shifts
• Short paragraphs separated by blank lines
• Bullet/numbered lists for enumerations
• Inline code/fenced code blocks for code/commands/identifiers
• Preserve all facts, names, numbers, quotations exactly

Let me outline the structure based on topic shifts:

Topic 1: Introduction to the problem - agents writing code without specs, SDD solution
Topic 2: TL;DR summary of SDD artifacts
Topic 3: What is SDD and how it differs from prompting
Topic 4: The artifact hierarchy (Specification → Plan técnico → Tareas → Implementación)
Topic 5: Rules about levels of abstraction
Topic 6: Tools that formalize the flow (Spec Kit)
Topic 7: Commands and how to use Spec Kit
Topic 8: Conclusion/remaining text about blog post

Now, I need to be very careful to preserve every exact word, number, quotation. I'll need to keep Spanish text as is, keep numbers, keep command strings exactly.

Let me re-read the article carefully and extract segments, ensuring I don't lose or change anything.

Original article text (I'll copy it here for reference):
"Un agente de código ya escribe una app funcional en una tarde. El problema dejó de ser producir el código y pasó a ser otro: el agente no escribe peor código sin una especificación, escribe un código excelente para el problema equivocado. Cada pregunta que no contestaste la contesta él con un valor por defecto razonable, y lo descubres semanas después. El Spec-Driven Development (SDD) ataca justo eso: escribir primero qué debe hacer el software, resolver por escrito lo que está ambiguo, y tratar el código como el resultado de esa especificación. Lo apliqué a un MVP en React Native con Expo que hace una sola cosa -mostrar un listado de los sismos recientes en todo el mundo- porque es el tipo de pedido que cabe en una línea y esconde más decisiones de las que parece. TL;DR SDD separa tres artefactos: la especificación (qué y por qué), el plan técnico (cómo) y las tareas. El agente implementa contra ellos en vez de contra un prompt suelto. El valor real no es el documento: es que las ambigüedades quedan marcadas y resueltas por escrito antes de que el agente elija por ti. Qué sismos entran en la lista, en qué orden y qué pasa sin conexión son decisiones de producto, no de código. Los criterios de aceptación se escriben como una tabla de casos y esa misma tabla se convierte en el test. Si la fila no está en la tabla, el comportamiento no está definido. Qué es el Spec-Driven Development y en qué se diferencia de prompting Un prompt es una instrucción que se consume y desaparece. Una especificación es un archivo versionado en el repositorio, que se revisa en un pull request y que sobrevive a la sesión del agente. Esa es toda la diferencia, y es más grande de lo que parece. En el flujo típico con un agente, describes la funcionalidad en el chat y el resultado son mil líneas de código más una conversación que nadie va a releer. Las decisiones importantes -la magnitud mínima, cuántas horas hacia atrás, qué pasa sin conexión- quedaron en un turno intermedio del chat. Cuando alguien pregunta por qué la app muestra un sismo de magnitud 2.6 y no uno de 2.4, la respuesta no está en ninguna parte. SDD separa el trabajo en artefactos distintos, cada uno con su propio nivel de abstracción: Especificación → qué debe pasar y por qué │ ▼ Plan técnico → cómo se implementa (stack, librerías, estructura) │ ▼ Tareas → unidades de trabajo verificables │ ▼ Implementación → el código que el agente escribe contra lo anterior La regla que ordena todo es que cada nivel habla de su nivel. La especificación evita decisiones de implementación salvo que sean una restricción real del producto: "debe funcionar sin conexión" o "los datos no salen del dispositivo" son requisitos aunque tengan consecuencias técnicas; "usar TanStack Query" no lo es. El plan sí nombra tecnología, pero no reabre decisiones de producto. Cuando esa separación se respeta, puedes cambiar de stack sin reescribir la especificación, y cambiar un umbral sin tocar el plan. Hay herramientas que formalizan este flujo. Spec Kit , de GitHub, instala una serie de comandos en tu agente que producen exactamente estos artefactos en carpetas del repositorio: # Instala el flujo en el proyecto y elige el agente que vas a usar. uvx --from git+https://github.com/github/spec-kit.git specify init sismos-app # A partir de ahí, dentro del agente: # /constitution → principios del proyecto (aplican a todas las features) # /specify → la especificación de esta feature # /clarify → resuelve las ambigüedades marcadas en la spec # /plan → el plan técnico # /tasks → el desglose en tareas # /implement → ejecuta las tareas No hace falta la herramienta: tres archivos markdown en specs/ y la disciplina de mantenerlos alcanzan. Lo que aporta es que el agente tiene los comandos, las plantillas y el orden ya cargados, y no se salta pasos. Sigue leyendo Hasta aquí la primera mitad. El recorrido completo - con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción - está en mi blog: Lee el artículo completo en ramonchancay.me → Publicado originalmente en www.ramonchancay.me/es/blog/spec-driven-development-react-native-app-sismos . Top comments (0)"

Important: The last part "Top comments (0)" might be part of the original text, but it's likely a platform artifact. The rule says "Preserve every fact, name, number, and quotation exactly as given." I should include it if it's part of the article, but it might be a comment section footer. I'll include it as-is since it's in the text, but I'll treat it as part of the article body.

Also, there are em-dashes and special characters: -mostrar, - SDD, -, con el resto de la implementación, etc. I need to preserve those exactly.

Now, let me plan the Markdown structure:

I'll create sections with ## headings where topics shift. I need to identify natural breaks:

1. The problem and SDD introduction
2. The MVP example and TL;DR
3. SDD vs prompting
4. The artifact hierarchy
5. Rules about levels of abstraction
6. Tools: Spec Kit
7. Commands and usage
8. Final note about not needing the tool

But I must be careful: the rule says "Add Markdown section headings (## Heading) where the topic clearly shifts, so the article scans well." I should not over-headline, but use them where topic clearly shifts.

Also: "Do not repeat the article title as a heading" - so I won't add ## Spec-Driven Development en React Native... as a heading.

Let me outline the paragraphs and lists:

First paragraph(s): Starting text about agent writing code, the problem, SDD solution.
Then the TL;DR can be a bullet list or a short paragraph. The text says: "TL;DR SDD separa tres artefactos: la especificación (qué y por qué), el plan técnico (cómo) y las tareas. El agente implementa contra ellos en vez de contra un prompt suelto. El valor real no es el documento: es que las ambigüedades quedan marcadas y resueltas por escrito antes de que el agente elija por ti. Qué sismos entran en la lista, en qué orden y qué pasa sin conexión son decisiones de producto, no de código. Los criterios de aceptación se escriben como una tabla de casos y esa misma tabla se convierte en el test. Si la fila no está en la tabla, el comportamiento no está definido."

I could format the TL;DR as a bullet list, but the rule says "Use bullet or numbered lists for enumerations". The TL;DR has enumerated points. I could make them a list. But I need to preserve the exact wording. I can create a markdown list where each item is one of those sentences, but I must ensure I don't alter the wording. The original text has them as separate sentences in a paragraph. I could keep them as a paragraph, or make a list. The rule says "Use bullet or numbered lists for enumerations". The TL;DR is essentially an enumeration of points. I think making a bullet list would be appropriate, but I need to check if the user wants me to preserve the exact flow. The rule: "Only restructure and lightly polish wording for flow and grammar; do not add an introduction, conclusion, opinion, or commentary of your own." and "Use bullet or numbered lists for enumerations". So I can convert the TL;DR points into a bullet list, as long as I preserve the exact text of each point.

Similarly, other enumerations: "Qué es el Spec-Driven Development y en qué se diferencia de prompting" section has comparisons. I can use lists there.

The hierarchy: "SDD separa el trabajo en artefactos distintos, cada uno con su propio nivel de abstracción: Especificación → qué debe pasar y por qué │ ▼ Plan técnico → cómo se implementa (stack, librerías, estructura) │ ▼ Tareas → unidades de trabajo verificables │ ▼ Implementación → el código que el agente escribe contra lo anterior" This is a hierarchy that could be a nested list or a code block, but it's text. I could format it as a markdown list with indentation, or keep as inline with pipes. The rule says "Use inline code or fenced code blocks where code, commands, or identifiers appear." This sentence contains arrows and pipes, but it's not code. I'll treat it as text, maybe format as a list.

The rules about levels: "La especificación evita decisiones de implementación salvo que sean una restricción real del producto: "debe funcionar sin conexión" o "los datos no salen del dispositivo" son requisitos aunque tengan consecuencias técnicas; "usar TanStack Query" no lo es. El plan sí nombra tecnología, pero no reabre decisiones de producto. Cuando esa separación se respeta, puedes cambiar de stack sin reescribir la especificación, y cambiar un umbral sin tocar el plan." This has quoted strings: "debe funcionar sin conexión", "los datos no salen del dispositivo", "usar TanStack Query". I need to preserve those exact quotes. I can use blockquotes or inline code for the quotes? The rule says "Use inline code or fenced code blocks where code, commands, or identifiers appear." The quoted phrases are not code, but they are identifiers/strings. I think I should keep them as regular text, but maybe use inline code debe funcionar sin conexión? The rule says "where code, commands, or identifiers appear". These are product requirements, not code. I'll keep them as regular text, but I can use quotes as given. The original has them with double quotes. I'll preserve the double quotes.

The Spec Kit section: "Hay herramientas que formalizan este flujo. Spec Kit , de GitHub, instala una serie de comandos en tu agente que producen exactamente estos artefactos en carpetas del repositorio: # Instala el flujo en el proyecto y elige el agente que vas a usar. uvx --from git+https://github.com/github/spec-kit.git specify init sismos-app # A partir de ahí, dentro del agente: # /constitution → principios del proyecto (aplican a todas las features) # /specify → la especificación de esta feature # /clarify → resuelve las ambigüedades marcadas en la spec # /plan → el plan técnico # /tasks → el desglose en tareas # /implement → ejecuta las tareas No hace falta la herramienta: tres archivos markdown en specs/ y la disciplina de mantenerlos alcanzan. Lo que aporta es que el agente tiene los comandos, las plantillas y el orden ya cargados, y no se salta pasos."

This has commands: uvx --from git+https://github.com/github/spec-kit.git specify init sismos-app and # /constitution, etc. I should format these as code blocks or inline code. The rule: "Use inline code or fenced code blocks where code, commands, or identifiers appear." So I'll use inline code for the command string, and maybe list the agent commands.

The last part: "Sigue leyendo Hasta aquí la primera mitad. El recorrido completo - con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción - está en mi blog: Lee el artículo completo en ramonchancay.me → Publicado originalmente en www.ramonchancay.me/es/blog/spec-driven-development-react-native-app-sismos . Top comments (0)" I'll keep as is.

Now, I need to decide on the overall structure with headings. I'll use ## for major sections. Let me identify section shifts:

• Start: problem description and SDD concept
• TL;DR summary
• SDD vs prompting
• Artifact hierarchy and rules
• Tools: Spec Kit and commands
• Conclusion/remaining text

I'll create headings like:

El problema del código sin especificación

TL;DR: los tres artefactos del SDD

Spec-Driven Development vs prompting

Jerarquía de artefactos y niveles de abstracción

Reglas de separación por nivel

Herramientas: Spec Kit y flujo de trabajo

Nota final

But I need to ensure I'm not adding headings that misrepresent or are unnecessary. The rule: "Add Markdown section headings (## Heading) where the topic clearly shifts, so the article scans well." I think it's okay to have headings that reflect the topic shifts in the text.

Let me now carefully go through the text and split into paragraphs, ensuring I preserve every word. I'll write the Markdown in a text editor mentally, but I'll output directly.

Important: I must not add any commentary, introduction, conclusion. Output only the reformatted article body as Markdown.

Let me start constructing:

First, I'll take the initial paragraph(s):
"Un agente de código ya escribe una app funcional en una tarde. El problema dejó de ser producir el código y pasó a ser otro: el agente no escribe peor código sin una especificación, escribe un código excelente para el problema equivocado. Cada pregunta que no contestaste la contesta él con un valor por defecto razonable, y lo descubres semanas después. El Spec-Driven Development (SDD) ataca justo eso: escribir primero qué debe hacer el software, resolver por escrito lo que está ambiguo, y tratar el código como el resultado de esa especificación."

Then: "Lo apliqué a un MVP en React Native con Expo que hace una sola cosa -mostrar un listado de los sismos recientes en todo el mundo- porque es el tipo de pedido que cabe en una línea y esconde más decisiones de las que parece."

Then TL;DR section. I'll make a heading "## TL;DR: los tres artefactos del SDD" or similar, but the rule says "Do not repeat the article title as a heading". The title is "Spec-Driven Development en React Native: un MVP que lista los sismos del mundo, especificado antes de escribir código". So I can use "## TL;DR" as long as it's not the title. I'll be careful.

Actually, looking at the rule: "Do not repeat the article title as a heading and do not wrap the whole answer in a code fence." So I can have other headings.

Let me plan the exact markdown output. I'll go paragraph by paragraph, combining where appropriate, using lists for enumerations, code blocks for commands.

I need to be extremely precise with preservation. Let me copy each segment exactly.

Segment 1:
"Un agente de código ya escribe una app funcional en una tarde. El problema dejó de ser producir el código y pasó a ser otro: el agente no escribe peor código sin una especificación, escribe un código excelente para el problema equivocado. Cada pregunta que no contestaste la contesta él con un valor por defecto razonable, y lo descubres semanas después. El Spec-Driven Development (SDD) ataca justo eso: escribir primero qué debe hacer el software, resolver por escrito lo que está ambiguo, y tratar el código como el resultado de esa especificación. Lo apliqué a un MVP en React Native con Expo que hace una sola cosa -mostrar un listado de los sismos recientes en todo el mundo- porque es el tipo de pedido que cabe en una línea y esconde más decisiones de las que parece."

Segment 2 (TL;DR):
"TL;DR SDD separa tres artefactos: la especificación (qué y por qué), el plan técnico (cómo) y las tareas. El agente implementa contra ellos en vez de contra un prompt suelto. El valor real no es el documento: es que las ambigüedades quedan marcadas y resueltas por escrito antes de que el agente elija por ti. Qué sismos entran en la lista, en qué orden y qué pasa sin conexión son decisiones de producto, no de código. Los criterios de aceptación se escriben como una tabla de casos y esa misma tabla se convierte en el test. Si la fila no está en la tabla, el comportamiento no está definido."

Segment 3:
"Qué es el Spec-Driven Development y en qué se diferencia de prompting Un prompt es una instrucción que se consume y desaparece. Una especificación es un archivo versionado en el repositorio, que se revisa en un pull request y que sobrevive a la sesión del agente. Esa es toda la diferencia, y es más grande de lo que parece. En el flujo típico con un agente, describes la funcionalidad en el chat y el resultado son mil líneas de código más una conversación que nadie va a releer. Las decisiones importantes -la magnitud mínima, cuántas horas hacia atrás, qué pasa sin conexión- quedaron en un turno intermedio del chat. Cuando alguien pregunta por qué la app muestra un sismo de magnitud 2.6 y no uno de 2.4, la respuesta no está en ninguna parte."

Segment 4:
"SDD separa el trabajo en artefactos distintos, cada uno con su propio nivel de abstracción: Especificación → qué debe pasar y por qué │ ▼ Plan técnico → cómo se implementa (stack, librerías, estructura) │ ▼ Tareas → unidades de trabajo verificables │ ▼ Implementación → el código que el agente escribe contra lo anterior"

Segment 5:
"La regla que ordena todo es que cada nivel habla de su nivel. La especificación evita decisiones de implementación salvo que sean una restricción real del producto: "debe funcionar sin conexión" o "los datos no salen del dispositivo" son requisitos aunque tengan consecuencias técnicas; "usar TanStack Query" no lo es. El plan sí nombra tecnología, pero no reabre decisiones de producto. Cuando esa separación se respeta, puedes cambiar de stack sin reescribir la especificación, y cambiar un umbral sin tocar el plan."

Segment 6:
"Hay herramientas que formalizan este flujo. Spec Kit , de GitHub, instala una serie de comandos en tu agente que producen exactamente estos artefactos en carpetas del repositorio: # Instala el flujo en el proyecto y elige el agente que vas a usar. uvx --from git+https://github.com/github/spec-kit.git specify init sismos-app # A partir de ahí, dentro del agente: # /constitution → principios del proyecto (aplican a todas las features) # /specify → la especificación de esta feature # /clarify → resuelve las ambigüedades marcadas en la spec # /plan → el plan técnico # /tasks → el desglose en tareas # /implement → ejecuta las tareas"

Segment 7:
"No hace falta la herramienta: tres archivos markdown en specs/ y la disciplina de mantenerlos alcanzan. Lo que aporta es que el agente tiene los comandos, las plantillas y el orden ya cargados, y no se salta pasos. Sigue leyendo Hasta aquí la primera mitad. El recorrido completo - con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción - está en mi blog: Lee el artículo completo en ramonchancay.me → Publicado originalmente en www.ramonchancay.me/es/blog/spec-driven-development-react-native-app-sismos . Top comments (0)"

Now, I need to format these into Markdown with:

• Short paragraphs separated by blank lines

• headings where topic shifts

• Bullet/numbered lists for enumerations
• Inline code/fenced code blocks for code/commands/identifiers
• Preserve all exact facts, names, numbers, quotations

Let me decide on headings. I'll use:

• After the first paragraph block, maybe no heading needed, or a heading like "## Spec-Driven Development: una nueva abordaje". But I need to see where topics clearly shift. The first block is about the problem and introduction. Then TL;DR is a clear shift. Then "Qué es el Spec-Driven Development..." is a shift. Then the hierarchy is a shift. Then rules about levels is a shift. Then tools is a shift. Then final note.

I'll structure headings as follows:

Spec-Driven Development: escribir qué debe hacer el software

(This covers the first segment, but the rule says don't repeat the article title. The title is "Spec-Driven Development en React Native: un MVP que lista los sismos del mundo, especificado antes de escribir código". Using "Spec-Driven Development: escribir qué debe hacer el software" is not repeating the title, it's a heading derived from content. I think it's okay.)

But maybe safer to use minimal headings, or just use the natural topic shifts. Let me re-read the rule: "Add Markdown section headings (## Heading) where the topic clearly shifts, so the article scans well." It doesn't say I must have headings for every shift, but I should add them where clear. I'll add headings for major sections.

Let me try to outline with headings that are not the title:

1. First part: problem and SDD intro. I could put a heading "## El enfoque Spec-Driven Development" but that might be too close to title. I'll maybe not put a heading for the very first block, or use a very generic one. Actually, the article starts with text, no heading. I can add a heading after the first paragraph if needed. But to be safe, I'll add headings only where the topic clearly shifts to a new theme.

Let me identify clear shifts:

• After "Lo apliqué a un MVP en React Native..." the TL;DR starts. That's a shift.
• After TL;DR, "Qué es el Spec-Driven Development y en qué se diferencia de prompting" is a new section heading in the original text? Actually it just starts with "Qué es el Spec-Driven Development...". That's a shift from the TL;DR summary to the conceptual explanation.
• Then the hierarchy sentence "SDD separa el trabajo en artefactos distintos..." is a shift.
• Then "La regla que ordena todo es que cada nivel habla de su nivel..." is a continuation or shift.
• Then "Hay herramientas que formalizan este flujo. Spec Kit..." is a shift to tools.
• Then the final paragraph about not needing the tool and the blog reference.

I'll use headings like:

TL;DR: los tres artefactos del SDD

Spec-Driven Development vs prompting

Jerarquía de artefactos y niveles de abstracción

Reglas de separación por nivel

Herramientas: Spec Kit y flujo de trabajo

Nota final

But I need to ensure that the headings don't become commentary or alter the structure improperly. The rule says "Only restructure and lightly polish wording for flow and grammar". Headings are part of restructuring.

Let me now construct the Markdown carefully. I'll keep the text as is, but break into paragraphs, add headings, and format lists/code.

Important: The TL;DR text starts with "TL;DR SDD separa...". I should probably keep "TL;DR" as part of the text. I could make a heading "## TL;DR" but the text already has "TL;DR