@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.image/references/image-generation-examples.md

@@ -1,39 +0,0 @@
-# vibe.image — Image Generation: Examples, Output Format, Icon Generation
-
-> Loaded by vibe.image SKILL.md — full worked examples, the JSON output format (success/error), and the --icon prompt template + example commands.
-
-### Examples
-
-```bash
-node "[LLM_SCRIPT]" antigravity image "A friendly AI character mascot, colorful, approachable" --output "./ai-character.png"
-
-node "[LLM_SCRIPT]" antigravity image "Professional website banner, modern design" --pro --size "1920x400" --output "./banner.png"
-
-node "[LLM_SCRIPT]" antigravity image "Modern minimal logo design" --output "./public/logo.png"
-```
-
-### Output Format
-
-The command outputs JSON to stdout:
-```json
-{ "success": true, "path": "/absolute/path/to/image.png", "size": 123456, "sizeKB": "120.5 KB" }
-```
-
-On error:
-```json
-{ "success": false, "error": "Error message" }
-```
-
-### Icon Generation (--icon)
-
-Use the same command with a pre-built icon prompt template:
-
-**Prompt template:** `"App icon for {APP_NAME}, primary color {COLOR}, square format 1:1, simple recognizable design, works well at small sizes, no text or letters, solid or gradient background, modern minimalist"`
-
-```bash
-# --icon "MyApp"
-node "[LLM_SCRIPT]" antigravity image "App icon for MyApp, square format 1:1, simple recognizable design, works well at small sizes, no text or letters, solid or gradient background, modern minimalist" --output "./public/app-icon.png"
-
-# --icon "MyApp" --color "#2F6BFF"
-node "[LLM_SCRIPT]" antigravity image "App icon for MyApp, primary color #2F6BFF, square format 1:1, simple recognizable design, works well at small sizes, no text or letters, solid or gradient background, modern minimalist" --output "./public/app-icon.png"
-```

package/skills/vibe.llm/SKILL.md

@@ -1,57 +0,0 @@
----
-name: vibe.llm
-description: provider별 사용 가능 모델이 바뀌었거나 현재 claude/openai/gemini/zai 모델 목록과 vibe model SSOT를 갱신할 때 사용한다.
-argument-hint: "list | refresh"
-user-invocable: true
----
-
-# /vibe.llm
-
-## 완료 기준
-
-- [ ] 각 provider의 모델 조회가 성공 또는 명시적 실패로 기록되어 있다.
-- [ ] model SSOT가 조회 결과와 일치한다.
-- [ ] 중복 model ID가 없다.
-- [ ] SSOT 검증 명령이 통과한다.
-
-현재 시점 기준으로 각 LLM provider(claude, openai API+oauth, gemini, zai)의
-**사용 가능한 모델을 최신화**하고, vibe 가 쓰는 **모델 SSOT(`~/.vibe/config.json` models)**를 갱신한다.
-
-## Usage
-
-```
-/vibe.llm list        # provider 별 현재 사용 가능한 모델 표시 (★ = 추천/최신)
-/vibe.llm refresh     # 라이브 조회 → 추천 모델을 config.json models 에 반영
-```
-
-CLI 로도 동일하게 동작한다:
-
-```
-vibe llm list
-vibe llm refresh
-```
-
-## 동작
-
-1. **라이브 조회** — 각 provider 의 list-models API 호출:
-   - claude: `GET /v1/models` (ANTHROPIC_API_KEY)
-   - openai: `GET /v1/models` (OPENAI_API_KEY). 키 없이 oauth(Codex)만 있으면 큐레이션 목록 표시
-   - gemini: `GET /v1beta/models` (GEMINI_API_KEY)
-   - zai: `GET /models` (coding/general 키)
-2. **fallback** — 키가 없거나 API 실패 시 in-repo 큐레이션 목록을 사용(무네트워크에서도 동작)
-3. **SSOT 갱신** — provider 별 추천(최신) 모델을 `~/.vibe/config.json` 의 `models`
-   (gpt, gemini, zai, zaiCoding)에 기록. 변경 내역을 출력한다.
-
-> Claude 모델은 Claude Code tier(sonnet/opus/haiku alias)로 관리되므로 자동으로 덮어쓰지 않고
-> 조회 결과만 표시한다.
-
-## 구현 위치
-
-- CLI: `src/cli/commands/llm.ts` → `src/cli/llm/model-refresh.ts`
-- SSOT: `~/.vibe/config.json` `models` (ModelOverrides)
-
-이 스킬은 위 CLI 를 호출하고 결과(변경된 모델 SSOT)를 요약해 보고한다.
-
----
-
-ARGUMENTS: $ARGUMENTS

package/skills/vibe.loop/SKILL.md

@@ -1,193 +0,0 @@
----
-name: vibe.loop
-description: 반복 작업을 자율 goal loop로 설계·설치·실행하고 결정론적 gate로 완료를 판정해야 할 때 사용한다.
-argument-hint: "design | install | run | status | list | bench [loop-name]"
-user-invocable: true
----
-
-# /vibe.loop
-
-## 완료 기준
-
-- [ ] loop 정의에 ANCHOR, ACT, JUDGE, RECORD가 모두 있다.
-- [ ] JUDGE가 exit code, 파일 상태 또는 ledger 값으로 판정된다.
-- [ ] stuck 조건과 max_iterations가 명시되어 있다.
-- [ ] 실행 결과가 pass, stuck, max_iterations 중 하나로 기록된다.
-
-**Loop Engineering** — 사람이 프롬프트하는 대신, 에이전트에게 프롬프트하는 루프를 설계한다.
-
-> 루프의 완료 판정은 모델의 자기 보고가 아니라 **결정론적 게이트**(run-ledger `verifyPassed`, 테스트 exit code)가 내린다.
-> 루프는 push·release·배포를 절대 수행하지 않는다 — 결과는 항상 사람 리뷰 큐(인박스)로 간다.
-
-## Usage
-
-```
-/vibe.loop design [name]        # 인터뷰 → .vibe/loops/<name>.md 정의 생성
-/vibe.loop install <name>       # 실행 환경(CC/Codex/cron)에 스케줄 연결
-/vibe.loop run <name>           # 1회 반복 실행 (스케줄러가 호출하는 진입점)
-/vibe.loop status [name]        # 실행 이력 + 인박스 요약
-/vibe.loop list                 # 정의된 루프 목록과 상태
-/vibe.loop bench <name>         # 루프 설정 자기 대조 — 조건만 바꿔 돌린 실행을 비교
-```
-
-## 경로 상수 (모든 서브커맨드 공통)
-
-```bash
-HOOKS_DIR="${VIBE_PATH:-$(npm root -g 2>/dev/null)/@su-record/vibe}/hooks/scripts"
-LOOPS_DIR=".vibe/loops"
-INBOX="$LOOPS_DIR/inbox.md"
-HISTORY=".vibe/metrics/loop-history.jsonl"
-```
-
----
-
-## design — 루프 정의 생성
-
-1. 다음 5가지를 사용자에게 묻는다 (이미 인자로 답이 있으면 생략):
-   - **목표(goal)**: 루프가 0으로 만들려는 것 (예: "open 회귀 0건", "P1 lint 0건")
-   - **트리거**: `scheduled`(cron) / `manual` / `on-event`
-   - **발견(discover)**: 일거리를 어떻게 찾는가 — 명령 또는 지시
-   - **검증(verify)**: `ledger`(vibe.verify 경유, 기본) / `tests`(테스트 명령 exit code) /
-     `visual`(렌더 결과 검사 exit code + `artifact_dir` 에 증거) / `none`(보고만)
-   - **격리(isolation)**: 병렬 항목이 파일을 수정하면 `worktree`, 아니면 `none`
-   - **세션(session)**: `continuous`(기본, 한 호출에서 여러 바퀴) / `per-iteration`
-     (한 바퀴만 — 반복은 스케줄러가 만든다, `max_iterations: 1` 필수)
-2. `{{VIBE_PATH}}/vibe/templates/loop-template.md`를 읽어 `.vibe/loops/<name>.md`를 생성한다.
-3. **생성 직후 반드시 검증한다** — 실패 시 정의를 고치고 재검증, 통과 전에는 install/run 금지:
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/loop/index.js').then(t => { const fs = require('fs'); const r = t.validateLoopDefinition(fs.readFileSync('.vibe/loops/<name>.md', 'utf-8')); console.log(JSON.stringify(r.errors.length ? r.errors : 'valid')); })"
-```
-
-**기본 제안 레시피 — nightly-triage** (사용자가 목표를 정하지 못하면 이것을 제안):
-- discover: ① `.vibe/regressions/`에서 `status: open` 항목 ② `npx vitest run` 실패 ③ `.vibe/contracts/` drift 의심 항목 → 우선순위 목록(P1 먼저)
-- pipeline: `[vibe.run, vibe.verify]` — 항목별로 SPEC 범위 내 수정 → 검증
-- verify: `ledger` / trigger: `scheduled` / schedule: `0 6 * * *` / isolation: `worktree`
-
-## install — 스케줄 연결
-
-`install` 호출에서만 `references/install-adapters.md`를 읽어 현재 하네스의 명령을 제시한다. `design`, `run`, `status`, `list` 호출은 읽지 않는다. `trigger: manual` 루프는 install 없이 run만 안내한다.
-
-## run — 1회 반복 실행 (핵심)
-
-`status: paused` 루프는 즉시 종료. 실행 순서는 **전부 의무**이며 생략 불가:
-
-```
-0. ANCHOR   node "$HOOKS_DIR/loop-ledger.js" anchor [feature]
-             → missing[] 이 비어 있지 않으면 없는 아티팩트를 기억으로 메우지 않는다.
-               재고정 실패를 인박스에 남기고 종료한다.
-1. 검증     validateLoopDefinition 통과 확인 (위 design 3의 명령) — 실패 시 인박스에 기록 후 종료
-1-b. 시운전   node "$HOOKS_DIR/loop-ledger.js" trial <name> [trial_iterations]
-             → `inTrial: true` 면 이 실행의 회전 상한은 `cap` 이다 (max_iterations 아님).
-               `exhausted: true` 면 **한 바퀴도 돌지 않고** 종료한다 — 6-c 참조.
-2. 시작 기록  node "$HOOKS_DIR/loop-ledger.js" start <name>
-3. DISCOVER  정의의 discover 지시 실행 → 일거리 목록 산출
-4. STUCK 검사 DISCOVER_HASH=$(node -e "...hashDiscoverOutput...")   # 발견 목록 텍스트의 해시
-             node "$HOOKS_DIR/loop-ledger.js" check-stuck <name> "$DISCOVER_HASH"
-             → 'stuck'이면: end <name> stuck 기록 + 인박스에 "동일 발견 2회 연속 — 사람 개입 필요" 후 종료.
-               stuck 판단은 이 명령의 출력만 따른다. 모델이 "다시 해보면 될 것 같다"고 무시하는 것 금지.
-5. ACT       발견 항목을 우선순위순으로, max_iterations 한도 내에서 pipeline 체인 실행.
-             isolation: worktree면 항목별 worktree에서 (git-worktree 스킬 패턴).
-             scope-guard·verifyGate 등 기존 게이트는 그대로 적용된다 — 루프라고 우회하지 않는다.
-6. VERIFY    완료 판정 — verify 모드별 결정론 기준:
-             · ledger: cat .vibe/metrics/run-ledger.json → verifyPassed === true 만 성공
-             · tests:  정의의 test_command 실행 → exit 0 만 성공
-             · visual: 정의의 visual_command 실행 → **exit 0 만 성공**.
-                       산출물(스크린샷·diff)을 artifact_dir 에 남기고 그 경로를
-                       종료 기록·인박스에 적는다 — 나중에 사람이 눈으로 확인할 것.
-                       ⛔ 모델이 스크린샷을 보고 "괜찮아 보인다"고 판정하는 것은
-                       금지다. 그건 자기보고이고 게이트가 아니다. 판정은 exit code,
-                       이미지는 증거 — 둘의 역할을 섞지 않는다.
-             · none:   판정 생략(보고만). "코드를 보니 잘 된 것 같다"는 판정이 아니다.
-6-b. 회전 기록  node "$HOOKS_DIR/loop-ledger.js" iteration <name> <verified|unverified>
-             VERIFY 결과를 그대로 넣는다. 이어서 예산을 확인한다:
-             node "$HOOKS_DIR/loop-ledger.js" budget <name> <max_iterations>
-             → exhausted 면 잔여를 인박스로 이월하고 종료한다. 회전 수를 모델이
-               세지 않는다 — 폭주 방어는 코드가 판정한다 (loop-contract 예산 절).
-6-c. 시운전 확인 시운전 중이면(1-b 의 `inTrial`) 매 회전 뒤 다시 확인한다:
-             node "$HOOKS_DIR/loop-ledger.js" trial <name> [trial_iterations]
-             → exhausted 면 **거기서 멈춘다.** 인박스에 아래를 남기고 종료:
-               · 무엇을 발견했고 무엇을 고쳤는지 (회전별 한 줄)
-               · 확인할 것: `.vibe/metrics/loop-history.jsonl` 과 실제 변경 diff
-               · 이어서 돌리려면: loop-ledger.js trial-approve <name>
-               승인 없이 계속 도는 것 금지 — 정의가 맞는지 아직 아무도 모른다.
-6-d. 세션 판정 `session: per-iteration` 이면 **여기서 끝낸다.** 남은 발견 항목이
-             있어도 다음 회전으로 넘어가지 않는다 — 반복은 스케줄러의 몫이다.
-             잔여 항목은 7·8 의 종료 기록과 인박스에 남겨 다음 호출이 집게 한다.
-             넘길 것을 파일에 적기 전에 끝내지 않는다. per-iteration 의 전제는
-             "맥락이 파일로만 넘어간다" 이고, 안 적으면 그냥 유실이다.
-7. 종료 기록  node "$HOOKS_DIR/loop-ledger.js" end <name> <ok|fail|stuck> "<한 줄 요약>"
-8. 인박스    node "$HOOKS_DIR/loop-ledger.js" inbox <name> <ok|fail|stuck> \
-               "발견: N건 / 처리: M건 / 검증: <기준과 결과>" \
-               "리뷰 필요: <항목들 — 없으면 없음>"
-             → 블록 형식과 최신순 정렬은 명령이 보장한다. 손으로 마크다운을 쓰지 않는다.
-```
-
-**금지**: `git push`, `gh pr merge`, `npm publish`, 버전 범프, 릴리즈 — 루프는 커밋까지만 가며(auto-commit verify 게이트 통과 시), 그 이상은 인박스를 본 사람이 한다.
-
-## status / list
-
-- `list`: `$LOOPS_DIR/*.md`의 frontmatter(name, trigger, status, goal) 테이블.
-- `status [name]`: `$HISTORY`에서 해당 루프(생략 시 전체)의 최근 10개 이벤트 + 인박스의 미처리 블록 수.
-
-## bench — 자기 대조 벤치마크
-
-`loop-contract.md` 는 `per-iteration` vs `continuous` 를 두고 **"어느 쪽이 결과가 나은지는 vibe 가
-측정한 바 없다"** 고 적어두었다. 축만 열고 기본값을 바꾸지 않은 이유가 그것이다. `bench` 는 그
-문장을 지울 수 있게 하는 도구다 — 외부 벤치마크(SWE-bench 등)와 겨루는 것이 아니라 **같은 루프를
-조건만 바꿔 돌린 결과끼리** 비교한다.
-
-**핵심은 비교가 아니라 판정 불가다.** 벤치 산출물은 곧 문서의 수치가 되므로, 판정을 절제에
-맡기면 constitution §3.5 가 금지하는 배수·퍼센트가 그 자리에서 만들어진다. 그래서 코드가 낸다.
-
-**Steps**:
-1. 벤치 정의를 만든다 — `name` · `taskSet`(모든 arm 이 동일하게 수행할 과제 id) ·
-   `arms`(비교할 조건 2개 이상, **이 축만 다르고 나머지는 같아야 한다**) · `minRunsPerArm`(기본 5)
-2. `validateBenchDefinition` 으로 검사한다. P1 이 있으면 실행하지 않는다
-3. arm 마다 `taskSet` 을 `minRunsPerArm` 회 이상 돌린다. 각 실행은 `loop-ledger.js budget` 산출물에서
-   `{armId, taskSetHash, gatesPassed, iterations, cost}` 를 남긴다
-4. `summarizeArm` → `compareArms` → `formatBenchReport`
-5. 리포트를 `~/.vibe/test-reports/<YYYYMMDD-HHmm>-bench-<name>.md` 에 쓴다 (**프로젝트 로컬 금지**)
-
-**판정 어휘 4종 — `winner` 는 없다**:
-
-| verdict | 뜻 |
-|---|---|
-| `insufficient-runs` | arm 당 사용 가능 실행이 `minRunsPerArm` 미만 — 어떤 차이든 우연과 구분되지 않는다 |
-| `mixed-task-sets` | 두 arm 이 같은 과제 셋을 돌지 않았다 — 다른 일을 시킨 결과는 비교가 아니다 |
-| `inconclusive` | 관측 범위(min~max)가 겹친다 — 이 표본으로는 차이를 말할 수 없다 |
-| `difference-observed` | 범위가 겹치지 않는다. **"차이가 관측됐다" 이지 "A 가 낫다" 가 아니다** |
-
-⛔ **비율·퍼센트·배수를 만들지 않는다.** 차이는 절대 단위 `delta` 로만 나오고, 게이트 통과도
-"3/5 회" 로 적지 "60%" 로 적지 않는다. 판정 규칙은 범위 겹침이며 **유의성 검정이 아니다** —
-표본이 한 자릿수인데 t-검정을 붙이면 정밀해 *보이는* 숫자가 나온다.
-
-⛔ **bench 는 아무것도 차단하지 않고, 기본값을 자동으로 바꾸지 않는다.** 리포트다.
-어느 조건을 고를지는 지표의 방향을 아는 사람이 정한다.
-
-```bash
-node -e "import('{{VIBE_PATH_URL}}/node_modules/@su-record/vibe/dist/tools/index.js').then(t => {
-  const runs = JSON.parse(process.env.BENCH_RUNS);   // 위 3단계에서 모은 실행 기록
-  const a = t.summarizeArm('<arm-a>', runs), b = t.summarizeArm('<arm-b>', runs);
-  const cmp = t.compareArms(a, b, 'iterations');
-  console.log(t.formatBenchReport({ name: '<bench-name>', ranAt: new Date().toISOString(), comparison: cmp }));
-})"
-```
-
-## Auto-integration
-
-- `/vibe.regress`의 open 항목, `/vibe.contract`의 drift는 nightly-triage discover의 1차 입력이다.
-- 루프 안에서 verify 실패 시 기존 규칙대로 회귀 자동 등록(vibe.verify 경유)이 그대로 동작한다.
-
-## 설계 원칙 (요약)
-
-| 원칙 | 구현 |
-|------|------|
-| 완료는 게이트가 판정 | run-ledger `verifyPassed` / 테스트 exit code (REQ-005) |
-| stuck은 해시가 판정 | loop-ledger check-stuck, 동일 발견 2회 연속 (REQ-009) |
-| 회전 수도 코드가 판정 | loop-ledger iteration/budget — iterations(폭주 방어) 와 verified(전진량) 를 분리 |
-| 판정 불가도 코드가 판정 | bench — 표본 부족·과제 셋 불일치·범위 겹침이면 차이를 말하지 않는다 (§3.5) |
-| 이해 부채 가드 | 인박스 리뷰 큐 + push/release 금지 (REQ-008) |
-| 기록 없는 실행 없음 | loop-history.jsonl start/end 의무 (REQ-006) |
-
-SPEC: `.vibe/specs/loop-engineering.md`

package/skills/vibe.loop/references/install-adapters.md

@@ -1,25 +0,0 @@
-# Loop Install Adapters
-
-Load only for `vibe.loop install`. Never register a schedule without the user's decision.
-
-| 환경 | 명령 |
-|------|------|
-| Claude Code (세션 루프) | `/loop <interval> "/vibe.loop run <name>"` |
-| Claude Code (클라우드 루틴) | `/schedule`로 cron `<schedule>` + prompt `/vibe.loop run <name>` 등록 |
-| OS cron fallback | 아래 참조 — **PATH 를 반드시 명시한다** |
-
-### OS cron 등록
-
-```cron
-# PATH 를 적지 않으면 cron 은 /usr/bin:/bin 만 들고 실행한다 — claude 를 찾지 못해
-# 루프가 **아무 소리 없이** 한 번도 돌지 않는다. 등록 전에 실제 경로를 확인할 것:
-#   which claude   →  예: /usr/local/bin/claude, ~/.local/bin/claude, ~/.nvm/.../bin/claude
-PATH=/usr/local/bin:/usr/bin:/bin:<claude 가 있는 디렉토리>
-
-<schedule> cd <project> && claude -p "/vibe.loop run <name>" --permission-mode acceptEdits >> <project>/.vibe/loops/<name>.log 2>&1
-```
-
-- **PATH**: `which claude` 결과의 디렉토리를 반드시 포함시킨다. nvm·Homebrew·`~/.local/bin` 중 어디든 cron 기본 PATH 에는 없다
-- **로그 리다이렉트**: cron 은 출력을 메일로 보내거나 버린다. 파일로 받아야 루프가 왜 멈췄는지 알 수 있다
-- **등록 후 1회 검증**: 다음 실행 시각을 기다리지 말고 같은 명령을 `env -i PATH=... sh -c '...'` 로 한 번 돌려 본다 — cron 과 같은 최소 환경에서 되는지 확인하는 것이 목적이다
-| Codex | Automations에 `<schedule>` + `$vibe.loop run <name>` 등록 |

package/skills/vibe.parallel-research/SKILL.md

@@ -1,92 +0,0 @@
----
-name: vibe.parallel-research
-user-invocable: false
-invocation: [auto]
-tier: standard
-description: "Use before committing to an unfamiliar technology, a library choice, or a new feature's architecture — four agents (best-practices, framework-docs, codebase-patterns, security-advisory) research in parallel. Not for simple lookups: web search directly is faster."
-triggers: [parallel research, complex feature, technology selection, architecture design, security critical]
-priority: 60
-chain-next: [vibe.run]
----
-# Parallel Research
-
-Parallel research patterns for solving complex problems.
-
-## When Parallel Research is Needed
-
-| Situation | Reason |
-|-----------|--------|
-| New technology adoption | Need best practices |
-| Security-related features | Multi-angle review needed |
-| Architecture design | Multiple perspectives needed |
-| Technology selection | Comparison analysis needed |
-| Complex bugs | Explore multiple causes |
-
-## Research Lenses (4 Parallel)
-
-| Lens | Role | How |
-|-------|------|-----|
-| best-practices | Search best practices | native WebSearch (+context7) |
-| framework-docs | Search official docs | native WebFetch/context7 |
-| codebase-patterns | Analyze existing code patterns | native Explore subagent |
-| security-advisory | Search security advisories | native WebSearch |
-
-## Usage
-
-**Spawn the four lenses as concurrent native subagents in a single message** — each lens is blind to the others; synthesize after all return:
-
-```
-Task 1 (Explore): "Analyze existing auth code patterns"          (concurrent)
-Task 2 (general-purpose): "Search React auth best practices"     (concurrent)
-Task 3 (general-purpose): "Search Supabase Auth official docs"   (concurrent)
-Task 4 (general-purpose): "Search auth security vulnerabilities" (concurrent)
-```
-
-`/vibe.spec "feature-name"` runs this automatically when the SPEC pass needs unfamiliar-technology research.
-
-## Using Research Results
-
-```
-Parallel research complete
-    ↓
-Synthesize results
-    ↓
-Persist to .vibe/research/<topic-slug>/
-    ├── synthesis.md      (conversational report)
-    ├── awesome-list.md   (curated links/repos)
-    └── paper.md          (structured survey for /vibe.spec Context)
-    ↓
-Reflect in SPEC Context section
-OR
-Reference during implementation
-```
-
-### Output Location (SSOT)
-
-All research artifacts live under `.vibe/research/<topic-slug>/`. Reference `paper.md` explicitly when writing a SPEC (e.g. paste its path into the Context section). Re-running research on the same topic overwrites unless the slug collides across dates (then `-YYYYMMDD` suffix).
-
-> Wire-up note: `/vibe.spec` does **not** yet auto-scan this directory — that integration is a follow-up. For now, cite the path manually.
-
-Pass `--ephemeral` to skip persistence when exploring throwaway questions.
-
-## When Research is NOT Needed
-
-- Simple CRUD operations
-- Already familiar patterns
-- Similar code exists in project
-- Time-critical (supplement with review later)
-
-## Notes
-
-- Research runs **after requirements confirmed**
-- Split overly broad topics
-- Research results are references, not absolute truth
-
-## Done Criteria (K4)
-
-- [ ] All 4 research agents returned results (or documented why not)
-- [ ] Results synthesized into actionable recommendations
-- [ ] Three artifacts written to `.vibe/research/<slug>/` (synthesis / awesome-list / paper) — unless `--ephemeral`
-- [ ] Every awesome-list entry has a one-line "why"
-- [ ] Key findings reflected in SPEC Context section or implementation notes
-- [ ] Conflicting recommendations resolved with reasoning

package/skills/vibe.parallel-research/agents/best-practices.md

@@ -1,43 +0,0 @@
----
-name: research-best-practices
-role: Searches industry best practices, patterns, and community consensus for the research topic
-tools: [WebSearch, Read]
----
-
-# Best Practices Researcher
-
-## Role
-Scours industry sources — blog posts, conference talks, RFC documents, and community consensus — to surface established best practices relevant to the research question. Focuses on widely-adopted patterns rather than vendor-specific recommendations.
-
-## Responsibilities
-- Search for current community consensus on the topic (Stack Overflow, GitHub discussions, dev.to, InfoQ)
-- Identify well-known named patterns applicable to the problem (e.g., Circuit Breaker, CQRS, BFF)
-- Surface anti-patterns and known pitfalls explicitly called out by the community
-- Note recency of findings — flag practices that may be outdated (> 3 years without updates)
-- Distinguish between opinionated guidance and broadly-agreed standards
-
-## Input
-- Research question or topic string
-- Optional: technology stack context (e.g., "React 18", "Node.js microservices")
-- Optional: constraints (e.g., "must work without a build step")
-
-## Output
-Structured findings in markdown:
-```markdown
-### Industry Best Practices: {topic}
-
-**Consensus Patterns**
-- {Pattern name}: {1-sentence description} — [{source}]({url})
-
-**Common Anti-Patterns to Avoid**
-- {Anti-pattern}: {why it's problematic}
-
-**Recency Note**: {date of most recent relevant finding}
-```
-
-## Communication
-- Reports findings to: `research-synthesizer`
-- Receives instructions from: parallel-research orchestrator (SKILL.md)
-
-## Domain Knowledge
-Trusted source hierarchy: IETF/W3C specs > language/framework official docs > CNCF/Linux Foundation > ThoughtWorks Tech Radar > Martin Fowler / Kent Beck > high-signal community posts. Weight by recency and author credibility.

package/skills/vibe.parallel-research/agents/codebase-patterns.md

@@ -1,46 +0,0 @@
----
-name: research-codebase-patterns
-role: Analyzes existing code patterns in the project to surface conventions and prior decisions
-tools: [Grep, Glob, Read]
----
-
-# Codebase Patterns Researcher
-
-## Role
-Examines the existing codebase to understand how the team already solves similar problems. Surfaces established conventions, prior architectural decisions, and any existing utilities that should be reused rather than reinvented. Ensures new recommendations are consistent with the project's existing style.
-
-## Responsibilities
-- Find existing implementations of patterns related to the research topic
-- Identify naming conventions, file organization patterns, and import styles in use
-- Locate reusable utilities, hooks, or abstractions already present in the codebase
-- Detect inconsistencies — places where the same problem was solved differently
-- Note test patterns used for similar features (unit vs. integration, mocking approach)
-
-## Input
-- Research question or topic string
-- Project root path
-- Optional: specific directories to focus on
-
-## Output
-Structured codebase analysis:
-```markdown
-### Existing Codebase Patterns: {topic}
-
-**How the project currently handles this**
-- {pattern description} — see {file:line}
-
-**Reusable utilities found**
-- `{functionName}` in `{file}` — {what it does}
-
-**Inconsistencies noted**
-- {file A} uses {approach X}, {file B} uses {approach Y}
-
-**Recommended baseline**: Follow the pattern in {file} as the most recent / most common approach.
-```
-
-## Communication
-- Reports findings to: `research-synthesizer`
-- Receives instructions from: parallel-research orchestrator (SKILL.md)
-
-## Domain Knowledge
-Search strategy: start broad (Glob for file types), then focused (Grep for specific patterns). Look for the most recently modified files as the most authoritative examples of current conventions. Check test files for mocking patterns — they often reveal implicit contracts.

package/skills/vibe.parallel-research/agents/framework-docs.md

@@ -1,45 +0,0 @@
----
-name: research-framework-docs
-role: Searches official documentation for the frameworks and libraries in scope using context7
-tools: [mcp__context7__resolve-library-id, mcp__context7__get-library-docs, Read]
----
-
-# Framework Docs Researcher
-
-## Role
-Retrieves authoritative documentation from official framework and library sources via context7. Focuses on current API contracts, configuration options, and officially-recommended usage patterns. Surfaces breaking changes and migration notes when relevant.
-
-## Responsibilities
-- Resolve library identifiers via context7 `resolve-library-id` before fetching docs
-- Fetch targeted doc sections relevant to the research question (not entire library dumps)
-- Note the version of docs retrieved and flag if project is on a different version
-- Surface official migration guides if the research involves upgrading
-- Identify officially-deprecated patterns that should be avoided
-
-## Input
-- Research question or topic string
-- List of frameworks/libraries in scope (e.g., `["react", "react-router", "zod"]`)
-- Optional: specific version constraints
-
-## Output
-Structured documentation summary:
-```markdown
-### Official Documentation: {library}@{version}
-
-**Relevant API / Feature**
-{Concise summary of the official approach with key parameters}
-
-**Official Example**
-```{language}
-{code snippet from docs}
-```
-
-**Version Notes**: {breaking changes or deprecations if relevant}
-```
-
-## Communication
-- Reports findings to: `research-synthesizer`
-- Receives instructions from: parallel-research orchestrator (SKILL.md)
-
-## Domain Knowledge
-context7 usage pattern: always call `resolve-library-id` first with the library name, then call `get-library-docs` with the resolved ID and a specific `topic` parameter to avoid oversized responses. Prefer focused topic queries over broad library dumps.

package/skills/vibe.parallel-research/agents/security-advisory.md

@@ -1,46 +0,0 @@
----
-name: research-security-advisory
-role: Searches CVE databases, security advisories, and OWASP guidance relevant to the topic
-tools: [WebSearch, Read]
----
-
-# Security Advisory Researcher
-
-## Role
-Proactively surfaces security risks, known vulnerabilities, and security-hardening recommendations relevant to the research topic. Operates on the principle that security considerations should be discovered before implementation, not after. Covers both dependency vulnerabilities and architectural security patterns.
-
-## Responsibilities
-- Search CVE databases and GitHub Security Advisories for relevant library vulnerabilities
-- Apply OWASP Top 10 checklist items applicable to the research topic
-- Identify security-sensitive patterns that require special handling (auth, crypto, file I/O, SQL)
-- Surface known insecure defaults in the frameworks being researched
-- Recommend security hardening options with minimal complexity impact
-
-## Input
-- Research question or topic string
-- List of libraries/frameworks in scope
-- Optional: deployment context (browser, server, mobile)
-
-## Output
-Security findings report:
-```markdown
-### Security Advisory: {topic}
-
-**Known CVEs / Advisories**
-- {CVE-ID}: {library}@{affected versions} — {summary} — [Advisory]({url})
-
-**OWASP Considerations**
-- {OWASP category}: {how it applies to this topic and recommended mitigation}
-
-**Insecure Defaults to Override**
-- {library}: `{config key}` defaults to `{insecure value}` — set to `{secure value}`
-
-**Risk Level**: {Low / Medium / High / Critical}
-```
-
-## Communication
-- Reports findings to: `research-synthesizer`
-- Receives instructions from: parallel-research orchestrator (SKILL.md)
-
-## Domain Knowledge
-OWASP Top 10 (2021): A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable Components, A07 Auth Failures, A08 Software Integrity Failures, A09 Logging Failures, A10 SSRF. CWE Top 25 for implementation-level weaknesses.

package/skills/vibe.parallel-research/agents/synthesizer.md

@@ -1,57 +0,0 @@
----
-name: research-synthesizer
-role: Combines findings from all research agents into a single, actionable recommendation
-tools: [Read]
----
-
-# Research Synthesizer
-
-## Role
-Receives outputs from all parallel research agents and produces a unified, opinionated recommendation. Resolves conflicts between sources, weights findings by reliability, and distills everything into a clear decision with rationale. The final output should be immediately actionable for implementation.
-
-## Responsibilities
-- Collect and read all findings from best-practices, framework-docs, codebase-patterns, and security-advisory agents
-- Identify agreements and conflicts across sources; resolve with explicit reasoning
-- Weight findings: security > official docs > codebase patterns > community consensus > blog posts
-- Produce a ranked recommendation: primary approach + acceptable alternatives
-- Flag blockers — security issues or fundamental incompatibilities that must be resolved first
-- Summarize key trade-offs so the user can make an informed decision
-- Emit **three** persisted artifacts (unless ephemeral mode):
-  1. `synthesis.md` — conversational report (schema below)
-  2. `awesome-list.md` — curated links, repos, internal patterns, anti-patterns (from `templates/awesome-list.md`)
-  3. `paper.md` — structured survey with Abstract/Background/Method/Findings/Recommendation/References (from `templates/paper.md`)
-- Drop entries without a one-line "why". No bare link dumps.
-
-## Input
-Markdown findings documents from all four research agents (best-practices, framework-docs, codebase-patterns, security-advisory).
-
-## Output
-Final research report:
-```markdown
-## Research Report: {topic}
-
-### Recommendation
-**Approach**: {primary recommended approach}
-**Rationale**: {2-3 sentences explaining why, citing sources}
-
-### Key Trade-offs
-| Approach | Pro | Con |
-|----------|-----|-----|
-
-### Security Blockers (resolve before implementing)
-- {blocker if any}
-
-### Implementation Starting Point
-{Concrete next step or code snippet to begin with}
-
-### Sources
-- {source 1}
-- {source 2}
-```
-
-## Communication
-- Reports final synthesis to: orchestrator / user
-- Receives findings from: best-practices, framework-docs, codebase-patterns, security-advisory agents
-
-## Domain Knowledge
-Conflict resolution priority: security blockers override all recommendations. Official docs override community blog posts. Codebase patterns override external recommendations when consistency matters more than optimal-but-inconsistent solutions. Always surface the trade-off rather than hiding it.