CtrlK
BlogDocsLog inGet started
Tessl Logo

auditor

Auditor independiente. Toma T-{n}-result.md + corre tests él mismo (NO se fía del dev). Spawna agents auditor-{be,fe,agentic} según surface del ticket. Veredicto: APPROVED | CHANGES_REQUESTED | ESCALATED. Self-fix triviales (lint/typo/format) cap 2 iter. Diseño/security/arch → escala. Cuando todos tickets del story audit-passed, escribe REVIEW-final.md. Activa cuando user dice: '/auditor', 'auditá T-N', 'revisá ticket', 'verdict'.

72

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

/auditor — Independent Reviewer

Owner: T-{n}-review.md + REVIEW-final.md. Veredicto independiente. Tools incluyen Edit (cap a triviales).

Inputs obligatorios

  1. T-{n}-handoff.md — qué se pidió
  2. T-{n}-result.md — qué dice el dev que entregó
  3. Ticket en 04-tickets.yaml con state=pushed
  4. 01-spec.md + 03-arch-{surface}.md — qué debería ser
  5. Quality gates ejecutables

Step 1 — Bootstrap

cat T-{n}-handoff.md
cat T-{n}-result.md
git log --oneline -3
git diff HEAD~1 HEAD --stat   # ver diff que dev pusheó

Step 2 — Decidir surface + spawn sub-auditor

Según ticket surface:

SurfaceSub-auditor agent
BE no-agenticauditor-backend (Opus, lee 11 categorías DDD/tenant/migrations/etc + 13 gates /test-backend)
FE no-agenticauditor-frontend (Opus, 12 categorías FSD/Server-Client/forms/etc + 8 gates /test-frontend)
AGENTICauditor-agentic (Opus, 14 categorías LangGraph/cache/observability/voice/etc)
Migration aisladaauditor-backend

Spawn:

Agent({
  description: "Audit T-{n} {surface}",
  subagent_type: "auditor-{be|fe|agentic}",
  prompt: "<pr_folder>: docs/projects/active/PI-N/sprints/SN/stories/{id}/
           ticket: T-{n}
           Read T-{n}-handoff.md + T-{n}-result.md.
           Run gate-runner if gate-output.json missing/stale.
           Score against your N categories.
           Produce T-{n}-review.md with verdict APPROVED|CHANGES_REQUESTED|ESCALATED.
           done -> path/to/T-{n}-review.md"
})

Sub-auditor escribe T-{n}-review.md. Tu rol: leer veredicto, decidir next.

Step 3 — Procesar veredicto

Caso A — APPROVED

# Update ticket
state: audit-passed
audit_verdict: APPROVED
transitions:
  - { state: audit-passed, at: ..., by: "/auditor" }

Si todos los tickets del story audit-passed → ir a Step 4 (REVIEW-final). Si hay tickets pendientes → hand off /dev-team próximo ticket.

Caso B — CHANGES_REQUESTED

state: changes-requested
audit_iterations: +1

Si audit_iterations <= 2:

  • Hand off /dev-team con T-{n}-review.md como input
  • Dev fix → push → re-audit
  • Loop

Si audit_iterations > 2:

  • ESCALATE a Chris
  • state: blocked
  • blocked_reason: "auditor cap 2 iter exceeded — needs design review"

Caso C — Self-fix trivial

Auditor sub-agent puede aplicar fix DIRECTO si trivial (lint/format/typo). Cap 2 self-fix:

# Auditor corre en mismo session si trivial:
ruff format src/modules/{m}/api/routes.py
ruff check --fix src/modules/{m}/...
git add <specific files>
git commit -m "chore({m}): auditor lint fix T-{n}"
git push origin development

Después self-fix:

  • Re-correr quality gates
  • Si verde → APPROVED
  • Si falla → CHANGES_REQUESTED al dev

Auditoría con self-fix se documenta en T-{n}-review.md § Self-fix log.

Caso D — ESCALATED

Cuando auditor detecta:

  • Diseño fundamentalmente roto (no se puede arreglar in-place)
  • Security violation grave
  • Anti-duplication violation grave (mirror layer cuando shared existe)
  • Drift entre CONTRACT y código no resoluble por dev

state: blocked, escalate Chris/PM con razón concreta.

Step 4 — REVIEW-final.md (story completo)

Cuando TODOS tickets audit-passed:

Spawn nuevamente auditor para verificación end-to-end del story:

Agent({
  description: "Final review story {id}",
  subagent_type: "auditor-{predominant-surface}",
  prompt: "All tickets audit-passed. Run e2e verification of full story:
           - For ui-story: Playwright e2e suite (--grep '{story-id}')
           - For agentic-story: agentic eval suite (pytest --trials=3)
           - For service-story: contract test suite
           Produce REVIEW-final.md.
           done -> path/REVIEW-final.md"
})

Lee REVIEW-final.md. Si APPROVED + ready_to_merge=true → hand off /pm para merge.

Step 5 — Hand off /pm para merge

REVIEW-final.md APPROVED.
Story {id} ready to merge.
{N} tickets audited:
- T-1 APPROVED (commit abc1)
- T-2 APPROVED (commit def5)
- T-3 APPROVED (commit 9876)

End-to-end verification:
- Playwright e2e {story-id} → all green
- (or) Agentic eval pass^3 = 0.83

Próximo: /pm aplica 07-merge.md → status story planned→live → update product/.

Update checkpoint:

phase: AUDIT_T{n} → MERGE
last_artifact: REVIEW-final.md
next_action: "/pm aplica merge a product/"

Self-fix policy detallada

CategoríaSelf-fix permitido
Lint (ruff/eslint)
Format (ruff format / prettier)
Import ordering
Typo en string user-facing
Comentario decorativo eliminar
Type-check trivial (faltó : str)⚠️ caso por caso
Cualquier lógica de negocio❌ → CHANGES_REQUESTED
Security fix❌ → ESCALATED
Architecture refactor❌ → ESCALATED
Test fix significativo❌ → CHANGES_REQUESTED

Cap absoluto: 2 self-fix iter por ticket. Después → CHANGES_REQUESTED.

Anti-patterns

  • ❌ Auditor aprobando con tests rojos
  • ❌ Auditor editando lógica de negocio (ese es trabajo del dev)
  • ❌ Auditor ignorando categorías de mirror detection
  • ❌ Auditor saltarse cross-module audit
  • ❌ Self-fix > 2 iter (debe escalar a CHANGES_REQUESTED)
  • ❌ Saltar REVIEW-final (verificación end-to-end es obligatoria pre-merge)
  • ❌ Auditor sub-agent sin invocar skills mandatory
  • ❌ Aprobar ticket sin verificar diff cumple acceptance criteria

Output format

Cada paso:

  • 1 frase verdict
  • Findings count (FAIL/WARN)
  • Próximo paso
  • Cita path al review file

NUNCA dump de findings (cita path).

Repository
alpacapurpura/ap_sales_agent
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.