본문으로 건너뛰기
cccskills
무료GitHub에 공개한국어 소개

poly-context

IntelliJ 플랫폼에서 파일이나 코드 위치에 적용되는 환경과 기능을 판별하는 `PolyContext` 구현을 돕습니다. 캐시를 사용하는 감지 제공자, 선언형 규칙, `.ws-context` 사용자 재정의를 다룹니다.

원문원문 설명 보기

Implement PolyContext feature gating and environment detection.

JetBrains/intellij-community스타 20,684(GitHub 20,684 + cccskills 0)

실행 점수 미검증

설치 방법 보기

이럴 때 유용합니다

  • 코드 위치에 적용되는 프레임워크 판별
  • 환경에 따라 기능 등록 전환
  • 파일이나 의존 패키지로 조건 정의
  • 사용자가 컨텍스트 값을 재정의

한국어 소개

할 수 있는 일

이 스킬은 IntelliJ 플랫폼에서 파일이나 코드 위치에 어떤 개발 환경 또는 기능이 적용되는지 판별하는 PolyContext 구현을 돕습니다. 파일을 파싱하기 전에 판별하는 방법과 구문 트리를 살펴보는 방법, 각 방식을 선택하는 상황을 설명합니다. 캐시를 사용하는 감지 제공자, Web Types JSON이나 코드로 정의하는 선언형 규칙, 사용자가 컨텍스트 값을 재정의할 수 있는 .ws-context 파일도 다룹니다.

이럴 때 유용합니다

프로젝트에 포함된 프레임워크나 패키지에 따라 기능을 켜는 플러그인을 만들 때 사용할 수 있습니다. 웹 개발뿐 아니라 Ruby gem이 있는지 확인하는 등 환경 판별에도 적용할 수 있습니다. 여러 기능이 같은 조건을 각각 확인하고 있다면 규칙을 한곳에 모아 중복 판별을 줄이는 설계에도 도움이 됩니다.

사용 예시

  • “이 파일에 적용되는 프레임워크를 판별하는 방법을 알려 주세요.”
  • “패키지 유무에 따라 컨텍스트를 전환하는 규칙을 추가해 주세요.”
  • “.ws-context의 사용자 설정을 반영하는 방법을 설명해 주세요.”

주의 사항

IntelliJ 플랫폼 플러그인 개발을 전제로 합니다. 감지 결과가 자주 조회되므로 제공자에서 캐시를 사용해야 합니다. VirtualFile과 Project를 사용하는 방식은 구문 트리에 접근할 수 없어, 파일 파싱 후 얻는 결과와 다를 수 있습니다.

이 소개문은 공개된 SKILL.md를 바탕으로 AI(OpenAI Codex)가 작성했습니다. 정확한 사양은 아래 원문을 확인하세요.

문서 점검

AI가 SKILL.md의 내용에서 주의가 필요한 작업과 도입 전제를 확인했습니다. 점수는 실제로 실행한 결과(실행 검증)만으로 매깁니다.

안전성전송·삭제·명령 실행 등을 명시하고 있는가
A양호설명된 작업은 컨텍스트 감지와 캐시이며 민감한 작업은 없습니다.
도입의 용이성필요한 도구나 API 키가 적고 적혀 있는가
B일부 부족IntelliJ 플랫폼 플러그인 개발이 필요하지만 도입 절차는 없습니다.

점수에는 넣지 않았습니다. 2026년 10월 28일 기준으로 AI(OpenAI Codex)가 판정했습니다. 참고용이므로 설치 전에 원문도 확인해 주세요.

평가가 다르다고 생각되면 재검토를 요청하기

어느 항목이 왜 다르다고 생각하는지 적어 주세요. 로그인은 필요 없습니다. SKILL.md와 대조해 평가를 다시 만들고 이곳에 반영합니다.

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

포함된 파일(1)

  • SKILL.md8.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

<!-- Generated by community/.ai/render-guides.mjs; edit community/.agents/skills/poly-context/SKILL.md -->

PolyContext

PolyContext answers "what coding environment am I in right now." It is a standalone platform mechanism — poly-symbols is its biggest consumer (gating which PolySymbolQueryScopeContributor/QueryConfigurator registrations apply), but PolyContext itself has no dependency on PolySymbols or on web frameworks being involved at all. Its defining advantage is that it is heavily optimized for performance (cached, cheap, RequiresReadLock-only), which makes it the right tool for any "is feature X relevant here" check that would otherwise get reinvented per-feature as an ad-hoc cached provider — not just "which JS framework is active." Confirmed non-web examples already in this repo: PolyContext.PKG_MANAGER_RUBY_GEMS/ PKG_MANAGER_SYMFONY_BUNDLES constants live right next to PKG_MANAGER_NODE_PACKAGES in PolyContext.kt, and ruby/tests/.../gem/GemContextTest.kt queries a "timecop-context" kind (is the timecop Ruby gem present?) with no PolySymbols query executor or web framework in sight.

For any given context kind (e.g. "framework"), at most one name is active at a location, or null if none applies.

PolyContext.get("framework", psiElement) // "vue" | "angular" | "astro" | null

Two location overloads

PolyContext.get(kind: PolyContextKind, location: PsiElement): PolyContextName?
PolyContext.get(kind: PolyContextKind, location: VirtualFile, project: Project): PolyContextName?
LocationCostCapability
PsiElementnormalcan inspect the PSI tree (e.g. check imports) — use for most coding-assistance logic
VirtualFile + Projectcheap, indexing-safeno PSI access; results may legitimately differ from the PsiElement answer for the same file once parsed

The VirtualFile+Project overload is what makes PolyContext usable during language substitution — i.e. before any PSI exists for the file, when the platform is still deciding which Language to parse it as. Concrete chain in this repo: WebFrameworkHtmlLanguageSubstitutor.getLanguage(file: VirtualFile, project: Project) (a LanguageSubstitutor, plugins/JavaScriptLanguage/web-platform/.../WebFrameworkHtmlLanguageSubstitutor.kt:15) → WebFramework.forContext(file, project) → PolySymbolFramework.inLocation(file, project) (community/platform/polySymbols/shared/src/com/intellij/polySymbols/framework/PolySymbolFramework.kt:52-53) → PolyContext.get(KIND_FRAMEWORK, file, project). The result picks which HTML dialect (Vue/Angular/plain) the file's Language is substituted to, entirely before a PSI tree is built.

Canonical PolySymbols use case: web framework detection. Only one of Vue/Angular/React/Astro can be the active framework at a location, and each plugin's PolySymbolQueryScopeContributor/ QueryConfigurator gates its registrations with .inContext { it.framework == MyFramework.ID } (see poly-symbols/references/query-model.md) — but this is one consumer among many, not the reason PolyContext exists.

PolyContextProvider — direct/dynamic detection

Implement isEnabled() (or isForbidden()) and register at EP com.intellij.polySymbols.context. Results are called very often — cache them (CachedValuesManager).

PolyContext.get("stimulus-context", psiElement) == "true"

Blocking: isForbidden() with name "any" suppresses an entire context kind — e.g. a Python templating (Blade-style) blocker disables the whole framework kind so it never conflicts with Vue/Angular detection.

Real examples in this repo/docs: StimulusContextProvider (checks for a JS import, caches the result), PyTemplatesWebContextBlocker (forbids framework when Python templating is detected). For a full custom-detector example, see VueFileContextProvider (contrib/vuejs/vuejs-backend/src/org/jetbrains/vuejs/context/VueFileContextProvider.kt) — returns true unconditionally for .vue files, and for any HTML-compatible file whose <script src="..."> matches a known Vue CDN/filename pattern (a cached-value scan, not a per-call check). Angular's equivalent is AngularCliContextProvider (contrib/Angular/.../org/angular2/cli/), registered at polySymbols.context kind="framework" name="angular".

Context rules — the declarative, faster alternative

Many providers redundantly re-check the same thing (is package X a dependency?). Context rules are declarative and let the platform compute proximity once instead of running N ad-hoc providers.

Via Web Types

Under a top-level contexts-config property in a Web Types JSON file (see poly-symbols/references/web-types.md): kind → name → enable-when/disable-when. (Pre-2024.2 files use a deprecated layout where name is top-level and kind a sibling property — don't use that shape for new files.)

enable-when rule kinds: file-extensions, file-name-patterns, ide-libraries, project-tool-executables, node-packages, ruby-gems. disable-when is more limited: file-extensions, file-name-patterns only.

Proximity scoring (lower = closer/stronger match; the winning name for a kind is whichever rule has the lowest total):

  • file-extensions / file-name-patterns → 0.0 (perfect match)
  • ide-libraries / ruby-gems → Double.MAX_VALUE (project/module-level match)
  • node-packages → computed from package.json location + dependency type: same directory as base 0.0, +1.0 per parent directory walked up, plus importance modifiers — peerDependencies +0.1, bundledDependencies +0.2, dependencies +0.3, optionalDependencies +0.4, devDependencies +0.5, indirect (node_modules) +0.6.

Web Types shipping a context rule are registered at EP com.intellij.polySymbols.webTypes (currently Node Package Manager only, requires the JS plugin) with two naming strategies: name the file after the real npm package if the rule should trigger on that package's presence, or use an arbitrary name + enableByDefault="true" if it should always apply.

Via code — PolyContextRulesProvider

For rules that can't be expressed as static file-based data, implement a PolySymbolQueryConfigurator and override getContextRulesProviders(project, dir): List<PolyContextRulesProvider> at EP com.intellij.polySymbols.queryConfigurator. Rule output must be stable — a change triggers project rescanning and cache invalidation.

.ws-context — user override file

Since 2024.1.2, users can force context values with a .ws-context JSON file:

  • <context kind> → <context name> — direct top-level assignment (implicitly applies to /**).
  • <GLOB path> → nested context-details object — GLOB supports only * in the final segment; ** matches nested directories.

When multiple patterns match a file, resolution priority is: (1) most path segments excluding **, (2) prefer patterns with an actual file-name match (not ending in **//), (3) first-defined wins.

PolyContextSourceProximityProvider

For integrating a new package manager or a language with a global-library concept, register at EP com.intellij.polySymbols.contextSourceProximityProvider and implement calculateProximity(), computing proximity per sourceNames entry matching a sourceKind (e.g. a dependency type). Return a Result with modificationTrackers — keep the tracker count minimal since it feeds every PolyContext.get() call.

Related

  • poly-symbols — PolyContext's biggest consumer, not something it depends on.
  • poly-symbols/references/web-types.md — contexts-config file format.
  • Official docs: Poly Symbols Context (the only official doc page for this API — despite the URL/page name, treat it as documenting a general-purpose context mechanism, not something PolySymbols-exclusive).

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

actions

무료요약 있음

IntelliJ `AnAction` 클래스를 구현하거나 수정하고 `plugin.xml`에 등록하도록 안내합니다. 표시 이름과 설명은 메시지 번들에 두고, 필요하면 아이콘을 설정하며, 이벤트 코루틴 범위에서 중단 함수를 실행해 동기식 처리로 IDE가 멈추는 일을 방지합니다.

  • IDE 메뉴에 새 동작 추가
  • 동작 등록이나 아이콘 변경
  • 동작 이름과 설명 정리
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

bazel-test-migration

무료요약 있음

IntelliJ JPS 테스트 모듈을 Bazel로 옮기고 Bazel에서만 발생하는 실패를 조사하는 안내서입니다. 의존성, 플러그인, 테스트 데이터와 runfiles 문제를 확인하고 생성된 대상과 이전된 테스트를 검증합니다.

  • 기존 JPS 테스트 모듈을 Bazel로 이전할 때
  • Bazel에서만 실패하는 테스트를 조사할 때
  • 테스트 의존성과 데이터 설정을 확인할 때
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

code-style

무료요약 있음

IntelliJ 프로젝트 규칙에 맞춰 Kotlin과 Java 코드를 작성하거나 검토합니다. 언어 선택, 서식, 봉인 타입, 스레드 주석, 제어 흐름 예외 처리를 확인합니다.

  • IntelliJ 규칙에 맞는 Kotlin 작성
  • Java 코드 검토
  • 예외 처리와 봉인 타입 분기 확인
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

commits

무료요약 있음

이 가이드는 IntelliJ 프로젝트의 변경 사항을 목적별로 나누고 프로젝트 형식에 맞는 커밋 메시지를 작성하도록 돕습니다. 티켓이 있으면 번호와 변경 설명을, 없으면 레이블과 하위 시스템명을 사용하며 필요에 따라 이유와 판단을 본문에 담습니다.

  • 티켓이 있는 변경의 프로젝트 형식 메시지 작성
  • 테스트나 문서 커밋에 적절한 레이블 적용
  • 기존 커밋 메시지를 규칙에 맞게 수정
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

compare-python-typecheckers

무료요약 있음

여러 Python 타입 검사기로 코드 조각이나 파일의 타입 추론과 오류 판정을 비교합니다. 도구별 결과, 실행 시간, 진단 내용을 Markdown 보고서로 모아 저장할 수 있습니다.

  • 검사기별 타입 추론 비교
  • 코드가 타입 오류로 판정되는지 확인
  • 여러 도구의 진단 결과 비교
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

compose-ui-architecture

무료요약 있음

Compose Desktop 화면을 구성할 때 컴포저블은 렌더링을 맡고 프레젠터나 코디네이터는 앱 결정을 맡도록 구조를 정리합니다. 상태 소유권, Effect, 재사용 컴포넌트 API, 지연 목록 키, 애니메이션과 성능을 개별 UI 변경에 맞춰 살펴봅니다.

  • 화면 렌더링과 프레젠터 판단 분리
  • UI 상태를 둘 위치 정리
  • Effect 키와 코루틴 사용 검토
JetBrains/intellij-community2.1만2026년 10월 29일 업데이트

JetBrains의 스킬 모두 보기

이 스킬의 문제 신고