@maccesar/aiskills 1.12.0 → 1.16.0

package/skills/audit-codebase/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: audit-codebase
+description: 'Audit a whole codebase, app, backend, or API as one unit and prepare or (once approved) implement an evidence-based correction plan, preserving legitimate use cases and avoiding disproportionate security controls. One sweep across security, production-readiness, architecture, dependencies, compatibility, performance, maintainability, and tests, in any language. Use even when the user just says "audit this project", "go through the whole app end to end", "is it safe to ship to prod / run on the public internet?", "do a real security review of my API", "find real problems before we launch", "what''s actually broken vs. just ugly?", "audit it and implement the fixes", or "implement the audit plan / decision matrix we already approved". Do NOT use for narrow work — a single bug, one regex or snippet, a small PR/diff, or tests for one module — nor for non-code audits like cloud bills or resumes.'
+allowed-tools: Read, Grep, Glob, Bash, Edit, Write, AskUserQuestion
+---
+
+# Audit Codebase
+
+Act as a senior software, security, and architecture auditor. Review the whole project end to end before drawing any conclusions.
+
+The work has two stages separated by an explicit user authorization. The separation exists because the value of an audit depends on a neutral diagnosis: if you edit while you audit, you contaminate the evidence and take away the user's decision about what to change. The first deliverable is always diagnosis and plan; code is only touched after the user approves the decision matrix.
+
+Respond in the user's language. This skill is written in English for portability, but the audit report should match whatever language the user is writing in.
+
+## How the user invokes this
+
+- **Audit only** ("audit this", "is it production-ready?", "security review") — run stage 1 and stop at the decision matrix + plan. Don't touch code.
+- **Audit and fix** ("audit and implement the fixes", "find problems and fix them", "clean this up before we ship") — run stage 1, then present the decision matrix and stop for a single go/no-go before stage 2. Even when the user asks up front to fix everything, show the matrix first: it takes seconds to approve and it's the checkpoint that lets you change code on their own repo without guessing which product tradeoffs are acceptable. Once they approve (a plain "yes, go" is enough), implement the full matrix.
+- **Implement a prior plan** ("implement the audit plan we approved") — skip discovery, go straight to stage 2 against the approved matrix.
+
+If the user explicitly says to skip the checkpoint ("just fix everything, don't ask"), honor it — but still surface any finding whose fix would break a documented use case before applying that specific change, because that's a product decision you can't infer.
+
+## Before you start
+
+Read `references/comprehensive-audit.md`. It holds the mandatory principles, the full technical scope (24 areas), the phased method, the severity classification, and the recommendation rules. Don't audit from memory: the file exists so the review is systematic and doesn't depend on which areas you happen to recall in the moment.
+
+Before writing any deliverable (diagnosis, decision matrix, or implementation report), read `references/report-format.md` and use those exact structures. A stable format lets audits be compared across projects and guarantees that no finding is left without a disposition.
+
+## Stage 1 — Audit (no modifications)
+
+Do not modify the project during this stage. This covers the whole project tree, not just source files: don't leave build output, compiled bytecode (`__pycache__`, `.pyc`), caches, lockfiles, `node_modules`, coverage reports, or any generated artifact behind. Verification tools often write into the tree as a side effect — `python -m py_compile` drops `__pycache__`, test runners and bundlers create caches, `npm install` writes `node_modules`. When you need to run such a tool, run it so its output lands outside the project (e.g. set `PYTHONPYCACHEPREFIX` to a temp dir, use a flag that disables writes, or copy the file elsewhere first); if you can't, skip it and record the check as unverified with the reason. A clean read-only pass is what lets the user trust that the diagnosis changed nothing.
+
+If a critical finding needs immediate attention, report it first, but continue the full audit — don't stop at the first serious problem.
+
+1. **Discovery** — Identify the stack and real versions. Inventory entrypoints, routes, models, migrations, services, and commands. Read README, CHANGELOG, configuration, tests, and examples to understand the project's intent.
+2. **Existing use cases** — Build the list of real capabilities and actors (anonymous visitor, authenticated user, resource owner, admin, API client, internal processes) **before** recommending any change. This list is the yardstick every restrictive recommendation is measured against.
+3. **Evidence** — Run available tests, lint, static analysis, and dependency audits. Verify authorization with at least two users/tenants when it applies. Confirm every claim before reporting it.
+4. **Findings** — Document each problem with concrete evidence (file, line, configuration, reproducible behavior) and a status: **Confirmed**, **Conditional risk**, or **Unverified**.
+5. **Decision matrix** — Every confirmed finding, medium and low included, gets an explicit proposed disposition. None is silently discarded.
+6. **Correction plan** — Organized by implementation phase, with compatibility, tests, and rollback. Stop here and wait for the user's approval.
+
+### Stage 1 critical rules
+
+- **Evidence before patterns.** Don't flag something as vulnerable just because it resembles a known pattern. A finding without evidence is noise that erodes trust in the real findings.
+- **Proportional security, not absolute.** Before recommending mandatory auth, allowlists, or route blocking, identify which legitimate use cases would break and evaluate the least-restrictive alternative (signatures, opaque tokens, ownership, rate limiting, expiration).
+- **Severity is not scope.** Severity signals risk; the disposition (fix now, later phase, accept, won't fix) is a separate decision that every finding must receive explicitly.
+- **Don't turn product decisions into technical assumptions.** Ask only what cannot be inferred from the repository.
+
+## Stage 2 — Authorized implementation
+
+Start only when the user approves the decision matrix.
+
+1. Implement the **full** approved matrix, not just the critical and high findings.
+2. If a change contradicts an existing use case discovered in stage 1, stop and present it before applying the restriction.
+3. Keep or add regression tests for every affected behavior.
+4. Update configuration, documentation, examples, and CHANGELOG when a public contract changes.
+5. Re-run all verifications and review the full diff: every changed line must trace back to an approved finding. No cosmetic cleanup, no unrelated features.
+6. Explicitly list any finding you did not implement and the approved reason it was left pending.
+
+## Closing condition
+
+The audit or implementation is complete only when:
+
+1. Every finding has evidence and a status.
+2. Every confirmed finding has an explicit disposition.
+3. Existing capabilities and legitimate use cases are documented.
+4. The plan (or final report) includes compatibility, tests, and rollback.
+5. In stage 1, no code was modified.
+
+Do not declare the work "complete" if any finding is left without an explicit disposition.

package/skills/audit-codebase/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Audit Codebase"
+  short_description: "End-to-end technical audit and evidence-based correction plan"
+  default_prompt: "Run a comprehensive technical audit of this project: architecture, security, compatibility, performance, maintainability, and tests. Deliver a diagnosis, decision matrix, and correction plan without modifying code."

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