HarryJhin
User코딩 에이전트용 개발방법론 플러그인. 설계에서 종료까지 이어지는 단계 사슬을 스킬로 덮고 세션마다 에이전트가 그 사슬에 진입하도록 강제한다.
Categories
Indexed Skills (20)
dispatching-parallel-agents
독립적인 문제 영역마다 서브에이전트 하나를 붙여 동시에 돌린다. Use when 서로 무관한 실패가 둘 이상일 때, 여러 테스트 파일·서브시스템이 각각 다른 이유로 깨졌을 때. 공유 상태나 순차 의존이 있으면 쓰지 않는다.
executing-plan
승인된 플랜을 현재 세션에서 직접 실행한다. 서브에이전트를 쓸 수 없거나 격리 이득이 없을 때의 실행 경로다. Use when 플랜 인라인 실행, 서브에이전트 없이 플랜 진행.
finding-unknowns
새 기능·멀티파일·아키텍처 작업의 설계 진입 스킬. 구현 전 unknowns를 털어 리뷰 통과한 스펙(해당 시 프로토타입)을 남긴다. Use when 새 기능, 기능 추가, 설계, 스펙 작성, "~를 만들자/붙이자". 1문장 diff로 설명되는 수정은 대상이 아니다.
finish
구현이 끝나고 테스트가 통과한 뒤 작업을 통합하는 방법을 정하고 산출물 수명을 닫는다. Use when 전 태스크 완료, 브랜치 마무리, 머지·PR 결정, 개발 종료.
managing-community-health-files
Use when 커뮤니티 헬스 파일(CODE_OF_CONDUCT, CONTRIBUTING, SECURITY.md, SUPPORT, GOVERNANCE, FUNDING.yml, CODEOWNERS, ISSUE_TEMPLATE, PULL_REQUEST_TEMPLATE, DISCUSSION_TEMPLATE)이 빠졌는지 점검하거나 표준에 맞게 새로 만들 때, 조직 `.github` 상속을 구성하거나 정본 문서를 고칠 때, community profile·health_percentage 수치를 해석할 때. 단일 파일 한 줄 수정은 대상이 아니다.
plan-review
플랜 문서를 리뷰어 패널로 검증한다. writing-plans가 플랜 작성 직후 호출한다. Use when 플랜 리뷰, 플랜 검증, 태스크 분해 검토, plan review.
receiving-code-review
받은 코드 리뷰 피드백을 검증하고 대응하는 규율. 맹목적 수용도 형식적 동의도 아닌 기술적 평가를 요구한다. Use when 리뷰 피드백 수령, 리뷰 지적 반영 직전, 피드백이 불명확하거나 기술적으로 의심스러울 때.
spec-review
스펙 문서를 리뷰어 패널로 검증한다. finding-unknowns가 스펙 작성 직후 호출한다. Use when 스펙 리뷰, 스펙 검증, 리뷰 패널, spec review.
subagent-driven-development
승인된 플랜을 태스크마다 fresh 구현자 서브에이전트로 실행하고 태스크마다 리뷰 게이트를 건다. 플랜 실행의 기본 경로다. Use when 승인된 플랜 실행 착수, 태스크 단위 디스패치, 플랜대로 구현.
systematic-debugging
수정을 제안하기 전에 근본 원인을 찾게 강제한다. Use when 버그·테스트 실패·예상 밖 동작·빌드 실패·성능 문제를 만났을 때. 증상만 덮는 수정을 막는다.
test-driven-development
기능·버그픽스 구현 전에 테스트를 먼저 쓰게 강제한다. Use when 기능 구현, 버그 수정, 리팩터링, 동작 변경에 착수할 때. 구현 코드를 쓰기 전에 적용한다.
using-git-worktrees
격리된 워크스페이스를 확보한다. 네이티브 도구를 우선하고 없을 때만 git worktree로 폴백한다. Use when 기능 작업 착수, 플랜 실행 직전, 현재 워크스페이스와 분리가 필요할 때.
using-groundwork
Use when starting any conversation - groundwork 설계 flow 진입을 강제한다. 새 기능·멀티파일·낯선 도메인 작업에서 코드·탐색·질문보다 먼저 이 규율을 적용한다.
verification-before-completion
완료·수정·통과를 주장하기 전에 검증 커맨드를 돌려 출력을 확인하게 강제한다. Use when 작업 완료 선언, 커밋·PR 생성 직전, "됐다"·"통과한다"·"고쳤다"를 말하려 할 때. 주장보다 증거가 먼저다.
writing-adr
ADR(Architecture Decision Record)의 형식·프로세스·신설 절차 정본. ADR 파일을 직접 쓰고, 위치·번호를 스캔으로 정한다. Use when "ADR 작성", "ADR 신설", "아키텍처 결정 기록", 구현 중 repo 아키텍처 결정을 문서로 남길 때.
writing-clearly-and-concisely
Apply Strunk's timeless writing rules to ANY prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Makes your writing clearer, stronger, and more professional.
writing-for-junior
맥락이 없는 주니어 독자가 문서만으로 이해하고 실행할 수 있게 쓰는 규범과 그것을 판정하는 렌즈. Use when 스펙·플랜·스킬·ADR을 쓰거나 고칠 때, 자기완결 판독성을 검토할 때, 용어·참조·서술 구조를 점검할 때.
writing-plans
승인된 스펙을 태스크 단위 실행 플랜으로 바꾸고, 리뷰 패널과 사용자 승인까지 닫는다. finding-unknowns의 다음 단계이고 실행 스킬의 앞 단계다. Use when 승인된 스펙의 실행 준비, "구현 계획", "플랜 작성", implementation plan, writing plans.
writing-skills
새 스킬을 만들거나 기존 스킬을 편집할 때, 또는 배포 전 스킬이 실제로 작동하는지 검증할 때 쓴다. Use when 스킬 작성, SKILL.md 편집·수정, 스킬 테스트, 배포 전 스킬 검증.
requesting-code-review
코드 리뷰어 서브에이전트를 디스패치해 완료된 작업을 요구·품질 기준으로 검증한다. Use when 태스크 완료 직후, 주요 기능 구현 후, 머지 전, 막혔을 때 새로운 시각이 필요할 때.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.