repo-baselineSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

npx skills add PapiScholz/repo-baseline -g      # 1. instalar (una sola vez por máquina)

flowchart TD
U["Pedís: armá el baseline de este repo"] --> D["1 · Detectacheck_baseline.py + package.json,deploy, CI, README, git remote"]
D --> Q{"¿Falta algún dato queel repo no dice?"}
Q -->|sí| F["2 · Un solo formulariotitular · jurisdic

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: "repo-baseline"
description: "Deja repos, sitios o software nuevos con su documentación mínima adaptada al proyecto (README, ARCHITECTURE, ADRs, DESIGN, legales AR, SECURITY, LICENSE, .gitignore/.gitattributes) y verifica qué falta."
---

# repo-baseline

Objetivo: que todo repo nazca con un set mínimo de documentación **escrita para ese proyecto**. Un README que dice "TODO: describir el proyecto" no sirve para nada. Uno que dice qué es, cómo se corre y dónde se despliega le ahorra horas a quien llegue después, incluido vos dentro de seis meses.

## El baseline

| Archivo | Cuándo | Qué contiene |
|---|---|---|
| `README.md` | Siempre | Qué es, para quién, cómo correrlo, cómo desplegarlo y links a los demás docs |
| `<carpeta>/README.md` | Cuando la carpeta tiene reglas propias (migrations, infra, scripts, legal, etc.) | Las reglas de esa carpeta |
| `ARCHITECTURE.md` | Siempre | Componentes, flujo de datos, dónde vive cada cosa y decisiones con link a su ADR |
| `docs/adr/0000-template.md` | Siempre | Plantilla de ADR |
| `docs/adr/0001-<decision>.md` | Siempre | Primera decisión real (normalmente el stack) |
| `DESIGN.md` | Solo si el diseño UX/UI está definido | Formato google-labs-code/design.md. Si no está definido, anotar el pendiente en el README |
| `PRIVACY.md` | Si maneja datos personales | Según la jurisdicción |
| `TERMS.md` | Si hay usuarios finales o venta | Según la jurisdicción |
| Botón de arrepentimiento | Si vende online en Argentina | Requisito de UI, no solo de docs |
| `SECURITY.md` | Siempre | Cómo reportar, qué datos se manejan, secretos y su rotación |
| `LICENSE.md` | Siempre | Según el titular. Default: propietario, "All rights reserved" |
| `.gitignore` | Siempre | Del stack real detectado |
| `.gitattributes` | Siempre | `* text=auto eol=lf` más los binarios y excepciones CRLF |

Los esqueletos de cada documento están en el **Apéndice C**. Leelo antes de redactar.

## Flujo

### 1. Detectar antes de preguntar

Corré el check en modo JSON sobre la raíz del repo. El script está en el **Apéndice D**: escribilo en un archivo temporal **fuera del repo** (por ejemplo `check_baseline.py` en el directorio temporal del sistema), para no ensuciar el proyecto, y ejecutalo:

```bash
python <tmp>/check_baseline.py <repo> --json
```

Devuelve el stack detectado, los archivos del baseline presentes o faltantes, señales (pagos, auth, formularios, UI) y marcadores TODO-LEGAL existentes. Después leé lo que ya hay: `package.json`, `pyproject.toml`, `composer.json`, `Dockerfile`, configs de deploy (`vercel.json`, `wrangler.toml`, `netlify.toml`, workflows de CI), el README existente y `git remote -v`. Ahí suelen estar el nombre, el propósito, los comandos de run y build, el target de deploy y a veces el autor.

Inferir primero respeta el tiempo del usuario: cada dato que se puede leer del repo es una pregunta menos.

### 2. Preguntar solo lo que no se puede inferir, todo junto

Juntá las dudas en **un solo formulario** (AskUserQuestion si está disponible, con un máximo de 4 preguntas por formulario; si hacen falta más, un segundo formulario). Si no hay herramienta de formulario, mandá un único mensaje con las preguntas numeradas y opciones. No hagas preguntas sueltas una por una.

Candidatas, incluidas solo si no se pudieron inferir:

- **Titular del código:** agencia o estudio, cliente, o personal. Define LICENSE y quién figura en los legales.
- **Jurisdicción:** el default es **Argentina**, pero siempre se confirma con el usuario. Las opciones son Argentina, otra (cuál) o genérica.
- **¿Vende online?** Si la respuesta es sí y la jurisdicción es Argentina, aplica el botón de arrepentimiento.
- **¿Maneja datos personales?** Formularios, cuentas, newsletter, analytics con identificadores, etc.
- **¿El diseño UX/UI está definido?** Si no, DESIGN.md queda como pendiente.
- **¿Dónde se despliega?** Solo si no hay config de deploy en el repo.

Si las señales del check ya responden algo (por ejemplo, `mercadopago` en las dependencias indica que vende online), presentalo como opción preseleccionada para que el usuario confirme, en lugar de preguntarlo de cero.

### 3. Verificar la normativa vigente (solo si hay legales)

Las normas cambian; por ejemplo, la Res. SCI 424/2020 fue derogada en 2025. Antes de redactar PRIVACY, TERMS o algo sobre el botón de arrepentimiento:

1. Leé el **Apéndice A** (Argentina) o el **Apéndice B** (otras jurisdicciones o genérica).
2. Si tenés búsqueda web, confirmá que cada norma citada siga vigente, sobre todo si la fecha de "última verificación" del archivo tiene más de 6 meses. Si encontrás un cambio, usá la norma nueva y avisale al usuario.
3. Si no podés verificar, citá igual lo que dice la referencia, agregá en el documento `> Normativa verificada al <fecha de la referencia> — confirmar vigencia antes de publicar` e incluilo en la tabla final.

### 4. Redactar

Reglas que importan, con su porqué:

- **Contenido real, no relleno.** Cada sección se escribe con lo que dice el repo: comandos reales de `scripts` en package.json, variables reales de `.env.example` y carpetas reales. Si de verdad falta un dato técnico, poné `TODO: <qué falta y dónde averiguarlo>`.
- **Nunca inventes datos legales.** Razón social, CUIT, domicilio, email legal, nombre del responsable, número de registro de base de datos, tribunales competentes: todo eso va como marcador visible `TODO-LEGAL: <dato>`. Un CUIT inventado en unos términos publicados es peor que un hueco visible, porque nadie lo va a revisar.
- **Las decisiones no se fabrican.** En el ADR 0001, el contexto y la decisión salen de la evidencia del repo. Si el usuario no dio las alternativas descartadas, podés proponer las obvias, pero marcalas `(sugerido — confirmar)` para que no pasen por hechos.
- **Fuentes en los ADRs:** links a la documentación oficial de las tecnologías elegidas. Solo URLs que existan; si no podés verificar una, no la pongas.
- **Idioma:** el que use el usuario o el del README existent

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.