coreline-ai

작업을 해석하고, 필요한 도메인 팩과 에이전트/스킬 구성을 결정한 뒤, 스킬을 먼저 설계·바인딩하고, 실제 구현 에이전트 팀 runtime으로 handoff 가능한 Codex용 메타 하네스 패키지를 정의하는 메타 하네스 스킬.

내부링크 구조 설계, 백링크 기회 분석, 링크 전략을 작성하는 link-strategist 전용 스킬.

메타태그, 구조화 데이터, 콘텐츠 최적화 계획을 작성하는 on-page-optimizer 전용 스킬.

키워드 리서치, 검색 의도 분류, 경쟁 강도 분석, 타겟 키워드 우선순위를 정리하는 keyword-strategist 전용 스킬.

audit 결과와 3개 최적화 계획의 갭/충돌/우선순위를 종합 분석하는 seo-reviewer 전용 스킬.

웹사이트 SEO 진단, 키워드 전략, 온페이지/테크니컬/링크 최적화, 종합 갭 분석을 에이전트 팀이 협업하여 수행하는 메타 하네스 오케스트레이터.

웹사이트의 크롤링 접근성, 인덱싱 상태, Core Web Vitals, 보안을 진단하는 seo-auditor 전용 스킬.

크롤링 최적화, Core Web Vitals 개선, 사이트맵/robots.txt 정비 계획을 작성하는 technical-seo-eng 전용 스킬.

URL, PDF, 텍스트, 이미지 추출문, 메모, 기술 자료, 블로그 초안, SKILL.md/.skill 패키지를 입력받아 고품질 한국어 HTML 학습자료, 전문가 리포트, 공개 아티클, 교육 모듈, 블로그 원고, SEO 대시보드, 플랫폼별 블로그 변환, 스킬 감사 리포트, 레퍼런스 매뉴얼, 비교 매트릭스, 케이스 스터디, 랜딩 브리프, 체크리스트 플레이북, GitHub 저장소 분석 리포트, YouTube 영상 분석 리포트, 역할별 매뉴얼 분석 리포트까지 생성하는 최종형 다중 모드 스킬. adaptive-html-learning-ultimate의 13개 모드 라우터·레이아웃·평가 루브릭을 뼈대로 삼고 GitHub 분석·YouTube 분석·매뉴얼 분석·GitHub 기능/도입 가이드·사업계획서(business_plan)를 추가한 21개 모드 체계를, adaptive-html-blog-writer의 블로그 글쓰기·SEO·플랫폼·박스 선택 상세 규칙을 흡수하고, 현행 examples급 editorial 디자인 시스템을 유지하고, 필요 시 8000×6000 SVG 인포그래픽 Visual Template System을 섹션별로 배치한다. 반드시 사용해야 하는 트리거: - "HTML로 정리", "초보자용 HTML", "전문가용 HTML", "교육용 HTML", "아티클 HTML", "레퍼런스/매뉴얼 HTML" - "블로그 작성", "블로그 글 써줘", "포스팅 작성", "SEO 글", "티스토리/벨로그/네이버/워드프레스용" - "비교/장단점/선택 기준", "사례 연구/회고", "랜딩/소개 페이지", "체크리스트/플레이북" - "이 문서를 블로그 글로", "이 내용을 글감으로", "제목/도입부/목차/본문/마무리까지" - "스킬 분석", "SKILL.md 개선", "한 줄 한 줄 분석", "스킬 통합/감사" - "GitHub 저장소 분석", "깃허브 URL 분석", "owner/repo 분석", "README/이슈/릴리스/라이선스 분석" - "YouTube 분석", "유튜브 영상 분석", "youtube URL 요약

공고문과 사업 아이디어를 분석하고, 사용자를 심층 인터뷰한 뒤 시장·기술·경쟁사·특허·논문을 조사하여 정부지원사업·R&D 과제·투자 피치덱·기업/공공 제안서를 설계·작성하는 사업 논리 설계 시스템. 빈칸을 문장으로 채우는 생성기가 아니라 공고 분석 → 심층 인터뷰 → 가설 → 리서치 → 사업 논리 설계 → 공식 서식 매핑 → 초안 → 평가위원 검증의 순서로 작동한다. 산출물 DOCX/HWPX/PDF/PPTX/XLSX/MD. 트리거 — "사업계획서 써줘", "사업계획서 작성", "정부지원사업 지원서", "창업지원 사업계획서", "R&D 계획서", "기술개발 과제 계획서", "투자 피치덱 만들어", "IR 덱", "제안서 작성", "공고문 분석해서 사업계획서", "지원사업 신청서", "사업계획서 검토", "이 공고 분석해줘", "/bizplan".

Use when creating, auditing, or updating user-facing manuals, operator guides, admin tutorials, onboarding docs, workflow walkthroughs, or screen-recorded product guides from a real application or system.

Stanford STORM 방법론(다관점 질문 + 출처 grounding)을 cmux 멀티 페인으로 구현한 딥리서치 오케스트레이터. 메인 Opus가 5개 영혼 페인(회의주의자·경제학자·역사학자·학자·미래학자)을 직접 만들어 claude/codex/kimi에 분산하고, 각 영혼이 출처 강제 딥리서치를 수행해 cmux send로 메인에 보고한다. 그 뒤 4프롬프트 파이프라인(다중관점 스캔→모순 지도→종합→동료 검토)을 돌려 dist/<프로젝트>/index.html 자체완결 리포트를 만든다. 트리거 — "STORM 리서치", "다관점 딥리서치", "5영혼으로 조사", "스톰 방법으로 조사해줘", "여러 LLM으로 병렬 리서치", "/storm-research".

STORM 모순 지도 — 다섯 관점이 어디서 합의하고 어디서 정면 충돌하는지 도식화한다. Co-STORM의 moderator/mind-map 정신으로 단일 관점이 못 보는 "핵심 긴장"과 사각지대를 표면화. 입력은 storm-scan의 다관점 출력. 단독 호출 가능하며 storm-research 파이프라인의 2단계. 트리거 — "모순 지도", "관점 충돌 분석", "어디서 의견이 갈리나", "contradiction map", "/storm-contradict".

STORM 동료 검토 — 종합본을 적대적으로 검토해 출처 편향 전이(source bias transfer)와 부당한 연결(over-association)을 잡는다. 원논문이 경고한 grounded 생성의 두 실패모드를 전담 점검. 입력은 storm-synthesize 출력. 단독 호출 가능하며 storm-research 파이프라인의 4단계(최종 게이트). 트리거 — "동료 검토", "이 글 비판적으로 검토", "편향·비약 점검", "peer review", "팩트체크 적대적으로", "/storm-review".

STORM 다중 관점 스캔 — 하나의 주제를 회의주의자·경제학자·역사학자·학자·미래학자 다섯 렌즈로 동시에 조사해 출처 포함 다관점 리서치를 산출한다. Stanford STORM의 Perspective-Guided Question Asking을 단일 프롬프트로 구현. 단독 호출 가능하며 storm-research 파이프라인의 1단계이기도 하다. 트리거 — "다관점으로 조사", "여러 전문가 시각으로", "STORM 스캔", "multi-perspective", "/storm-scan".

STORM 종합 — 다섯 관점과 모순 지도를 하나의 논지를 가진 구조화된 글로 짠다. 나열이 아니라 충돌을 통과한 판단. Stanford STORM의 Outline Generation + Article Generation(인용 유지)을 구현. 입력은 storm-scan + storm-contradict 출력. 단독 호출 가능하며 storm-research 파이프라인의 3단계. 트리거 — "종합해줘", "하나의 글로 정리", "관점들 통합", "synthesis", "/storm-synthesize".

Use when the user asks to fix failing tests, CI failures, pytest/Jest errors, broken test suites, or red builds.

Use when the user asks to fix lint, formatting, typecheck, mypy, tsc, ruff, eslint, or static analysis errors.

Use when the user repeatedly asks to generate release notes from commits, diffs, PRs, or git changes (10 similar examples).

Use when the user asks to analyze a GitHub repository and create a concise 16:9 infographic brief or image-generation prompt.

Use when the user asks to review the current git diff, PR changes, code changes, or wants risk and bug analysis before committing.

Use when the user asks to update README, docs, API documentation, usage guides, or changelog-like documentation.

Create or update lightweight phased development plan documents with checkbox tasks, test cases, and completion criteria for implementation work

Automated test-driven fix loop — run tests, analyze failures, investigate root causes, fix code, and re-run until all tests pass with configurable max iterations

Dual-mode review skill — review implementation plans before coding (plan mode) or review code changes after implementation (code mode) with architecture, risk, and test analysis

Plan and coordinate parallel development workstreams using Claude Code sub-agents with worktree isolation for safe concurrent implementation

Generate or update release documentation — README.md styling with badges and navigation, CHANGELOG entries, and release notes for version management

[Android App Development] [Claude Code] sub-agent가 안드로이드 앱의 PRD, TRD 등을 분석하여 안드로이드 아키텍처(Kotlin/NDK) 기반 설계 의도 문서(design-intent.md)와 코드 품질 평가 기준(code-quality-guide.md)을 수립하도록 안내하는 안드로이드 전용 스킬입니다.

[Android App Development] [Claude Code] 안드로이드 최초 기획 문서(PRD, TRD 등)를 리뷰하고 안드로이드 생태계 제약사항에 맞춰 정합성을 교정, 문서를 상세화하는 안드로이드 메인 Agent 스킬입니다.

[Android App Development] [Claude Code] 구현 전담 Agent가 PRD, TRD, code-quality-guide.md를 바탕으로 안드로이드 프레임워크와 NDK 기반의 실제 앱 코드 및 테스트 코드를 안전하게 구현하도록 안내하는 스킬입니다.

[Android App Development] [Claude Code] 안드로이드 서브에이전트 파이프라인의 유일한 시작점이자 지휘 Agent입니다. 문서 상태와 handoff를 읽어 document-review, guide-generation, implementation, review 중 다음 worker를 결정하고, Reject 시 최대 3회 루프를 제어합니다.

[Android App Development] [Claude Code] 리뷰 전담 Agent가 설계 의도 문서(design-intent.md)와 품질 가이드(code-quality-guide.md)를 통해 구현된 안드로이드 및 NDK 코드를 엄격히 리뷰하도록 안내하는 스킬입니다.

Redesign README.md files with modern GitHub styling — badges, icons, tables, ASCII diagrams, and anchor navigation. Use when asked to restyle, modernize, or redesign a README with shields.io badges, section icons, or visual improvements.

Create or update lightweight phased development plan markdown documents for implementation work. Use when the user asks for a 개발 계획 문서, 구현 계획, dev plan, phased implementation plan, implement_*.md, checkbox-based task plan, or asks to formalize scope before coding.

Plan and coordinate parallel development workstreams across a codebase. Use when the user asks to parallelize implementation, split work into multiple PRs/agents, define file ownership boundaries, coordinate sub-agents, reduce merge conflicts, manage dependencies, or create a merge/integration plan for concurrent changes.

Engineering-manager style implementation plan review. Use when asked to review architecture, lock in an execution plan, assess data flow, edge cases, test coverage, performance, rollout risk, or perform an engineering review before coding.

Create, refine, and sync project response style, agent execution rules, and LLM/proxy usage policy into AGENT.md and CLAUDE.md from reusable JSON profiles. Use when the user wants to standardize Korean-first answers, force dev-plan-first workflows, require clarification before risky decisions, block default cloud API usage, prefer proxies such as multi_model_tui, or keep AGENT.md / CLAUDE.md aligned with a shared project rule set across repositories.

Create or update lightweight phased development plan markdown documents for implementation work. Use when the user asks for a 개발 계획 문서, 구현 계획, dev plan, phased implementation plan, implement_*.md, or a checkbox-based task plan before or during coding. Before drafting, read relevant project `.md` files to clarify the goal, scope, and documented rules. Generate or maintain `dev-plan/implement_YYYYMMDD_HHMMSS.md` with a clear purpose, scope limits, phased tasks, per-phase self-tests, and progress checkboxes.

"스킬 검증해줘", "스킬 보안 검사해줘", "이 스킬 안전한지 확인해줘"처럼 설치할 스킬 패키지의 안전성을 물을 때 사용하는 설치 전 검증 스킬. Always guide the user to the pre-install validation workflow via `skills add`, `skills validate`, and `skills audit` instead of direct `npx skills add`. If the user says "이 스킬 안전한지 확인해줘", assume they mean an installable skill package and answer with the wrapper workflow, not a review of the current repo source code, unless they explicitly say this repository, this folder, or local code review. Do not use for generic "스킬 설치해줘" requests unless validation or the wrapper is requested.