← ClaudeAtlas

ultracode-service-auditlisted

Run a multi-agent, adversarially-verified full-service audit across 7 dimensions (code / UX / scalability / planning+north-star / security / promotion / extensible), separating findings into confirmed / unverified / rejected and producing a priority-ranked, M-numbered milestone roadmap (as many milestones as the findings warrant). Use when the user says "ultracode 전체 서비스 점검", "전체 서비스를 점검하자", "코드·UX·확장성·기획·북극성지표·보안·홍보 문제점을 파악하고 우선순위에 따라 개선", "다차원 서비스 감사", or in English "audit the whole service / full multi-dimensional service audit / find code, UX, scalability, planning, security, and marketing problems and prioritize fixes". The heavyweight superset audit — orchestrate it as a Workflow with fan-out finders and an adversarial verify pass. NOT for a single-artifact prose/README review (use multi-persona-review) or a single-axis gap-vs-benchmark loop (use gap-analysis-e2e) — those are the lighter siblings.
uzysjung/uzys-agent-harness · ★ 3 · AI & Automation · score 69
Install: claude install-skill uzysjung/uzys-agent-harness
# Ultracode Service Audit The heavyweight, multi-agent audit of an *entire* service across many dimensions at once. The fan-out is orchestrated as a **Workflow / multi-agent run, and it can be large** — the real run drove many agents in parallel, not a 7-agent minimum. "ultracode" implies that heavyweight parallelism: a finder (often several) per dimension plus a separate squad of verifiers. Where a single skill inspects one axis (UX, or code, or strategy), this one fans out finder agents per dimension, then runs a **separate adversarial verification pass** so that only findings that survive cross-examination are reported as real. The output is one priority-ranked roadmap where every item is dimension-tagged, evidence-graded, and traceable to the product's North Star. This is the skill behind the user's real request (turn 94): > "ultracode 현재까지 개발한 내용을 기준으로 전체 서비스를 점검하자. 코드상 문제, UX 상 문제, > 확장성 문제, 기획 및 북극성지표, 보안상, 홍보상의 문제점을 파악하고 각각의 개선점 ... > 우선순위에 따라 개선하자" That run produced **확정 29 / 미검증 0 / 기각 8** — the confirmed/unverified/rejected split is not decoration, it is the whole point. The **미검증 0 was *that run's* outcome, not a guarantee the bucket goes unused**: the 미검증 bucket is load-bearing and stays in the report the moment any finding lands with no verifier votes. A finding nobody could verify never gets reported as fact. ## When to use - The user wants a **whole-service health check**, not one narrow review — "전체 서비스를 점검하자", "다차원 감사", "audit everything before launc