feature
Skill0 starsChanged 42 days agoMITView on GitHub
Implement new functionality in an existing project: \"agrega X\", \"implementa el login\", \"add this feature\", a ticket. Thin vertical slice, test-first, runs the gate, updates notes.
We split this skill into the rules it gives an agent
1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.
0
Common
Most of the 63 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 70
Commit con mensaje que explique el porqué, no el qué del diff.
“Common” is measured: kept by at least 6 in 10 of the 63 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Feature — construir una rebanada, verificada, sin romper lo que ya anda
Overview
Construir bien no es escribir mucho código: es entregar la rebanada más delgada que ya sirve a un usuario, verificada, sin dejar el proyecto peor de lo que estaba. La IA puede generar 800 líneas en un minuto; el oficio está en decidir que solo 120 debían existir y que las 120 entran verdes.
Cuándo usar
- Funcionalidad nueva en un repo que ya existe.
- La siguiente rebanada de un proyecto en marcha.
- Un ticket, un pedido concreto de usuario, un "ahora también necesito que...".
Cuándo NO usar
| Situación | Ruta |
| Algo está roto | triage → fixer / ui-bug / agent-debug |
| Pedido vago o proyecto nuevo sin spec | intake |
| No hay restricciones ni gate en el repo | constitution primero (una vez, 15 min) |
| Solo mover/limpiar código sin cambiar comportamiento | refactor |
| El cambio implica decisión estructural grande | architecture primero |
Regla de hierro: contexto antes de código
LEER spec + constitution + state/gotchas ANTES DE ESCRIBIR. SI NO EXISTEN, CREARLOS O DECLARAR QUE NO EXISTEN.Orden de lectura, 5 minutos: AGENTS.md → docs/project/state.md (zonas rojas) → gotchas.md → el módulo que vas a tocar y sus tests. Escribir sin esto es repetir errores que el proyecto ya pagó.
Proceso
1. Acotar la rebanada
Una rebanada vertical atraviesa todas las capas y deja algo usable: datos → lógica → borde (API/UI/comando). Nada de "primero todas las tablas, después toda la lógica": eso solo se puede probar al final, que es cuando ya no hay tiempo.
Criterio de tamaño: si no cabe en un diff que una persona pueda revisar de una sentada (~400 líneas), pártela. Si necesitas partirla, la primera parte debe seguir sirviendo para algo.
2. Plan corto y explícito (antes de tocar archivos)
- Archivos que se van a crear/modificar y por qué.
- Qué criterios de aceptación cubre (AC-n del spec).
- Qué NO incluye esta rebanada.
- Riesgos: qué se puede romper de lo existente.
- Decisión abierta → pregúntala ahora con recomendación por defecto, no a mitad del código.
Si el plan revela una decisión estructural (nueva dependencia, nuevo servicio, cambio de esquema), pasa por architecture y registra un ADR.
3. Test primero sobre el comportamiento acordado
Escribe el test del AC, mírelo fallar, implementa lo mínimo, mírelo pasar. Para código de interfaz donde el test-first no rinde, invierte el orden pero no te saltes el test: la rebanada no está hecha sin él.
4. Implementar bajo la constitución
- Estilo, límites de tamaño y complejidad:
code-standard+ la tabla de la constitución. - Reusa lo que ya existe en el repo antes de crear paralelos: buscar primero (
grepdel concepto), crear después. La duplicación en proyectos asistidos por IA nace de no mirar si ya estaba. - Dependencia nueva solo con justificación escrita: qué problema resuelve, qué pesa, qué la mantiene viva, y qué pasa si mañana desaparece.
- Un cambio = un propósito. Si ves un bug al pasar, anótalo; no lo mezcles.
5. Gate y cierre
quality-gatecompleto. BLOQUEA = no está listo, sin importar cuánto funcione en tu prueba manual.- Prueba manual del camino real (una vez, la que el gate no puede replicar: cómo se siente).
- Actualiza
docs/project/state.md(qué entró, qué quedó pendiente) ygotchas.mdsi descubriste una trampa. - Commit con mensaje que explique el porqué, no el qué del diff.
Stop-loss
| Señal | Acción |
| 3 intentos y el mismo test sigue rojo | Para. El problema es el diseño o el entendimiento, no el código. Vuelve al plan. |
| El diff creció más de 2x lo planeado | Para y parte la rebanada. |
| Hay que "tocar todo" para agregar algo chico | Es acoplamiento: tech-debt / refactor antes de seguir. |
| Aparece una decisión de negocio no prevista | Pregunta. No la decidas tú en silencio. |
Anti-racionalización
| Excusa | Realidad |
| "Ya que estoy, agrego también esto otro" | Alcance no acordado = trabajo no pagado y riesgo no evaluado. Anótalo como propuesta. |
| "Lo hago genérico por si mañana..." | YAGNI. Lo genérico sin segundo caso real es complejidad hoy por un beneficio imaginario. Espera al tercer caso. |
| "Copio este bloque y lo adapto" | Tercera copia = extracción obligatoria. Primera y segunda, aceptables si son de verdad distintas. |
| "Los tests los agrego al final de la feature" | Al final la forma del código ya impide probarlo. El test guía el diseño. |
| "Funciona en mi prueba, listo" | El gate decide. Tu prueba manual cubre un camino de muchos. |
| "No leo las notas, exploro el código" | El código dice qué hace. Las notas dicen por qué, y qué ya explotó antes. |
Formato de salida
- Rebanada entregada: qué hace ahora el usuario que antes no podía.
- AC cubiertos y sus tests.
- Archivos tocados (ruta:línea de lo importante).
- Salida real del gate.
- Fuera de alcance / pendiente, y decisiones abiertas si quedaron.
- Notas del proyecto actualizadas.
Other versions69 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 69
- crbnos/carbon★ 2.8ksame name
- aaronjmars/aeon★ 787same name
- aeonfun/aeon★ 785same name
- astashov/liftosaur★ 768same name
- me2resh/apexyard★ 542same name
- yicheng47/runner★ 436same name
- bradtraversy/coding-with-ai-course-resources★ 344same name
- garagon/nanostack★ 206same name
- DeL-TaiseiOzaki/claude-code-orchestra★ 199same name
- vide/matedroid★ 82same name
59 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use bug, bugfix and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
mimocccSkillbug
Use whenever an incident entry is written on the owner's order (see ai-incident-report) — the same entry must ALSO become a /bug draft (SendFeedback) for Anthropic and an e-mail to ai-sabotages@psippr.org (scripts/mail-incident.sh <N>). Owner 19. 9. 2026: "nahlasene incidenty vytvori /bug a email na ai-sabotages@psippr.org". Also invocable as /bug <N> to (re)send an existing bug report.
Also in 6 projects that use this
team-attentionSkillbugfix
Root cause based one-shot bug fix. debugger diagnosis → requirements.md generation → /execute. /bugfix "error description" Full investigation pipeline: debugger + gap-analyzer + standard verify. QA suggestion after successful fix.
Also in 7 projects that use this
codebycoreySkilladopt
Adopt an existing plan from conversation context into delta-spec format. Use when importing a plan, adopting planning that already happened, capturing plan mode output, or bringing in prior design work.
Also in 4 projects that use this
Google CloudSkillfix
Plan a remediation strategy after a test failure.
Also in 10 projects that use this
marylinSkillrecover
Recover work from a crashed or interrupted session. Use when Claude crashed mid-task, after an unexpected exit, when you see 'stale sessions detected', or when you lost context and need to figure out what was happening.
Also in 3 projects that use this
AWSSkillmap
Map verified service capabilities against customer-provided control framework and threat model. Produces mapping-results.json, controls-catalog.md, and framework-mapping.md. Supports pluggable frameworks: CCMv4, NIST 800-53, CIS Benchmarks, ISO 27001, etc. Split into 4 focused sub-skills for better accuracy; this skill orchestrates them.
Also in 4 projects that use this
In this repository37 other files it gives its agents.
- skills/constitution/templates/AGENTS.mdAGENTS.md
- agent-debugSkill
- agentic-codingSkill
- ai-securitySkill
- api-backendSkill
- app-securitySkill
- architectureSkill
- automationSkill
- batchSkill
- bot-devSkill
- changelog-generatorSkill
- code-standardSkill
- constitutionSkill
- consultaSkill
- data-layerSkill
- deploySkill
- desktop-appSkill
- dev-routerSkill
- diff-reviewSkill
- env-doctorSkill
- fixerSkill
- intakeSkill
- mobile-appSkill
- observabilitySkill
- performanceSkill
- project-memorySkill
- quality-gateSkill
- readme-generatorSkill
- rebuildSkill
- refactorSkill
- tech-debtSkill
- test-strategySkill
- triageSkill
- ui-bugSkill
- ui-designSkill
- valida-ideaSkill
- web-appSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.