Spec scaling
Skill uzysjung/uzys-agent-harness/templates/skills/spec-scaling
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.From its SKILL.md
npx -y skills add uzysjung/uzys-agent-harness --skill spec-scalingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.0 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
Spec Scaling
When to Use
SPEC.md 또는 PRD.md가 300줄을 초과했을 때 자동 트리거.
Process
- 현재 SPEC.md/PRD.md의 줄 수를 확인한다.
- 300줄 초과 시 기능별 분리를 제안한다 (SPEC와 PRD 둘 다 동일 패턴):
SPEC 분리 (기능별)
docs/
├── SPEC.md # 마스터 — 공통 규칙 + 각 기능 파일 라우트
├── specs/
│ ├── auth.md # 인증/인가 기능 스펙
│ ├── dashboard.md # 대시보드 기능 스펙
│ └── payment.md # 결제 기능 스펙
PRD 분리 (제품 영역별)
docs/
├── PRD.md # 마스터 — 비전, 사용자, 큰 그림 + 영역 파일 라우트
└── PRD/ # 영역별 세부 사양
├── platform-common.md # 플랫폼 공통 (인증, 권한, 인프라)
├── feature-screener.md # 스크리너 영역
├── feature-portfolio.md # 포트폴리오 영역
└── feature-simulator.md # 시뮬레이터 영역
도메인 비종속 구조. 본 패턴에서는
docs/PRD/하위에 위치. 두 패턴 모두 마스터 = 인덱스 + 공통, 하위 = 독립 참조 가능 단위 원칙.
- 마스터 SPEC.md 구조:
# SPEC: [프로젝트명]
## 공통 규칙
[전체 적용 Boundaries, Tech Stack, DO NOT CHANGE]
## 기능별 스펙
- [인증/인가](specs/auth.md)
- [대시보드](specs/dashboard.md)
- [결제](specs/payment.md)
- 마스터 PRD.md 구조:
# PRD: [프로젝트명]
## 1. 비전 / Personas / NSM
[North Star 요약 (없으면 생략)]
## 2. 영역별 사양
- [Platform Common](PRD/platform-common.md) — 인증/권한/인프라
- [Feature: Screener](PRD/feature-screener.md)
- [Feature: Portfolio](PRD/feature-portfolio.md)
## 3. 영역 간 의존성
- Screener → Portfolio (선택 결과 전달)
- All → Platform Common (인증 의존)
- 인간 승인 후에만 분리 실행. 자동 분리 금지.
Rules
- 공통 규칙(Boundaries, Tech Stack, DO NOT CHANGE)은 마스터에 유지.
- 각 하위 파일은 독립적으로 참조 가능해야 한다 — 다른 파일을 읽지 않아도 의미 통해야 함.
- 영역/기능 간 의존성은 마스터에 명시.
- 분리 후 기존 SPEC.md/PRD.md는 마스터로 변환 (삭제 아님).
- 하위 파일도 다시 300줄 초과하면 sub-area로 추가 분리 (재귀 적용).
When to Split SPEC vs PRD
| 경우 | 분리 대상 |
|---|---|
| 비즈니스 맥락 / 사용자 시나리오가 큰 비중 | PRD 우선 분리 |
| 기술 스펙이 핵심 (API, 데이터 모델, AC) | SPEC 우선 분리 |
| 둘 다 큰 경우 | PRD를 영역별로, SPEC를 기능별로 (서로 cross-link) |
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most plan spec skills give in ~1.0k tokens
Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07
- Ask one question at a timein 51 of 1099
- Break plans into vertical slicesin 29 of 1099, across 11 files
- Publish issues in dependency orderin 27 of 1099, across 9 files
- Iterate until user approves the breakdownin 25 of 1099, across 7 files
- Explore the repository to understand the codebase statein 24 of 1099, across 7 files
- Use domain glossary vocabularyin 23 of 1099, across 5 files
- Apply correct triage labels to published issuesin 23 of 1099, across 5 files
- Prefer AFK slices over HITLin 22 of 1099, across 7 files
- Write a specification before writing any codein 22 of 1099, across 14 files
- Write failing tests before implementation codein 22 of 1099, across 20 files
- Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
- Respect existing architecture decision recordsin 20 of 1099, across 5 files
Said here and by no other author read
- Check line count of spec documents
- Propose feature-based splitting if over 300 lines
- Maintain common rules in the master document
- List feature or area dependencies in the master document
- Ensure each sub-file is independently referenceable
- Convert existing documents to master instead of deleting
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.