Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

spec-scaling

Estrellas2

Forks0

Actualizado12 de abril de 2026, 23:06

Detects when SPEC.md or PRD.md exceeds 300 lines and proposes feature-based splitting with a master route document. Use when SPEC.md grows too large to be effectively used as a single document.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

uzysjung

uzysjung/uzys-agent-harness

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	spec-scaling
description	Detects when SPEC.md or PRD.md exceeds 300 lines and proposes feature-based splitting with a master route document. Use when SPEC.md grows too large to be effectively used as a single document.

Spec Scaling

When to Use

SPEC.md 또는 PRD.md가 300줄을 초과했을 때 자동 트리거.

Process

현재 SPEC.md/PRD.md의 줄 수를 확인한다.
300줄 초과 시 기능별 분리를 제안한다:

docs/
├── SPEC.md                    # 마스터 — 공통 규칙 + 각 기능 파일 라우트
├── specs/
│   ├── auth.md                # 인증/인가 기능 스펙
│   ├── dashboard.md           # 대시보드 기능 스펙
│   └── payment.md             # 결제 기능 스펙

마스터 SPEC.md 구조:

# SPEC: [프로젝트명]

## 공통 규칙
[전체 적용 Boundaries, Tech Stack, DO NOT CHANGE]

## 기능별 스펙
- [인증/인가](specs/auth.md)
- [대시보드](specs/dashboard.md)
- [결제](specs/payment.md)

인간 승인 후에만 분리 실행. 자동 분리 금지.

Rules

공통 규칙(Boundaries, Tech Stack, DO NOT CHANGE)은 마스터에 유지.
각 기능 스펙은 독립적으로 참조 가능해야 한다.
기능 간 의존성은 마스터에 명시.
분리 후 기존 SPEC.md는 마스터로 변환 (삭제 아님).

Más de este repositorio

mismo repositorio

model-orchestration

uzysjung/uzys-agent-harness

Apply the fixed model-role and thinking-effort policy whenever work is delegated to subagents or a model/effort choice is made: the orchestrator (top-tier model) DIRECTLY sets service direction, reviews plan/spec documents (with multi-persona-review), improves shipped features, and hunts performance/security problems; plan/spec/planning documents are AUTHORED by Opus, which also owns core implementation and V&V, at xhigh or above; repetitive implementation and E2E tests go to Sonnet at high or above — never delegate below those effort floors. Use whenever you are about to spawn an Agent/Task/Workflow worker, pick a model for a subtask, set a thinking/effort level, assign verification, or hand off orchestration because the current model's quota is exhausted. Trigger on "위임해", "에이전트로 돌려", "오케스트레이션", "모델 역할분담", "어떤 모델로", "effort 얼마로", "thinking level", "서브에이전트", or in English "delegate this", "spawn an agent for", "which model should", "route this task", "verify with", "orchestrate". Fire even when the user does

2026-07-072

gh-issue-workflow

uzysjung/uzys-agent-harness

Treats GitHub Issues as the async backlog + decision channel between user and AI agent. Use when a non-blocking todo / bug / decision needs to persist beyond the chat session. Enforces 5-section body template (Background / Given / Decision / AC / Next) so issues become reusable agent context, not just sticky notes.

2026-06-262

north-star

uzysjung/uzys-agent-harness

Defines and enforces a project's long-term direction (North Star Statement, NSM, Will/Won't, 4-gate decision heuristic). Use when starting a new project, when scope creep is suspected, or when a non-obvious feature request needs prioritization. Sits one layer above SPEC/PRD — answers 'why and where to', not 'what and how'.

2026-06-262

ui-visual-review

uzysjung/uzys-agent-harness

Captures screenshots of key UI flows after E2E tests pass, runs an agent-side first-pass diff (regressions, console errors, layout shifts), then surfaces a checklist for the user's final approval. Use after E2E tests pass on a UI track (csr-*, ssr-*, full). Adapts the GoalTrack screenshot-review pattern into a repeatable workflow.

2026-06-262

gap-analysis-e2e

uzysjung/uzys-agent-harness

Two-mode chained gap analysis. DETECT scans the current service end-to-end through three lenses — north-star alignment, correctness (bugs), and user-perspective (UX) — and enumerates concrete, severity-ranked gaps. Then BENCHMARK researches how reference/benchmark services actually solved each high-ranked gap and PROPOSES a closing approach. Use when the user says any of: "북극성 기준으로 부족한 점", "사용자 관점에서 부족한 점", "다른 벤치마크 서비스는 이 부분을 어떻게 해결했는지", "갭분석", "레퍼런스 서비스랑 비교해서 부족한 점 찾아줘" — or the English equivalents: "gap analysis", "what are we missing vs the ideal/north-star", "benchmark against reference services". Fires for both Korean and English phrasing. NOT for a whole-codebase multi-dimension audit (use ultracode-service-audit) or single-artifact prose review (use multi-persona-review) — this is the narrower gap-vs-benchmark loop.

2026-06-212

multi-persona-review

uzysjung/uzys-agent-harness

A panel-review skill that critiques ONE artifact (launch post, README, doc, markdown, plan, design) via 3-5 disjoint user-perspective personas running in parallel, then synthesizes deduped, severity-ranked improvement points (P0/P1/P2). Use when the user says "작성글을 사용자 관점의 페르소나를 여러명 만들어서 (손넷 모델정도로) 피드백 받아바", "다면 리뷰 해볼까", "페르소나로 리뷰", "여러 관점으로 피드백", or in English "multi-persona review", "review this from different user perspectives", "get persona feedback on this post/README/doc", "panel review this artifact". Lighter than a full service audit — point it at ONE artifact, not a whole codebase. NOT for a whole-codebase multi-dimension audit (use ultracode-service-audit) or a single-axis gap-vs-benchmark loop (use gap-analysis-e2e).

2026-06-212

name	spec-scaling
description	Detects when SPEC.md or PRD.md exceeds 300 lines and proposes feature-based splitting with a master route document. Use when SPEC.md grows too large to be effectively used as a single document.

Spec Scaling

When to Use

SPEC.md 또는 PRD.md가 300줄을 초과했을 때 자동 트리거.

Process

현재 SPEC.md/PRD.md의 줄 수를 확인한다.
300줄 초과 시 기능별 분리를 제안한다:

docs/
├── SPEC.md                    # 마스터 — 공통 규칙 + 각 기능 파일 라우트
├── specs/
│   ├── auth.md                # 인증/인가 기능 스펙
│   ├── dashboard.md           # 대시보드 기능 스펙
│   └── payment.md             # 결제 기능 스펙

마스터 SPEC.md 구조:

# SPEC: [프로젝트명]

## 공통 규칙
[전체 적용 Boundaries, Tech Stack, DO NOT CHANGE]

## 기능별 스펙
- [인증/인가](specs/auth.md)
- [대시보드](specs/dashboard.md)
- [결제](specs/payment.md)

인간 승인 후에만 분리 실행. 자동 분리 금지.

Rules

공통 규칙(Boundaries, Tech Stack, DO NOT CHANGE)은 마스터에 유지.
각 기능 스펙은 독립적으로 참조 가능해야 한다.
기능 간 의존성은 마스터에 명시.
분리 후 기존 SPEC.md는 마스터로 변환 (삭제 아님).