Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/jeonje/claude-plugins/plan-quicknpx skills add JeonJe/claude-plugins --skill plan-quickgit clone --depth 1 https://github.com/JeonJe/claude-pluginsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00060 | $0.01556 |
| Opus 5 | $0.00030 | $0.00778 |
| Sonnet 5 | $0.00012 | $0.00311 |
| Haiku 4.5 | $0.00006 | $0.00156 |
Grade A, and why
plan-quick scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan Command
구현 전 계획 수립. 코드 작성 전 사용자 승인 대기 (승인 없이 진입 시 의도와 다른 결과 위험).
Use Cases
1. 신규 기능 계획
- Input: "/plan 실시간 알림 기능 추가"
- Action: 요구사항 재정의 → 리스크 분석 → Phase별 계획 → 사용자 확인 대기
- Output: 구조화된 구현 계획 + 리스크 + 복잡도 평가
2. 리팩토링 계획
- Input: "/plan 인증 시스템 리팩토링"
- Action: 현재 코드 분석 → 의존성 파악 → 단계별 마이그레이션 계획
- Output: 안전한 마이그레이션 로드맵 + 롤백 전략
3. 복잡한 버그 수정
- Input: "/plan 결제 동시성 이슈 해결"
- Action: 원인 분석 → 해결 옵션 2-3개 → 트레이드오프 비교
- Output: 옵션별 장단점 + 추천 방안
- (조건부) How tree: 실질 대안이 2개 이상이면 문제 → 접근 갈래 → 구체안으로 대안을 생성하고(떠오른 것 나열 X) 같은 레벨끼리 비교한다. 선택지 하나뿐이면 생략. 비교표는 Risk Gate Output의 Options 블록에 채운다.
4. Risky change gate
- Input: "/plan DB schema 변경", "/plan public API 수정", auth/security/payment/production/3+파일 변경
- Action: 근거 수집 → 영향 범위 확인 → 승인 필요한 계획으로 정리 → 코드 작성 금지
- Output: approval-ready plan + impact/risk/verification
5. Impact check
- Input: "/plan 이 API 변경 영향 봐줘", "/plan symbol rename 영향 확인"
- Action: 변경 계약(symbol/endpoint/schema/env/config/DTO/route) 식별 → 참조·테스트·문서·FE/BE 영향 확인
- Output: CLEAR/WATCH/BLOCK verdict + 근거
How It Works
계획 수행자(본 세션 인라인, 또는 워크스페이스에 planner 에이전트가 있으면 그것)는 다음을 수행한다:
- Analyze the request — 요구사항을 명확히 재정의
- Break down into phases — 실행 가능한 단계로 분해 (접근이 갈리면 phases를 How tree(문제 → 접근 갈래 → 구체안) 형태로 분해해 갈래별 단계를 비교)
- Identify dependencies — 컴포넌트 간 의존성 파악
- Assess risks — 잠재 블로커와 리스크 평가
- Estimate complexity & duration — High/Medium/Low + Phase별 구현/테스트 예상 소요와 근거(참조 구현 크기, 변경 파일 수, 미지수 개수). 근거 없는 숫자는 예상이 아니라 희망이다
- Present the plan — "WAITING FOR CONFIRMATION" 표시 후 사용자 명시적 승인 대기
- Gate risky changes — DB/auth/security/API/payment/production/3+ files require explicit approval before edits
- Check impact — for public contracts, list references, affected tests/docs, FE/BE or cross-repo impact
Confirmation Protocol
- 승인:
yes/proceed/ 긍정 응답 → 구현 시작 - 수정 요청:
modify: [변경사항]different approach: [대안]skip phase 2 and do phase 3 first
사용자가 명시적으로 승인하기 전에는 코드 변경/파일 작성 금지. 이유는 계획 단계의 잘못된 가정이 코드에 박히면 되돌리기 비용이 크기 때문. 위험 작업(DB schema, auth/security, public API, payment, production config, 3+ files, 2+ repos)은 반드시 계획 단계에서 멈춘다. 구현은 승인 후 별도 단계에서만 진행한다.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 136 lines · 60 tokens per session scan A 443b1c9610a9
plan-quick is a skill published in the GitHub repository JeonJe/claude-plugins (3 stars, last pushed 28d ago), licensed MIT. It adds 60 tokens to every session and 1,556 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
api-testing
HTTP API testing with Supertest (TS) and httpx/pytest (Python). Use when the user mentions API testing, Supertest, httpx, REST/GraphQL validation, or HTTP response errors.
phpunit-test-team-reviewing
Use this skill when the user asks for a team-based, consensus, multi-reviewer, or red-team review of Shopware PHPUnit tests — trigger phrases like "team review these tests", "consensus review the tests in PR.
researching-code
Use this skill when the user asks an architectural or semantic question about a codebase — phrases like "how does X work?", "what's the architecture?", "help me understand this codebase", "find all components that use Y", "trace the data flow from A to B", "where is feature Z handled", "I'm new to this code, where do…
dev-environment-bootstrapping
Use this skill when the user asks to bootstrap, set up, create, or initialize a Shopware development environment from scratch — phrases like "set up a Shopware dev environment", "clone and install Shopware", "initialize a Shopware plugin project", "bootstrap Shopware and a new plugin called X", "get a fresh Shopware…
phpunit-integration-to-unit-migrating
Use this skill ONLY when the user explicitly requests an audit, migration, or evaluation of whether a Shopware integration test belongs in the unit suite — trigger phrases like "audit integration tests", "migrate integration tests to unit", "is this an integration test or a unit test", "evaluate integration tests for…
cross-browser-typography-qa
Use this skill when web text looks clipped, flattened, wrapped incorrectly, misaligned, or materially different between Chromium and WebKit/Safari. Treat text rendering as both a geometry problem and a visual paint problem: passing DOM bounds does not prove that every glyph is intact.