MCP HubMCP Hub
Retour aux compétences

decode-minified-js-gates

pjt222
Mis à jour Yesterday
3 vues
17
2
17
Voir sur GitHub
Développementgeneral

À propos

Cette compétence analyse les bundles JavaScript minifiés pour identifier et classifier les implémentations de feature flags ("portes"). Elle extrait le contexte, détecte divers modèles de lecture (synchrone, asynchrone, objet de configuration, etc.) et enregistre leurs mécanismes pour investigation. Utilisez-la pour rétro-ingénierier l'évaluation des feature flags dans du code de production obfusqué.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/decode-minified-js-gates

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

Decode Minified JS Gates

讀 minified JavaScript bundle 中旗字周之調用脈絡,生 gate-mechanics 錄:何 reader 變、何默認、何 conjunction、何役。probe-feature-flag-state 答「此 gate 開或關」;此技則答其前提——「此 gate 究行何事」。

用時

  • sweep-flag-namespace 所揭之旗,名不足以類者
  • 二進制用 gate-reader 函數逾一,須知某旗呼何者
  • gate 之「默認」現非 boolean({}null、數值字面),須解其實 reader 變
  • 疑 kill-switch(反置之 gate),而旗名不足以確
  • 述語以 && 合多 gate,須先列其共 gate 再探之

  • 必要:minified JavaScript bundle 文件(.js.mjs.bun
  • 必要:欲解之目標旗字,字面形
  • 可選:前番 decode 已知之 reader 函數名列,速第二步
  • 可選:脈絡窗大小之改;默旗出現處之前 300 字、後 200 字

Step 1: Extract the Context Window

定旗字之位,每出現處取不對稱窗。前脈絡(旗前)藏 reader 函數名;後脈絡(旗後)藏默認值與 conjunction。

BUNDLE=/path/to/cli/bundle.js
FLAG=acme_widget_v3                   # synthetic placeholder
PRE=300
POST=200

# All byte offsets where the flag string occurs
grep -boE "\"${FLAG}\"" "$BUNDLE" | cut -d: -f1 > /tmp/decode-offsets.txt
wc -l /tmp/decode-offsets.txt

# Capture an asymmetric window per occurrence
while read -r offset; do
  start=$((offset - PRE))
  [ "$start" -lt 0 ] && start=0
  length=$((PRE + POST))
  echo "=== offset $offset ==="
  dd if="$BUNDLE" bs=1 skip="$start" count="$length" 2>/dev/null
  echo
done < /tmp/decode-offsets.txt > /tmp/decode-windows.txt

less /tmp/decode-windows.txt

速首掃,可以 grep -oE 配 Perl-相容之負向後顧正則,一管收同窗。

得:每旗出現處一或多脈絡窗,各約 500 字。多次出現常共 reader 函數,而默認或 conjunction 或異——各審之。

敗則:若 bundle 過大不堪逐次 dd(>100MB 或出現次甚多),改 rg -B 5 -A 3 "$FLAG" "$BUNDLE" 為結構輸出之近。窗似損者,bundle 或為 UTF-16 或有非 ASCII 之分隔;以 iconv 或視作二進制處之。

Step 2: Identify the Reader Variant

minified gate 庫常出 4–6 種 reader 變,各語義異。reader 函數名為首示,調用簽名乃驗者。

變之分類(合成名——以 bundle 中實 minified 識別符代之):

VariantSynthetic shapeReturnsCommon usage
Sync booleangate("flag", false) or gate("flag", true)booleanStandard on/off feature switches
Sync config-objectfvReader("flag", {key: value})JSON objectStructured config (delays, allowlists, model names)
Bootstrap-aware TTLttlReader("flag", default, ttlMs)boolean (cached)Startup-path gates before remote config arrives
Truthy-onlytruthyReader("flag")truthy/falsyQuick checks; no explicit default
Async bootstrapasyncReader("flag")Promise<boolean>Gates resolved post-bootstrap
Async bridgebridgeReader("flag")Promise<boolean>Bridge/relay-channel gates with separate evaluation path

每脈絡窗合於變之式:

# Test for variant patterns. Replace the synthetic reader names with the
# actual minified identifiers found in the bundle.
grep -oE '\b(gate|fvReader|ttlReader|truthyReader|asyncReader|bridgeReader)\("acme_widget_v3"' /tmp/decode-windows.txt | sort | uniq -c

同旗現多變者(罕而實有——一旗於啟動時 sync 讀,bootstrap 後又 async 讀),別錄每出現之變。探結果或異。

得:每 gate-call 出現皆繫一變。掃中各變之計成二進制層之分布(如「60% sync boolean、30% config-object、10% TTL」)。

敗則:脈絡窗無可識之 reader 式者,旗或本未被 gate 調用——重審 sweep-flag-namespace 第二步之調用點類。窗有此分類外之 reader 名者,於研究檔中錄為新變,斟酌其是否須別處之徑。

Step 3: Extract the Default Value

默認乃 reader 之第二位置參(truthy-only/async 變則無)。取其精字面——falsetruenull0、字串或 JSON config 對象。

# Boolean default extraction (sync boolean and TTL variants)
grep -oE '\b(gate|ttlReader)\("acme_widget_v3",\s*(true|false)' /tmp/decode-windows.txt

# Config-object default — match the opening brace and capture until the
# matching brace at the same nesting depth. For minified bundles this is
# usually safe with a non-greedy match because objects rarely span lines.
grep -oE 'fvReader\("acme_widget_v3",\s*\{[^}]*\}' /tmp/decode-windows.txt

# Numeric default (rare but real for TTL or threshold gates)
grep -oE '\b(gate|ttlReader)\("acme_widget_v3",\s*[0-9]+' /tmp/decode-windows.txt

config-object 默認者,察其 JSON 結構——鍵常示 gate 之意(如 {maxRetries: 3, timeoutMs: 5000} 為重試-策略 config,非 feature toggle)。

得:每出現一精字面默認。boolean 無歧;config-object 須手讀其結構。

敗則:config-object 之配對大括號落於脈絡窗外者,於第一步增後脈絡之大。默認似為變參(如 gate("flag", x))者,其默認運行時始算——標為 DYNAMIC,以 probe-feature-flag-state 探實返之值。

Step 4: Detect Conjunctions and Kill Switches

多 gate 入合述語。conjunction(&&)與反置(!)變 gate 之實役。

# Conjunction detection: gate-call followed by `&&` and another gate-call
# within the same predicate window
grep -oE '(gate|fvReader|ttlReader|truthyReader|asyncReader|bridgeReader)\("acme_widget_v3"[^)]*\)\s*&&\s*(gate|fvReader|ttlReader|truthyReader|asyncReader|bridgeReader)\("acme_[a-zA-Z0-9_]+"' /tmp/decode-windows.txt

# Kill-switch detection: leading `!` before the gate-call
grep -oE '!\s*(gate|fvReader|ttlReader|truthyReader|asyncReader|bridgeReader)\("acme_widget_v3"' /tmp/decode-windows.txt

每偵得之 conjunction,列其共 gate 旗名。其入探之範——若目標旗之求值賴於共 gate,獨探目標生不全之態。

每偵得之反置,於 gate-mechanics 錄中標旗為 kill switch。kill switch 翻默認之意:default=false 之 kill switch 乃「默認 feature 開」(因 !false === true),而正 gate 之 default=false 乃「默認 feature 關」。

得:每出現一 conjunction 列(或空)及一反置標(boolean)。

敗則:conjunction 含逾二共 gate 者,述語繁過正則所及。手讀脈絡窗,於 gate-mechanics 錄中字面錄其述語形。

Step 5: Classify the Gate's Role

合第二至四步為一役類。役驅異探策與異整合險。

RoleSignatureImplication
Feature switchsync boolean, no inversion, no conjunctionStandard on/off; probe directly
Config providersync config-object (fvReader)Read returned object; default-empty {} ≠ feature off
Lifecycle guardbootstrap-aware TTL or async bootstrapState depends on bootstrap timing; probe at multiple points
Kill switchinverted gate, default-falseFeature on for users by default; flag flips it OFF
Conjunction memberany variant with && co-gateCannot evaluate alone; co-gates are part of the probe scope
Bridge gateasync bridge variantProbe must occur over the bridge channel, not the main path

得:每 gate-call 出現恰一主役。某旗於各出現現多役者(如某調用點為 feature switch,另一為 conjunction member)——各役別錄之。

敗則:役不合於表者,二進制用此技未錄之 gate 庫。以合成識別符添一行,以此變回饋此技(或項目專屬之擴)以利後察者。

Step 6: Produce the Gate-Mechanics Record

合每旗之得為結構化錄。JSONL 便焉,每旗一行,易與 sweep-flag-namespace 簿冊合。

{"flag":"acme_widget_v3","variant":"sync_boolean","default":false,"role":"feature_switch","conjunctions":[],"inverted":false,"occurrences":3}
{"flag":"acme_retry_policy","variant":"sync_config_object","default":{"maxRetries":3,"timeoutMs":5000},"role":"config_provider","conjunctions":[],"inverted":false,"occurrences":1}
{"flag":"acme_legacy_path","variant":"sync_boolean","default":false,"role":"kill_switch","conjunctions":[],"inverted":true,"occurrences":2}
{"flag":"acme_beta_feature","variant":"sync_boolean","default":false,"role":"conjunction_member","conjunctions":["acme_beta_program_active"],"inverted":false,"occurrences":1}

gate-mechanics 錄饋 probe-feature-flag-state 第二步(gate-vs-event 辨):變+役+conjunction 列定何觀為 LIVE/DARK/INDETERMINATE 態之證。

得:每旗一 JSONL 錄(或同旗多異機者每出現一錄)。錄可重——同二進制再行此法,得同錄。

敗則:錄於各次行間異者,上游某步非定。多為第一步正則漏或過配。campaign 行間鎖正則。

  • 第一步每旗出現一脈絡窗;窗約 500 字
  • 第二步每出現繫恰一 reader 變,自分類中
  • 第三步取精默認字面(boolean、config-object 或 DYNAMIC)
  • 第四步揭窗中所有 conjunction 與 kill-switch 反置
  • 第五步每出現繫一役,自役表中
  • 第六步生 JSONL gate-mechanics 錄,跨次行差別清
  • 一切例皆用合成 placeholder(acme_*gatefvReader 等)——無實旗名、實 reader 名或實 config-object schema
  • 錄可為 probe-feature-flag-state 所食(同旗識別符、相容欄名)

  • 以「默認」讀為「行為」default=true 之 gate 於此二進制默認開,而服務器側之蓋或翻之。默認言基線;運行時探(probe-feature-flag-state)言實態
  • 混 config-object 空默認與 feature 關fvReader("flag", {}) 默認返空對象——而旗(gate 求值為 truthy)。視 {} 為「關」乃誤類 config-provider 為 feature switch
  • 漏 kill switch:gate-call 前領之 ! 翻其義。跳第四步生「default=false,默認 feature 關」之錄,而實乃「default=false,因反置而默認 feature
  • 探 conjunction 之半:若述語為 acme_widget_v3 && acme_user_in_cohort,獨探 acme_widget_v3 而得 LIVE,未必 feature 真活——conjunction 或仍由 cohort 旗閉之
  • 跨版恃 reader 名:minified 識別符於主版間或變。第二步之分類乃按簽名(調用形、返類、默認位),非按名。版易則自新 decode 重得 reader 名
  • 窗過窄:200/100 之分漏 config-object 默認 300+ 字者。300/200 或 400/300 較安;唯 bundle 巨而窗代價要時始收
  • 漏實 reader 名:minified reader 名似無意(abYc1),易視為可貼。其仍為所獲——發法前以合成 placeholder 代之

  • probe-feature-flag-state——用 gate-mechanics 錄解運行時觀
  • sweep-flag-namespace——生此技所解之候旗集
  • monitor-binary-version-baselines——跨版跟 reader 名之變;基線翻則重導第二步之式
  • redact-for-public-disclosure——如何發 gate-decoding 法而不露實 reader 名或 schema
  • conduct-empirical-wire-capture——以運行時行為驗 gate-mechanics 錄

Dépôt GitHub

pjt222/agent-almanac
Chemin: i18n/wenyan/skills/decode-minified-js-gates
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Compétences associées

qmd

Développement

qmd est un outil CLI de recherche et d'indexation locale qui permet aux développeurs d'indexer et de rechercher dans des fichiers locaux en utilisant une recherche hybride combinant BM25, des embeddings vectoriels et du reranking. Il prend en charge à la fois une utilisation en ligne de commande et un mode MCP (Model Context Protocol) pour l'intégration avec Claude. L'outil utilise Ollama pour les embeddings et stocke les index localement, ce qui le rend idéal pour rechercher dans de la documentation ou des bases de code directement depuis le terminal.

Voir la compétence

subagent-driven-development

Développement

Cette compétence exécute des plans de mise en œuvre en déployant un nouveau sous-agent pour chaque tâche indépendante, avec une revue de code entre les tâches. Elle permet une itération rapide tout en maintenant des contrôles de qualité grâce à ce processus de revue. Utilisez-la lorsque vous travaillez sur des tâches principalement indépendantes au sein d'une même session pour assurer une progression continue avec des vérifications de qualité intégrées.

Voir la compétence

mcporter

Développement

La compétence mcporter permet aux développeurs de gérer et d'appeler des serveurs Model Context Protocol (MCP) directement depuis Claude. Elle fournit des commandes pour lister les serveurs disponibles, appeler leurs outils avec des arguments, et gérer l'authentification ainsi que le cycle de vie du démon. Utilisez cette compétence pour intégrer et tester les fonctionnalités des serveurs MCP dans votre flux de travail de développement.

Voir la compétence

adk-deployment-specialist

Développement

Cette compétence déploie et orchestre des agents Vertex AI ADK en utilisant le protocole A2A, gérant la découverte d'AgentCard, la soumission de tâches, et prenant en charge des outils tels que le bac à sable d'exécution de code et la banque de mémoire. Elle permet de construire des systèmes multi-agents avec des modèles d'orchestration séquentiels, parallèles ou en boucle en Python, Java ou Go. Utilisez-la lorsqu'on vous demande de déployer des agents ADK ou d'orchestrer des flux de travail d'agents sur Google Cloud.

Voir la compétence