# Simple Issue Description > Convierte un reporte de bug tosco, una petición de feature, una nota de soporte o un PR en un issue corto y en lenguaje llano, centrado en el problema y el comportamiento deseado. Fuente: https://skillsagentes.com/skills/every-app/open-seo/simple-issue-description Markdown: https://skillsagentes.com/skills/every-app/open-seo/simple-issue-description.md Repositorio: https://github.com/every-app/open-seo Autor: every-app Licencia: MIT Actualizado: hace 13 días Coste de contexto: 88 tok instalada, 1.2k tok al activarse, 1.2k tok con todos los archivos del bundle Bundle: 2 archivos, 5 KB Permisos que pide: ninguno declarado ## Instalación Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina. ```bash # Claude Code npx -y skills add every-app/open-seo --skill simple-issue-description --agent claude-code # Cursor npx -y skills add every-app/open-seo --skill simple-issue-description --agent cursor # Codex npx -y skills add every-app/open-seo --skill simple-issue-description --agent codex # Gemini CLI npx -y skills add every-app/open-seo --skill simple-issue-description --agent gemini # Windsurf npx -y skills add every-app/open-seo --skill simple-issue-description --agent windsurf # Cline npx -y skills add every-app/open-seo --skill simple-issue-description --agent cline ``` ## Qué hace - Convierte un reporte de bug tosco, una petición de feature, una nota de soporte o un PR en un issue corto y en lenguaje llano, centrado en el problema y el comportamiento deseado. - Identifica el problema concreto, describe el comportamiento deseado sin prescribir implementación y deja solo el contexto que ayuda a entender o reproducir. - Un issue por problema: si la fuente junta varios, redacta el del más importante y dice que los demás se separen en issues y PRs distintos. - No inventa impacto en el usuario ni pasos de reproducción; si la fuente solo muestra limpieza o refactor, dice que no hay problema claro en vez de fabricar uno. - Si la fuente arregla una vulnerabilidad no pública, no redacta un issue público: sugiere reportarla en privado al maintainer. ## Cuándo usarla - Se pide simplificar un issue, explicar para qué sirve un PR, crear el issue correspondiente a un PR o quitar el detalle de implementación de un reporte. - Se invoca `/simple-issue-description`. ## Qué la activa - "Simplifica este issue para que un maintainer lo entienda en un minuto" - "Crea el issue que corresponde a este PR" - "Quita el detalle de código de este reporte de bug" ## Archivos - SKILL.md — 5 KB - agents/openai.yaml — 262 B ## SKILL.md Reproducido tal cual desde every-app/open-seo bajo MIT. Esta sección es el documento original y está en inglés. # Simple Issue Description Write an issue a maintainer can understand in under a minute. Focus on what someone experiences and what should happen instead. ## Workflow 1. Read the supplied notes, conversation, issue, PR description, or diff. In a PR, also check for spec, design doc, or README changes — they often state the intent better than the description does. 2. Identify the concrete problem. State who or what is affected when the source makes that clear. 3. Describe the desired behavior without prescribing an implementation. 4. Keep only context that helps someone understand or reproduce the problem. 5. If the source is a PR or diff, describe the problem the change tries to solve, not the files or code it changes. 6. Draft the issue immediately unless the problem and desired behavior cannot be determined. In that case, ask one short clarifying question. One issue per problem. If the source bundles unrelated problems, draft the issue for the most significant one, list the others in a line each, and tell the contributor to split them into separate issues and separate pull requests. If the source adds a capability instead of fixing a misbehavior, do not stage the absence as a bug. Describe what a user cannot do today and the full user experience of the feature: who uses it, from where, and what they see. Do not invent user impact, reproduction steps, or certainty that the source does not support. If the source only shows cleanup, refactoring, or a possible code smell, say that no concrete problem is clear instead of manufacturing an issue — this rule wins over step 6. Reply with two or three sentences: what the source shows, and what evidence would make it issue-worthy. If the source fixes a security weakness that is not already public, do not draft a public issue describing it. Suggest reporting it privately to the maintainer instead. ## Writing rules - Use plain language and short sentences. - Keep the issue under 200 words unless it is clear that more is necessary to describe the reproduction steps or a large feature. - Lead with behavior, not code, architecture, or the proposed fix. A one-sentence plain-language cause is fine when the symptom cannot be understood without it. - Keep technical details only when they are necessary to reproduce or understand the problem. Limits and defaults that make the symptom make sense (batch sizes, quotas, caps) count as necessary. - Preserve useful evidence such as error messages, screenshots, links, and documentation references. - Do not mention that AI wrote or reviewed the issue. - Avoid filler, praise, roadmap language, and exhaustive edge cases. - Use the contributor's level of certainty. Do not present a guess as a confirmed bug; write "can" or "appears to" when the source describes a risk rather than an observed failure. ## Output format The first line is the issue title — when filing on GitHub, put it in the title field instead of repeating it in the body. For a missing capability, title the outcome ("Flag pages with no structured data") rather than a fake bug ("Audits never mention structured data"). Omit the **Extra context** section when there is nothing useful to add. Constraints and scope notes belong there, including what is not affected when a maintainer would reasonably worry that it is. ```markdown # ## TL;DR ## What is happening? ## What should happen? ## Extra context ``` ## Example ```markdown # The chat jumps away from messages I am reading ## TL;DR When I scroll up to read an older message, a new response moves me back to the bottom of the chat. The chat should stay where I left it until I choose to return to the latest message. ## What is happening? New responses automatically scroll the chat to the bottom, even when I am reading earlier messages. ## What should happen? Keep my current scroll position and show that a new message is available. ``` ## Dónde encaja - Categoría: [Herramientas para desarrolladores](https://skillsagentes.com/categorias/herramientas-desarrollo.md) — Skills que cambian cómo tu agente escribe, revisa y despliega código. - Creador: [every-app](https://skillsagentes.com/creators/every-app.md) — 19 skills en el directorio - [Todas las skills](https://skillsagentes.com/skills.md) - [Ranking de instalaciones](https://skillsagentes.com/ranking.md) ## Otras skills del mismo repositorio - [Seo Coach](https://skillsagentes.com/skills/every-app/open-seo/seo-coach.md): Entra en un modo de coach de OpenSEO cercano que explica los flujos, recomienda los siguientes pasos y ayuda a usar bien agentes, búsqueda web, scraping y datos MCP. - [Seo Audit](https://skillsagentes.com/skills/every-app/open-seo/seo-audit.md): Audita un sitio y entrega un informe SEO de una página, en lenguaje llano, que cualquiera puede accionar, centrado en una única acción para esta semana. - [Create Repo Skill](https://skillsagentes.com/skills/every-app/open-seo/create-repo-skill.md): Crea o actualiza una skill en este repositorio de la forma correcta: hogar canónico en `.agents/skills`, marca interna o pública, symlinks en `.claude/skills` y registro en las docs públicas para las skills de producto. - [Seo Project Setup](https://skillsagentes.com/skills/every-app/open-seo/seo-project-setup.md): Rellena el contexto compartido de OpenSEO de un proyecto (alcance del sitio, objetivos, posicionamiento, competidores, páginas clave y preferencias), más comprobaciones de MCP y entrada de Search Console. - [Local Seo](https://skillsagentes.com/skills/every-app/open-seo/local-seo.md): Audita un Google Business Profile, lo compara con competidores locales y mapea la visibilidad en Google Maps alrededor de una ubicación para decidir qué arreglar primero. ## Skills relacionadas - [Papercuts](https://skillsagentes.com/skills/every-app/open-seo/papercuts.md): Registra en `.agents/PAPERCUTS.md` la fricción real y recurrente del repositorio (setup confuso, comandos inestables, errores engañosos, archivos generados obsoletos) y también revisa, deduplica y resuelve las entradas existentes. - [Maintain Greptile Rules](https://skillsagentes.com/skills/every-app/open-seo/maintain-greptile-rules.md): Evalúa hallazgos verificados de revisiones de merge-ready, Greptile, PR, CI, seguridad y facturación, y promueve los huecos de revisión duraderos a la configuración versionada de `.greptile`. - [Create Repo Skill](https://skillsagentes.com/skills/every-app/open-seo/create-repo-skill.md): Crea o actualiza una skill en este repositorio de la forma correcta: hogar canónico en `.agents/skills`, marca interna o pública, symlinks en `.claude/skills` y registro en las docs públicas para las skills de producto. - [Keyword Research](https://skillsagentes.com/skills/every-app/open-seo/keyword-research.md): Descubre oportunidades de palabras clave, evalúa métricas y SERPs y guarda o etiqueta los términos prometedores usando los datos MCP de OpenSEO. - [Openseo Release Notes](https://skillsagentes.com/skills/every-app/open-seo/openseo-release-notes.md): Corta una release de OpenSEO: sube la versión, redacta notas de versión para el usuario desde los commits del último tag, pasa una revisión con verificación por subagentes y abre un PR `release: vX.X.X`. --- Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)