@maccesar/aiskills 1.11.0 → 1.15.0

package/skills/audit-codebase/references/comprehensive-audit.md

@@ -0,0 +1,220 @@
+# Comprehensive technical audit — full method
+
+Detailed guidance for stage 1 (audit) and the rules that govern both stages. The exact deliverable formats live in `report-format.md`.
+
+## Objective
+
+Detect real, verifiable problems in:
+
+1. Implementation and functional logic.
+2. Architecture and separation of responsibilities.
+3. Security, authentication, and authorization.
+4. Input validation and trust boundaries.
+5. Database, integrity, and performance.
+6. Files, uploads, paths, and storage.
+7. Error handling, logs, and sensitive data.
+8. Dependencies, configuration, and deployment.
+9. Frontend, mobile client, or external integrations.
+10. Tests, compatibility, and maintainability.
+
+The result must let the user decide what to fix, what to keep, what to consciously postpone, and how to implement the changes without breaking valid use cases.
+
+## Mandatory principles
+
+### 1. Evidence before patterns
+
+- Don't invent problems.
+- Don't flag something as vulnerable just because it resembles a known pattern.
+- Every finding must include concrete evidence: file, line, configuration, dependency, reproducible behavior, or tool output.
+- If it can't be verified, mark it **Unverified**.
+- Distinguish clearly between:
+  - **Confirmed**: demonstrated in code or execution.
+  - **Conditional risk**: depends on specific configuration or infrastructure.
+  - **Unverified**: not enough data to conclude.
+
+### 2. Proportional security, not absolute security
+
+- "Secure by default" does not mean "forbid by default" without analyzing the product.
+- Before recommending authentication, strict authorization, allowlists, tokens, route blocking, or removing compatibility, identify the current use cases that could break.
+- Explicitly consider public, anonymous, multi-user, admin, API, temporary, and embedded flows when they exist in the project or its documentation.
+- Don't impose registration/login if the product legitimately supports anonymous visitors.
+- Prefer controls at the real boundary: signatures, opaque tokens, anonymous sessions, rate limiting, ownership, expiration, scopes, and context validation.
+- Don't duplicate controls without justifying the benefit. If a signature already guarantees integrity, don't also add a mandatory manual record unless it mitigates a distinct, demonstrated risk.
+- Every restrictive recommendation must include:
+  1. The concrete risk it mitigates.
+  2. The affected use cases.
+  3. The least-restrictive alternative evaluated.
+  4. A safe opt-in/opt-out mechanism, if applicable.
+  5. The migration and compatibility impact.
+
+### 3. Compatibility and existing behavior
+
+- Review README, CHANGELOG, configuration, tests, examples, and recent history to identify public contracts and intentional behaviors.
+- Build a list of existing capabilities before recommending changes.
+- Don't silently remove or change a documented capability.
+- Classify each change as:
+  - Compatible.
+  - Justified breaking change.
+  - Avoidable breaking change.
+- If a fix could break consumers, include a transition strategy, configuration, deprecation, or migration guide.
+- Verify the real support matrix of the language, framework, database, and runtime versions.
+
+### 4. Severity is not scope
+
+- Severity indicates risk; it does not automatically decide whether something is implemented or ignored.
+- Every confirmed finding — mediums and lows included — must receive an explicit disposition:
+  - **Fix now**.
+  - **Fix in a later phase**, with a reason and a follow-up condition.
+  - **Consciously accept**, with technical justification.
+  - **Won't fix**, because it isn't a real problem or the cost/risk outweighs the benefit.
+- Don't use "optional", "tech debt", or "medium improvement" as a synonym for "won't be done".
+- If the user asks to implement the full plan, include every finding whose fix is appropriate and proportionate, not just criticals and highs.
+- Refactors are evaluated by benefit, risk, and available coverage; they are neither done automatically nor discarded automatically.
+
+### 5. Minimal, complete, verifiable changes
+
+- Prioritize small, safe changes, but don't leave a functional fix half done.
+- Don't propose full rewrites without a demonstrated need.
+- Don't add features unrelated to the problems found.
+- Don't introduce abstractions without a concrete problem they solve.
+- Don't do cosmetic cleanup during the fix phase unless it's needed to implement or verify the change.
+- Every recommendation must state how to check that it works and that it caused no regressions.
+
+## Technical scope
+
+Review at minimum:
+
+1. General architecture and folder structure.
+2. Separation of responsibilities and coupling.
+3. Modern framework conventions.
+4. Main configuration and default values.
+5. Direct, transitive, outdated, or vulnerable dependencies.
+6. Public, private, web, API, and callback routes.
+7. Authentication, sessions, tokens, and expiration.
+8. Authorization, ownership, roles, policies, gates, and isolation between users.
+9. Input validation, coercion, limits, and error messages.
+10. Models, mass assignment, casts, relations, and events.
+11. Migrations, indexes, cascades, constraints, and referential integrity.
+12. Queries, N+1, transactions, concurrency, and partial operations.
+13. Controllers, services, jobs, commands, and middleware.
+14. Uploads, MIME, extensions, names, paths, disks, permissions, and cleanup.
+15. Image/document processing and CPU/memory consumption.
+16. Sensitive data in responses, logs, exceptions, and caches.
+17. CSRF, CORS, rate limiting, headers, and signed URLs.
+18. Frontend, CDN dependencies, CSP, integrity, and client-side error handling.
+19. Build scripts, published assets, and install/update commands.
+20. Production configuration and behavior behind proxies/CDNs.
+21. Existing tests, practical coverage, and compatibility matrix.
+22. Outdated documentation, examples, and public contracts.
+23. Duplicated code, dead code, and accidental complexity.
+24. Deployment, upgrade, and rollback risks.
+
+Adapt the list to the real stack: a CLI has no CSRF, a library has no routes. Explicitly mark the areas that don't apply instead of silently omitting them, so the reader knows they were considered.
+
+## Working method
+
+### Phase 1: discovery
+
+1. Identify the stack and real versions.
+2. Review the repository instructions and Git state.
+3. Inventory entrypoints, routes, models, migrations, services, views, and commands.
+4. Read configuration, README, CHANGELOG, and examples to understand intent and compatibility.
+5. Identify real actors and flows:
+   - Anonymous visitor.
+   - Authenticated user.
+   - Resource owner.
+   - Administrator.
+   - API client or external service.
+   - Internal processes and CLI.
+6. Trace the critical flows end to end.
+
+### Phase 2: verification
+
+1. Run available tests, lint, static analysis, and audits.
+2. Use dependency tools to verify real advisories.
+3. Reproduce important bugs when it's safe.
+4. Verify authorization with at least two users/tenants when it applies.
+5. Verify positive and negative paths.
+6. Review concurrency, rollback, and cleanup in operations that touch DB + filesystem.
+7. Check every claim against evidence before reporting it.
+
+### Phase 3: diagnosis, no modifications
+
+- The first deliverable is diagnosis and plan only.
+- Don't modify the project tree during this phase — not just source files, but any generated artifact (compiled bytecode/`__pycache__`, caches, `node_modules`, lockfiles, coverage output). Verification tools that write into the tree as a side effect (`py_compile`, test runners, bundlers, `npm install`) must be run with their output redirected outside the project, or skipped and recorded as unverified with the reason.
+- If a critical finding needs immediate attention, report it first, but continue the full audit.
+- Don't stop the analysis after finding critical problems.
+
+### Phase 4: decide before implementing
+
+Before modifying code, present a **decision matrix** with all confirmed findings (format in `report-format.md`).
+
+Don't start changes until the decisions are clear for anything that alters public behavior, authentication, compatibility, schema, dependencies, or API.
+
+Ask only about product decisions that can't be inferred from the repository. Don't ask for data that can be investigated locally.
+
+### Phase 5: authorized implementation
+
+When the user authorizes implementation:
+
+1. Implement the full approved matrix, not just the highest-severity findings.
+2. If a contradiction with an existing use case appears, stop and present it before applying a restriction.
+3. Keep or add regression tests for every affected behavior.
+4. Update configuration, documentation, examples, and CHANGELOG when a contract changes.
+5. Run all verifications again.
+6. Review the full diff and confirm there are no out-of-scope changes.
+7. Explicitly list any finding not implemented and the approved reason for leaving it pending.
+
+## Severity classification
+
+### Critical
+
+- Provable unauthorized access, modification, or deletion.
+- Direct exposure of secrets or highly sensitive data.
+- Code execution, server or database compromise.
+- Data loss or breakage of an essential flow.
+
+### High
+
+- Serious permissions, validation, integrity, or logic problem.
+- Can cause partial data loss, inconsistencies, or major failures.
+- Vulnerable dependency exploitable in the project's real context.
+- Must be resolved before production unless explicitly and justifiably accepted.
+
+### Medium
+
+- Real performance, maintainability, compatibility, or incomplete-validation problem.
+- Faulty build, migration, cache, or operational process with a workaround available.
+- Must receive an explicit decision and is normally included in stabilization.
+
+### Low
+
+- Confirmed minor inconsistency or defect.
+- Its fix is small or can be grouped with related work.
+- Must not be ignored automatically; weigh cost against benefit.
+
+### Informational
+
+- Verified correct behavior.
+- Unconfirmed risk or preventive recommendation with no current defect.
+- Requires no change unless a conscious decision is made.
+
+## Rules for recommendations
+
+- Be actionable and specific.
+- Include the file and the suggested change when possible.
+- Recommend one concrete option, but explain the real tradeoffs.
+- Don't present a restrictive policy as the only solution if a safer, more flexible alternative exists.
+- Don't turn product decisions into technical assumptions.
+- Don't recommend allowlists, mandatory authentication, or endpoint removal without demonstrating why signatures, scopes, tokens, ownership, or rate limiting aren't enough.
+- If a fix is breaking, include migration and compatibility.
+- If you decide not to fix something, justify why and what future signal would force a reconsideration.
+
+## Communication rules
+
+- Be direct, no filler.
+- Don't explain basic framework concepts.
+- Don't list irrelevant theoretical possibilities.
+- Separate facts, inferences, and decisions.
+- Acknowledge uncertainty and contradictions.
+- Don't declare the audit or implementation "complete" if any findings lack an explicit disposition.

package/skills/audit-codebase/references/report-format.md

@@ -0,0 +1,119 @@
+# Deliverable formats
+
+Exact structures for the deliverables of both stages. Always use these templates: a stable format lets audits be compared across projects and guarantees that no finding is left without a disposition.
+
+## Stage 1 deliverable: diagnosis
+
+### 1. Executive summary
+
+- Overall state.
+- Overall risk: Low / Medium / High / Critical.
+- Top five priorities.
+- Existing capabilities that must be preserved.
+- What is well implemented.
+- What blocks production.
+- What could not be verified.
+
+### 2. Findings table
+
+Each finding includes:
+
+- ID (stable, e.g. `F-01`; the matrix and plan reference it).
+- Status: Confirmed / Conditional risk / Unverified.
+- Severity: Critical / High / Medium / Low / Informational.
+- Area (security, DB, files, performance, etc.).
+- File and line.
+- Problem.
+- Evidence.
+- Real impact.
+- Affected actors and use cases.
+- Concrete recommendation.
+- Least-restrictive alternative evaluated.
+- Compatibility and regression risk.
+- Acceptance test.
+- Proposed disposition.
+
+With few findings, a wide table works; with many, use a summary table (ID, severity, area, problem, disposition) followed by one card per finding with the remaining fields.
+
+### 3. Special sections
+
+Include separate sections for:
+
+- Security.
+- Database.
+- Files and storage.
+- Performance.
+- Code quality.
+- Frontend/build/assets.
+- Dependencies and compatibility.
+- Tests.
+- Production and deployment.
+
+If an area doesn't apply to the stack (e.g. database in a pure library), state it in one line instead of omitting the section.
+
+### 4. Decision matrix
+
+Include **all** confirmed findings, regardless of severity. None may be implicitly discarded.
+
+| ID  | Finding | Severity | Proposed disposition | Compatibility | Affected cases | Justification |
+| --- | ------- | -------- | -------------------- | ------------- | -------------- | ------------- |
+
+Valid dispositions:
+
+- **Fix now**.
+- **Fix in a later phase** — with a reason and a follow-up condition.
+- **Consciously accept** — with technical justification.
+- **Won't fix** — because it isn't a real problem or the cost/risk outweighs the benefit.
+
+Compatibility column: Compatible / Justified breaking / Avoidable breaking.
+
+### 5. Recommended correction plan
+
+Organize by implementation phase, not just by severity:
+
+1. Immediate protection without breaking legitimate capabilities.
+2. Integrity and functional errors.
+3. Compatibility, migrations, and dependencies.
+4. Performance, caching, and operations.
+5. Maintainability and justified refactors.
+6. Tests, documentation, rollout, and rollback.
+
+For each phase state:
+
+- Exact changes.
+- Files or subsystems.
+- Dependencies between changes.
+- Risks and mitigations.
+- Use cases that must keep working.
+- Required tests.
+- Acceptance criteria.
+
+Close the diagnosis by stating that no code was modified and that you await the user's decision on the matrix.
+
+## Stage 2 deliverable: implementation report
+
+When the authorized implementation is done, deliver:
+
+### 1. Change summary
+
+- Implemented findings (by ID), with the files touched by each.
+- Final compatibility classification of each change (Compatible / Justified breaking) and, for breaking ones, the migration strategy applied.
+
+### 2. Verification
+
+- Verification commands run (tests, lint, static analysis) and their literal output.
+- Regression tests added or updated, mapped to the finding they cover.
+- Confirmation of the full-diff review: every changed line traces back to an approved finding.
+
+### 3. Pending items
+
+Table of matrix findings that were not implemented:
+
+| ID  | Finding | Approved disposition | Reason left pending | Follow-up condition |
+| --- | ------- | -------------------- | ------------------- | ------------------- |
+
+If empty, say so explicitly ("the approved matrix was implemented in full").
+
+### 4. Updated documentation
+
+- List of documents touched (README, CHANGELOG, examples, configuration) and which contract changed each one.

package/skills/humaniza/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: humaniza
-description: Humaniza textos en español (especialmente es-MX) eliminando patrones típicos de IA y devolviendo una versión natural y clara. Úsalo al editar emails, documentación,  marketing, soporte o textos técnicos en español cuando el usuario pida "humanizar", "hacerlo más natural", "quitar tono IA" o "hacerlo sonar humano".
-allowed-tools: Read, Write, Edit, Grep, Glob, AskUserQuestion
+description: 'Úsalo cuando humanices textos en español (especialmente es-MX) — editando emails, documentación, marketing, soporte o textos técnicos, eliminando patrones típicos de IA y devolviendo una versión natural y clara. Triggers: "humanizar", "hacerlo más natural", "quitar tono IA", "hacerlo sonar humano".'
+allowed-tools: Read, Write, Edit, Grep, Glob, Bash, AskUserQuestion
 ---
 
 # Humaniza
@@ -16,15 +16,66 @@ Editor de estilo para español de México. El objetivo es quitar tics de IA sin
 - Preferir es-MX: evitar "vosotros", "ordenador", "móvil", "coche" cuando el texto sea neutro.
 - No inventar fuentes ni datos.
 
+## Reglas clave (adaptadas de Stop Slop)
+
+1. **Corta los abridores.** Elimina frases que anuncian lo que sigue. "La verdad es que", "Déjame ser claro", "Aquí está la cosa". Di el contenido directo.
+
+2. **Rompe estructuras formulaicas.** Evita contrastes binarios ("No porque X, sino porque Y"), listados negativos ("No es X, no es Y, es Z"), fragmentación dramática ("[Sustantivo]. Eso es todo."), setups retóricos ("¿Qué tal si...?"), agencia falsa ("la decisión emerge").
+
+3. **Usa voz activa.** Cada oración necesita un sujeto humano haciendo algo. No le hables a objetos inanimados como si actuaran solos. Los datos no "dicen" nada; alguien los lee.
+
+4. **Sé concreto.** Sin vaguedades. "Las implicaciones son significativas" → nombra la implicación específica. "Las razones son estructurales" → di cuál es la razón.
+
+5. **Pon al lector en la escena.** "Tú" gana a "la gente". Lo específico gana a lo abstracto. Sin narrador desde la distancia ("La gente tiende a...", "Esto pasa porque...").
+
+6. **Varía el ritmo.** Mezcla largos y cortos. Dos elementos ganan a tres. No termines todos los párrafos igual. Elimina las rayas (—) en prosa narrativa.
+
+7. **Confía en el lector.** Afirma los hechos directo. Sin suavizar, justificar, ni dar permiso ("y eso está bien").
+
+8. **Corta lo citable.** Si suena a frase de caja de motivación, reescríbela.
+
 ## Flujo
 
 1. Detectar tono y audiencia a partir del texto.
 2. Si el usuario pide un modo (marketing, técnico, soporte, etc.), priorizarlo.
-3. Identificar tics de IA con `references/ai-patterns-es.md` y `references/lexicon-es-mx.md`.
+3. Identificar tics de IA con `references/ai-patterns-es.md`, `references/lexicon-es-mx.md`, y `references/structures-es.md`.
 4. Reescribir: cortar relleno, concretar, variar ritmo, usar "ser/estar" cuando sea más claro.
 5. Ajustar el tono según `references/modes-es-mx.md` si aplica.
 6. Añadir voz humana cuando aplique con `references/voice-es-mx.md`.
-7. Pasar QA final con `references/checklist.md`.
+7. Verificar el resultado con el escáner determinístico — ver "Verificación con script" abajo — y después pasar el QA visual con `references/checklist.md`.
+
+## Verificación rápida (antes de entregar)
+
+- ¿Hay adverbios -mente? Redúcelos o elimínalos.
+- ¿Voz pasiva sin sujeto visible? Encuentra al actor, ponlo de sujeto.
+- ¿Objeto inanimado haciendo algo humano ("la decisión emerge")? Nombra a la persona.
+- ¿Oración empieza con pronombre o adverbio interrogativo (qué, cuándo, dónde, cómo)? Reestructura.
+- ¿Abre con "he aquí", "la verdad es", "déjame"? Corta al punto.
+- ¿Tres oraciones consecutivas del mismo largo? Rompe una.
+- ¿Párrafo termina con frase corta de impacto? Varía.
+- ¿Raya (—) en prosa narrativa? Elimínala o usa coma.
+- ¿Declaración vaga ("las implicaciones son graves")? Nombra la implicación concreta.
+- ¿Comentario meta ("el resto de este artículo...")? Bórralo.
+- ¿Falso contraste ("no es X, es Y")? Afirma Y directo.
+- ¿Son a cita de LinkedIn? Reescribe sonando a humano.
+
+## Verificación con script
+
+Antes de entregar el texto, ejecuta el escáner para detectar tics que se hayan colado en la reescritura:
+
+```bash
+python <SKILL_DIR>/scripts/check_ai_patterns.py texto_editado.txt
+# o vía stdin:
+echo "$texto" | python <SKILL_DIR>/scripts/check_ai_patterns.py
+```
+
+Reemplaza `<SKILL_DIR>` por la "Base directory for this skill" que aparece en el system message al cargar el skill (la ruta cambia entre instalación plugin y standalone).
+
+El script lee `references/lexicon-es-mx.md` y reporta cada hit con línea, columna, categoría y sugerencia cuando existe. Para cada hit:
+
+- Si es un tic real → corrige el texto y vuelve a ejecutar el escáner
+- Si es una cita, marca o ejemplo legítimo → déjalo y anótalo en la entrega
+- El script NO sustituye al checklist visual — solo elimina la fase mecánica de búsqueda léxica
 
 ## Modos (si el usuario lo pide)
 

package/skills/humaniza/references/ai-patterns-es.md

@@ -49,3 +49,43 @@ Después: Finalmente lanzaremos la actualización.
 ## 12. Cierres vacíos
 Antes: En conclusión, este avance es clave para el futuro.
 Después: Este avance reduce el tiempo de carga.
+
+## 13. Abridores (throat-clearing)
+Antes: La verdad es que necesitamos mejorar el proceso.
+Después: Necesitamos mejorar el proceso.
+
+## 14. Muletas de énfasis
+Antes: Punto. Esto cambia todo. Que quede claro.
+Después: (elimínalas — el contenido se sostiene solo)
+
+## 15. Agencia falsa
+Antes: La plataforma permite a los equipos colaborar de forma eficiente.
+Después: Los equipos colaboran más rápido con esta plataforma.
+Antes: Los datos nos dicen que el usuario prefiere X.
+Después: Según los datos, el usuario prefiere X.
+Antes: La decisión emerge tras varias iteraciones.
+Después: El equipo decide tras iterar varias veces.
+
+## 16. Narrador desde la distancia
+Antes: La gente tiende a subestimar el tiempo de implementación.
+Después: Casi siempre subestimas el tiempo de implementación (o "los equipos subestiman...").
+
+## 17. Comentario meta (auto-referencial)
+Antes: El resto de este artículo explica las diferencias.
+Después: (elimínalo — deja que el artículo fluya solo)
+
+## 18. Vagos declarativos
+Antes: Las implicaciones de este cambio son profundas.
+Después: Este cambio reduce los costos en un 15%.
+Antes: Las razones son estructurales.
+Después: La razón principal es que el equipo no tiene acceso a los datos.
+
+## 19. Adverbiomanía (-mente)
+Antes: Realmente necesitamos reconsiderar el enfoque.
+Después: Necesitamos reconsiderar el enfoque.
+Antes: Es simplemente cuestión de prioridades.
+Después: Es cuestión de prioridades.
+
+## 20. Falsa intimidad / sinceridad manufacturada
+Antes: Te prometo que esto funciona.
+Después: Esto funciona.

package/skills/humaniza/references/checklist.md

@@ -3,7 +3,16 @@
 - El significado se mantuvo intacto.
 - No se inventaron datos ni fuentes.
 - Se redujeron muletillas y conectores repetidos.
+- No hay abridores ("la verdad es que", "déjame ser claro").
+- No hay muletas de énfasis ("punto", "que quede claro").
+- No hay contrastes binarios ("no porque X, sino porque Y").
+- No hay listado negativo ("no es X, no es Y, es Z").
+- No hay fragmentación dramática ("[sustantivo]. Eso es todo.").
+- No hay agencia falsa ("los datos nos dicen").
+- No hay adverbios -mente de relleno.
+- No hay voz pasiva sin sujeto visible.
 - El ritmo es natural y variado.
 - Se mantuvo el registro (tú/usted) y el tono.
 - La puntuación y los párrafos son claros.
 - El vocabulario es consistente con es-MX.
+- Si suena a cita de LinkedIn o frase de caja motivacional, reescribir.

package/skills/humaniza/references/examples.md

@@ -15,3 +15,19 @@ Después: Tu solicitud ya se procesó. En breve recibirás una actualización.
 ## Marketing
 Antes: Una experiencia única e inolvidable que transforma la manera en que trabajas.
 Después: Una experiencia pensada para que trabajes más rápido y con menos fricción.
+
+## Abridor + falso contraste
+Antes: La verdad es que no se trata de trabajar más horas, sino de trabajar mejor.
+Después: Trabaja mejor, no más horas.
+
+## Énfasis vacío + fragmentación
+Antes: Punto. Rapidez. Precisión. Confianza. Eso es lo que importa.
+Después: Lo que importa es la rapidez, la precisión y la confianza.
+
+## Agencia falsa
+Antes: La plataforma permite a los equipos comunicarse de forma fluida, eliminando la fricción y facilitando la colaboración.
+Después: Los equipos se comunican sin fricción, colaboran más rápido.
+
+## Abridor vago
+Antes: Las implicaciones de esta actualización son profundas y marcan un antes y un después en la plataforma.
+Después: Esta actualización reduce el tiempo de carga 40% y añade búsqueda por voz.

package/skills/humaniza/references/lexicon-es-mx.md

@@ -27,6 +27,24 @@ según expertos, diversos estudios, algunos analistas, observadores señalan, se
 - a nivel de -> en / respecto a (si no son niveles reales)
 - en términos de -> respecto a / sobre
 
+## Abridores (throat-clearing) — elimínalos, di el punto directo
+la verdad es que, déjame ser claro, voy a ser honesto, he aquí, la cosa es que, el problema es que, lo interesante es que, lo curioso es que, lo que quiero decir es, resulta que, el asunto es que, la realidad es que, el punto es que, lo importante es que, déjame explicarte, para ser honesto, honestamente hablando.
+
+## Muletas de énfasis — no añaden significado
+punto, punto final, que quede claro, esto importa porque, sin lugar a dudas, no te quepa duda, y eso es todo, esto cambia todo, hagamos una pausa para reflexionar, haz que eso cale.
+
+## Adverbios -mente inflados — se cuelan como relleno
+realmente, simplemente, literalmente, genuinamente, honestamente, profundamente, verdaderamente, fundamentalmente, inevitablemente, interesantemente, crucialmente, básicamente, esencialmente, prácticamente, claramente, obviamente, ciertamente, definitivamente, absolutamente, precisamente, notablemente, particularmente, especialmente, típicamente, actualmente (meaning "currently" — preferir "ahora", "hoy").
+
+## Comentario meta (auto-referenciales)
+el resto de este artículo, como veremos más adelante, en esta sección hablaremos de, quiero explorar, en las siguientes líneas, a continuación analizaremos, vale la pena mencionar que, es importante señalar que, cabe mencionar que.
+
+## Agencia falsa — verbos humanos a objetos
+los datos nos dicen, la plataforma permite, la herramienta facilita, el sistema detecta, la solución ofrece, el mercado recompensa, la cultura exige, la tecnología transforma, la decisión emerge, los resultados reflejan, la experiencia brinda.
+
+## Vagos declarativos — anuncian importancia sin nombrar qué
+las implicaciones son significativas, las razones son estructurales, el problema es profundo, las consecuencias son reales, lo que está en juego es alto, el impacto es considerable, el cambio es sustancial, las posibilidades son infinitas.
+
 ## Preferencias es-MX (si el texto es neutro)
 ordenador -> computadora
 móvil -> celular

package/skills/humaniza/references/structures-es.md

@@ -0,0 +1,132 @@
+# Estructuras a evitar
+
+Basado en el patrón detectado por Stop Slop, adaptado al español.
+
+## Contrastes binarios
+
+Crean falso drama. Afirma el punto directo.
+
+| Patrón | Problema |
+|--------|----------|
+| "No porque X, sino porque Y" / "No por X, sino por Y" | Giro telegrafiado |
+| "X no es el problema. Y lo es." | Reformulación formulaica |
+| "La respuesta no es X. Es Y." | Giro predecible |
+| "No se trata de X, sino de Y" | Mecánico |
+| "La pregunta no es X, sino Y" | Distracción retórica |
+| "No es X, es Y" | Contraste mecánico |
+| "No solo X, sino también Y" | Muletilla aditiva |
+| "deja de ser X y empieza a ser Y" | Falso arco de transformación |
+| "no significa X, sino Y" | Negación-seguida-de-afirmación |
+
+**En lugar de:** Afirma Y directo. "El problema es Y." "Aquí importa Y." Suelta la negación.
+
+## Listado negativo
+
+Enumerar lo que algo *no* es antes de decir lo que *sí* es. Striptease retórico.
+
+| Patrón | Problema |
+|--------|----------|
+| "No es X... No es Y... Es Z." | Acumulación dramática con negación |
+| "No fue X. No fue Y. Fue Z." | Misma estructura, pasado |
+
+**En lugar de:** Di Z. El lector no necesita la pista de aterrizaje.
+
+## Fragmentación dramática
+
+Fragmentos de oración para énfasis que leen a profundidad fabricada.
+
+| Patrón | Problema |
+|--------|----------|
+| "[Sustantivo]. Eso es todo." / "[Sustantivo]. Eso es." | Simplicidad performativa |
+| "X. Y. Y Z." | Drama staccato |
+| "Esto activa algo. [Palabra]." | Revelación artificial |
+
+**En lugar de:** Oraciones completas. Confía en el contenido, no en la presentación.
+
+## Setups retóricos
+
+Anuncian perspicacia en lugar de entregarla.
+
+| Patrón | Problema |
+|--------|----------|
+| "¿Qué tal si...?" / "¿Y si...?" | Postura socrática |
+| "He aquí lo que quiero decir:" / "Esto es lo que quiero decir:" | Vista previa redundante |
+| "Piénsalo." | Indicación condescendiente |
+| "Y eso está bien." / "Y no pasa nada." | Permiso innecesario |
+| "Imagina que..." | Falso gancho narrativo |
+
+**En lugar de:** Di el punto directo. Deja que el lector saque conclusiones.
+
+## Agencia falsa
+
+Darle a objetos inanimados verbos humanos. A la IA le encanta porque evita nombrar al actor.
+
+| Patrón | Problema |
+|--------|----------|
+| "la queja se convierte en solución" | La queja no hizo nada. Alguien la resolvió. |
+| "la decisión emerge" | Las decisiones no emergen. Alguien decide. |
+| "la cultura cambia" | Las culturas no cambian solas. La gente cambia su comportamiento. |
+| "la conversación avanza hacia" | Las conversaciones no avanzan solas. Alguien las dirige. |
+| "los datos nos dicen" | Los datos están ahí. Alguien los lee y saca conclusiones. |
+| "el mercado recompensa" | Los mercados no recompensan. Los compradores pagan por cosas. |
+| "la plataforma permite" | La plataforma no permite nada. Alguien la construyó para eso. |
+| "el sistema detecta" | El sistema no detecta nada. Alguien programó esa detección. |
+
+**En lugar de:** Nombra al humano. "El equipo lo resolvió esa semana" gana a "la queja se convierte en solución".
+
+## Narrador desde la distancia
+
+Flotando sobre la escena en vez de poner al lector en ella.
+
+| Patrón | Problema |
+|--------|----------|
+| "Nadie diseñó esto." | Observación incorpórea |
+| "Esto pasa porque..." | Voz de conferencista |
+| "Por eso es que..." | Misma voz distante |
+| "La gente tiende a..." | Sociólogo de sillón |
+| "Uno tiende a pensar que..." | Generalización impersonal |
+| "Se tiende a creer que..." | Distanciamiento innecesario |
+
+**En lugar de:** Pon al lector en la escena. "Tú no te sientas un día y decides..." gana a "Nadie diseñó esto".
+
+## Voz pasiva
+
+Cada oración necesita un sujeto haciendo algo. La voz pasiva esconde al actor.
+
+| Patrón | Solución |
+|--------|----------|
+| "fue creado por" | Nombra quién lo creó |
+| "se cree que" | Nombra quién lo cree |
+| "se tomaron decisiones" | Nombra quién decidió |
+| "se llegó a la conclusión" | Nombra quién concluyó |
+| "fue implementado" | Nombra quién implementó |
+| "ha sido reportado que" | Nombra quién reportó |
+
+**En lugar de:** Encuentra al actor. Ponlo al frente de la oración.
+
+## Inicios de oración a evitar
+
+| Patrón | Solución |
+|--------|----------|
+| Oraciones que empiezan con qué, cuándo, dónde, cómo, quién, por qué | Reestructura. Lidera con el sujeto o el verbo. |
+| Párrafos que empiezan con "entonces", "así que" | Empieza con contenido |
+| Oraciones que empiezan con "mira", "oye" | Elimínalas |
+
+Los interrogativos (qué, cómo, por qué) como abridores se vuelven muleta. "Lo que hace difícil esto es..." cambia a "La dificultad es..." o mejor, nombra la dificultad específica.
+
+## Patrones de ritmo
+
+| Patrón | Solución |
+|--------|----------|
+| Listas de tres elementos | Usa dos o uno |
+| Preguntas respondidas inmediatamente | Deja que las preguntas respiren o elimínalas |
+| Todo párrafo termina con golpe de efecto | Varía los finales |
+| Rayas (—) en prosa narrativa | Elimínalas. Usa comas o puntos. |
+| Fragmentación staccato | No apiles oraciones cortas sucesivas |
+| "No siempre. No perfectamente." | Muletilla disfrazada de seguridad |
+
+## Vaguedad con extremos
+
+| Patrón | Problema |
+|--------|----------|
+| Extremos vagos: todo, todos, siempre, nunca, nadie, absolutamente | Falsa autoridad. Usa datos específicos. |