oh-my-customcodex 0.1.8 → 0.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -13,7 +13,7 @@
13
13
 
14
14
  **[한국어 문서 (Korean)](./README_ko.md)**
15
15
 
16
- 48 agents. 108 skills. 22 rules. One command.
16
+ 48 agents. 112 skills. 22 rules. One command.
17
17
 
18
18
  ```bash
19
19
  npm install -g oh-my-customcodex && cd your-project && omcodex init
@@ -132,14 +132,14 @@ Each agent declares its tools, model, memory scope, and limitations in YAML fron
132
132
 
133
133
  ---
134
134
 
135
- ### Skills (108)
135
+ ### Skills (112)
136
136
 
137
137
  | Category | Count | Includes |
138
138
  |----------|-------|----------|
139
139
  | Best Practices | 24 | Go, Python, TypeScript, Kotlin, Rust, React, FastAPI, Spring Boot, Django, Flutter, Docker, AWS, Postgres, Redis, Kafka, dbt, Spark, Snowflake, Airflow, pipeline-architecture-patterns, alembic, and more |
140
140
  | Routing | 4 | secretary, dev-lead, de-lead, qa-lead |
141
141
  | Workflow | 13 | structured-dev-cycle, deep-plan, research, evaluator-optimizer, dag-orchestration, worker-reviewer-pipeline, reasoning-sandwich, pipeline, and more |
142
- | Development | 9 | dev-review, dev-refactor, analysis, create-agent, intent-detection, web-design-guidelines, omcodex:takeover, skill-extractor, idea |
142
+ | Development | 10 | dev-review, dev-refactor, analysis, create-agent, intent-detection, web-design-guidelines, omcodex:takeover, skill-extractor, pre-generation-arch-check, idea |
143
143
  | Operations | 10 | update-docs, audit-agents, sauron-watch, monitoring-setup, token-efficiency-audit, fix-refs, release-notes, and more |
144
144
  | Memory | 3 | memory-save, memory-recall, memory-management |
145
145
  | Package | 3 | npm-publish, npm-version, npm-audit |
@@ -166,6 +166,7 @@ All commands are invoked inside the oh-my-customcodex GPT Codex + OMX session.
166
166
  | `/research` | 10-team parallel analysis with cross-verification |
167
167
  | `/sdd-dev` | Spec-Driven Development workflow |
168
168
  | `/ambiguity-gate` | Pre-routing ambiguity analysis |
169
+ | `/pre-generation-arch-check` | Check architecture risks before implementation |
169
170
  | `/adversarial-review` | Attacker-mindset security code review |
170
171
  | `/pipeline` | Execute YAML-defined pipelines |
171
172
  | `/pipeline resume` | Resume a halted pipeline from last failure point |
@@ -224,7 +225,7 @@ Key rules: R010 (orchestrator never writes files), R009 (parallel execution mand
224
225
 
225
226
  ---
226
227
 
227
- ### Guides (38)
228
+ ### Guides (39)
228
229
 
229
230
  Reference documentation covering best practices, architecture decisions, and integration patterns. Located in `guides/` at project root, covering topics from agent design to CI/CD to observability.
230
231
 
@@ -281,7 +282,7 @@ your-project/
281
282
  │ ├── specs/ # Extracted canonical specs
282
283
  │ ├── contexts/ # 4 shared context files
283
284
  │ └── ontology/ # Knowledge graph for RAG
284
- └── guides/ # 38 reference documents
285
+ └── guides/ # 39 reference documents
285
286
  ```
286
287
 
287
288
  ---
package/dist/cli/index.js CHANGED
@@ -3087,7 +3087,7 @@ var init_package = __esm(() => {
3087
3087
  workspaces: [
3088
3088
  "packages/*"
3089
3089
  ],
3090
- version: "0.1.8",
3090
+ version: "0.2.0",
3091
3091
  description: "Batteries-included agent harness on top of GPT Codex + OMX",
3092
3092
  type: "module",
3093
3093
  bin: {
package/dist/index.js CHANGED
@@ -2173,7 +2173,7 @@ var package_default = {
2173
2173
  workspaces: [
2174
2174
  "packages/*"
2175
2175
  ],
2176
- version: "0.1.8",
2176
+ version: "0.2.0",
2177
2177
  description: "Batteries-included agent harness on top of GPT Codex + OMX",
2178
2178
  type: "module",
2179
2179
  bin: {
package/package.json CHANGED
@@ -3,7 +3,7 @@
3
3
  "workspaces": [
4
4
  "packages/*"
5
5
  ],
6
- "version": "0.1.8",
6
+ "version": "0.2.0",
7
7
  "description": "Batteries-included agent harness on top of GPT Codex + OMX",
8
8
  "type": "module",
9
9
  "bin": {
@@ -336,6 +336,16 @@
336
336
  }
337
337
  ],
338
338
  "PostToolUse": [
339
+ {
340
+ "matcher": "tool matches \"^mcp__playwright__\"",
341
+ "hooks": [
342
+ {
343
+ "type": "command",
344
+ "command": "bash .codex/hooks/scripts/playwright-compress.sh"
345
+ }
346
+ ],
347
+ "description": "Compress verbose Playwright MCP output while preserving refs and URLs"
348
+ },
339
349
  {
340
350
  "matcher": "tool == \"Bash\"",
341
351
  "hooks": [
@@ -0,0 +1,79 @@
1
+ #!/bin/bash
2
+ set -euo pipefail
3
+
4
+ input=$(cat)
5
+ tool_name=$(echo "$input" | jq -r '.tool_name // .tool // ""')
6
+
7
+ if [[ ! "$tool_name" =~ ^mcp__playwright__ ]]; then
8
+ exit 0
9
+ fi
10
+
11
+ raw_output=$(echo "$input" | jq -c '.tool_response // .tool_output.output // .tool_output // empty')
12
+
13
+ if [ -z "$raw_output" ] || [ "$raw_output" = "null" ]; then
14
+ exit 0
15
+ fi
16
+
17
+ text_output=$(printf '%s' "$raw_output" | jq -r 'if type == "string" then . else tostring end')
18
+ min_chars=${PLAYWRIGHT_COMPRESS_MIN_CHARS:-3000}
19
+
20
+ if [ "${#text_output}" -lt "$min_chars" ]; then
21
+ exit 0
22
+ fi
23
+
24
+ ref_matches=$(printf '%s\n' "$text_output" | grep -oE 'ref[=:]"?[^", ]+' || true)
25
+ refs=$(printf '%s\n' "$ref_matches" \
26
+ | sed 's/^ref[=:]"*/ref=/' \
27
+ | awk 'length($0) > 0 && !seen[$0]++' \
28
+ | head -12 \
29
+ | paste -sd ', ' -)
30
+
31
+ url_matches=$(printf '%s\n' "$text_output" | grep -oE 'https?://[^" )]+' || true)
32
+ urls=$(printf '%s\n' "$url_matches" \
33
+ | awk 'length($0) > 0 && !seen[$0]++' \
34
+ | head -6 \
35
+ | paste -sd ', ' -)
36
+
37
+ important_matches=$(printf '%s\n' "$text_output" | grep -iE 'ref=|error|failed|warning|timeout|assert|url|title|text|name|role|selector' || true)
38
+ important_lines=$(printf '%s\n' "$important_matches" \
39
+ | sed 's/^[[:space:]]*//; s/[[:space:]]\+/ /g' \
40
+ | awk 'length($0) > 0 && !seen[$0]++' \
41
+ | head -25)
42
+
43
+ if [ -z "$important_lines" ]; then
44
+ important_lines=$(printf '%s\n' "$text_output" \
45
+ | sed 's/^[[:space:]]*//; s/[[:space:]]\+/ /g' \
46
+ | awk 'length($0) > 0 && !seen[$0]++' \
47
+ | head -20)
48
+ fi
49
+
50
+ if [ -z "$important_lines" ]; then
51
+ important_lines='(no high-signal lines detected; payload was compressed by fallback rules)'
52
+ fi
53
+
54
+ summary=$(
55
+ {
56
+ printf 'Playwright MCP output compressed.\n'
57
+ printf 'Original size: %s chars.\n' "${#text_output}"
58
+ if [ -n "$refs" ]; then
59
+ printf 'Preserved refs: %s\n' "$refs"
60
+ fi
61
+ if [ -n "$urls" ]; then
62
+ printf 'URLs: %s\n' "$urls"
63
+ fi
64
+ printf '\nHigh-signal lines:\n'
65
+ printf '%s\n' "$important_lines"
66
+ } | head -c "${PLAYWRIGHT_COMPRESS_MAX_CHARS:-2500}"
67
+ )
68
+
69
+ if [ -z "$summary" ]; then
70
+ exit 0
71
+ fi
72
+
73
+ jq -n \
74
+ --arg summary "$summary" \
75
+ --arg note "Playwright MCP output compressed to preserve refs and reduce context cost." \
76
+ '{
77
+ additionalContext: $note,
78
+ updatedMCPToolOutput: $summary
79
+ }'
@@ -18,6 +18,8 @@ Auto-activates when: 4+ parallel tasks, batch operations, 80%+ context usage, or
18
18
 
19
19
  **Compression**: File lists -> count only (unless < 5), error traces -> first/last 3 lines, code -> path:line ref only.
20
20
 
21
+ **Pruning Transparency**: When input pruning occurs, include a compact report line such as `[Pruned] {n} files, ~{tokens} tokens saved` so the user can see what was compressed away.
22
+
21
23
  ## Config
22
24
 
23
25
  ```yaml
@@ -0,0 +1,72 @@
1
+ ---
2
+ name: design-shotgun
3
+ description: Generate and compare multiple deliberate UI directions before converging on one implementation path
4
+ scope: core
5
+ user-invocable: true
6
+ argument-hint: "<screen-or-flow>"
7
+ ---
8
+
9
+ # Design Shotgun
10
+
11
+ Use this skill when one polished mockup is too early and the real need is breadth first. The goal is not random variety; it is structured divergence followed by deliberate convergence.
12
+
13
+ ## When To Use
14
+
15
+ - early UI exploration
16
+ - redesign of a high-visibility screen
17
+ - style selection before implementation
18
+ - multiple viable directions need comparison
19
+
20
+ ## Workflow
21
+
22
+ ### 1. Pick comparison axes
23
+
24
+ Choose 2-3 axes that should differ between options:
25
+
26
+ - editorial vs. utilitarian
27
+ - dense vs. spacious
28
+ - bold vs. restrained
29
+ - product-led vs. workflow-led
30
+
31
+ ### 2. Generate 4-6 directions
32
+
33
+ Each direction should differ materially in:
34
+
35
+ - hierarchy
36
+ - composition
37
+ - copy tone
38
+ - motion or interaction emphasis
39
+
40
+ Avoid trivial color-swaps.
41
+
42
+ ### 3. Compare on one board
43
+
44
+ For each direction, record:
45
+
46
+ - strongest move
47
+ - weakest move
48
+ - what kind of user it favors
49
+ - what should survive into the final hybrid
50
+
51
+ ### 4. Build taste memory
52
+
53
+ Preserve:
54
+
55
+ - chosen typography moves
56
+ - preferred spacing rhythm
57
+ - colors or motifs worth keeping
58
+ - rejected patterns to avoid repeating
59
+
60
+ ### 5. Converge
61
+
62
+ Produce one implementation direction with:
63
+
64
+ - headline design thesis
65
+ - components to build first
66
+ - references to related guides or skills
67
+
68
+ ## Related References
69
+
70
+ - `.codex/skills/impeccable-design/SKILL.md`
71
+ - `.codex/skills/web-design-guidelines/SKILL.md`
72
+ - `guides/browser-automation/README.md` for consistent browser-based comparison capture
@@ -307,6 +307,30 @@ agents:
307
307
  # ---------------------------------------------------------------------------
308
308
  # Research / Information Gathering (skill-based, not agent)
309
309
  # ---------------------------------------------------------------------------
310
+ wiki-rag:
311
+ keywords:
312
+ korean:
313
+ - 아키텍처
314
+ - 워크플로우
315
+ - 어떤 에이전트
316
+ - 어떤 스킬
317
+ - 규칙
318
+ english:
319
+ - architecture
320
+ - workflow
321
+ - "which agent"
322
+ - "which skill"
323
+ - rule
324
+ - "how does this work"
325
+ file_patterns: []
326
+ supported_actions:
327
+ - explain
328
+ - search
329
+ - investigate
330
+ - research
331
+ base_confidence: 80
332
+ routing_rule: "Use wiki-rag for architecture, workflow, agent, skill, and rule questions before broader exploration"
333
+
310
334
  research-workflow:
311
335
  keywords:
312
336
  korean:
@@ -369,6 +393,90 @@ agents:
369
393
  action_weight: 25
370
394
  routing_rule: "Suggest codex-exec hybrid when codex available, or gemini-exec hybrid when gemini available, for new file creation tasks"
371
395
 
396
+ product-strategy:
397
+ keywords:
398
+ korean:
399
+ - 제품 전략
400
+ - 오피스 아워
401
+ - 창업자 질문
402
+ - CEO 리뷰
403
+ - 범위 축소
404
+ english:
405
+ - "product strategy"
406
+ - "office hours"
407
+ - "ceo review"
408
+ - "founder questions"
409
+ - "scope reduction"
410
+ file_patterns: []
411
+ supported_actions:
412
+ - analyze
413
+ - plan
414
+ - review
415
+ - reduce
416
+ base_confidence: 65
417
+ routing_rule: "Use the product-strategy skill to pressure-test product bets before implementation"
418
+
419
+ design-shotgun:
420
+ keywords:
421
+ korean:
422
+ - 디자인 샷건
423
+ - 시안 비교
424
+ - 테이스트 메모리
425
+ - 방향 비교
426
+ english:
427
+ - "design shotgun"
428
+ - "compare directions"
429
+ - "taste memory"
430
+ - "variation board"
431
+ file_patterns: []
432
+ supported_actions:
433
+ - create
434
+ - compare
435
+ - review
436
+ - polish
437
+ base_confidence: 65
438
+ routing_rule: "Use the design-shotgun skill for multi-direction UI exploration before converging on one implementation"
439
+
440
+ browser-automation-reference:
441
+ keywords:
442
+ korean:
443
+ - 브라우저 자동화
444
+ - 쿠키 임포트
445
+ - 안티봇
446
+ - 세션 재사용
447
+ english:
448
+ - "browser automation guide"
449
+ - "cookie import"
450
+ - anti-bot
451
+ - "session reuse"
452
+ file_patterns: ["playwright.config.ts", "*.pw.ts"]
453
+ supported_actions:
454
+ - explain
455
+ - review
456
+ - investigate
457
+ base_confidence: 55
458
+ routing_rule: "Consult guides/browser-automation/README.md and existing Playwright surfaces before implementing browser-session workflows"
459
+
460
+ playwright-compress:
461
+ keywords:
462
+ korean:
463
+ - 플레이라이트 압축
464
+ - 브라우저 출력 압축
465
+ - ref 보존
466
+ - MCP 압축
467
+ english:
468
+ - "playwright compress"
469
+ - "browser output compression"
470
+ - "preserve refs"
471
+ - "mcp compression"
472
+ file_patterns: ["playwright.config.ts", "*.pw.ts"]
473
+ supported_actions:
474
+ - optimize
475
+ - compress
476
+ - review
477
+ base_confidence: 60
478
+ routing_rule: "Use the playwright-compress skill when Playwright MCP output is verbose and refs must remain actionable"
479
+
372
480
  # Managers (continued)
373
481
  mgr-gitnerd:
374
482
  keywords:
@@ -0,0 +1,46 @@
1
+ ---
2
+ name: playwright-compress
3
+ description: Compress verbose Playwright MCP output while preserving element refs and actionable browser evidence
4
+ scope: core
5
+ user-invocable: true
6
+ argument-hint: "[status]"
7
+ ---
8
+
9
+ # Playwright Compress
10
+
11
+ This skill documents the Codex-native pattern for shrinking verbose Playwright MCP output without destroying the references needed for follow-up interaction.
12
+
13
+ ## Purpose
14
+
15
+ - keep `ref=` tokens visible
16
+ - reduce repetitive browser snapshots and logs
17
+ - preserve URLs, errors, and key visible text
18
+ - complement runtime token controls instead of replacing them
19
+
20
+ ## Runtime Surface
21
+
22
+ The implementation lives in:
23
+
24
+ - `.codex/hooks/scripts/playwright-compress.sh`
25
+ - `.codex/hooks/hooks.json`
26
+
27
+ It runs on `PostToolUse` for Playwright MCP tools and returns `updatedMCPToolOutput` when the payload is large enough to benefit from compression.
28
+
29
+ ## Compression Policy
30
+
31
+ - Leave short outputs untouched.
32
+ - Preserve `ref=` tokens and URLs.
33
+ - Prefer high-signal lines over bulk DOM noise.
34
+ - Keep failure evidence verbatim where possible.
35
+ - Never send browser session secrets to external services.
36
+
37
+ ## Use Cases
38
+
39
+ - browser snapshot output is too large to keep in context
40
+ - a page contains many repeated nodes but only a few actionable refs
41
+ - follow-up tool calls need a compact view of visible evidence
42
+
43
+ ## Related References
44
+
45
+ - `guides/claude-code/14-token-efficiency.md`
46
+ - `guides/browser-automation/README.md`
@@ -0,0 +1,80 @@
1
+ ---
2
+ name: pre-generation-arch-check
3
+ description: Check planned code changes for architecture and responsibility violations before implementation
4
+ scope: package
5
+ argument-hint: "<change-request-summary>"
6
+ user-invocable: true
7
+ ---
8
+
9
+ # Pre-Generation Architecture Check
10
+
11
+ Review a requested change before code generation begins and warn about likely architecture violations.
12
+
13
+ This skill fills a gap between planning and implementation:
14
+
15
+ - `adversarial-review` focuses on attacker-minded risk after code exists
16
+ - `deep-verify` focuses on release-quality verification after code exists
17
+ - `pre-generation-arch-check` focuses on architecture hygiene before code is written
18
+
19
+ ## What It Checks
20
+
21
+ The skill looks for likely violations of:
22
+
23
+ - R006 separation of concerns
24
+ - compilation metaphor integrity
25
+ - wrong-layer ownership
26
+ - accidental orchestrator responsibility expansion
27
+ - speculative wrappers or abstractions that do not earn their cost
28
+
29
+ ## Inputs
30
+
31
+ Provide a short request summary, optionally including likely files or modules.
32
+
33
+ Examples:
34
+
35
+ ```text
36
+ /pre-generation-arch-check add a background sync service to updater.ts
37
+ /pre-generation-arch-check move routing logic into the agent file instead of the routing skill
38
+ ```
39
+
40
+ ## Output Contract
41
+
42
+ ### No concern
43
+
44
+ ```text
45
+ [ARCH-CHECK] CLEAR
46
+
47
+ Request appears consistent with current architecture.
48
+ ```
49
+
50
+ ### Warning
51
+
52
+ ```text
53
+ [ARCH-WARNING] Severity: MEDIUM
54
+ Boundary: routing vs agent definition
55
+ Concern: Request would move reusable routing logic into an agent artifact
56
+ Why: Violates compilation metaphor and R006 separation of concerns
57
+ Safer shape: Keep logic in a skill or routing layer; keep agent file declarative
58
+ ```
59
+
60
+ ## Heuristics
61
+
62
+ - warn when a request mixes skill logic with agent artifacts
63
+ - warn when orchestrator responsibilities expand into direct file-writing logic
64
+ - warn when a request introduces a new abstraction without a clear reuse or boundary win
65
+ - warn when a change smells like the wrong layer owns the behavior
66
+ - prefer concise warnings with one safer alternative
67
+
68
+ ## Integration
69
+
70
+ Use before:
71
+
72
+ - major refactors
73
+ - new workflow or routing features
74
+ - multi-file cross-layer changes
75
+
76
+ Good pairings:
77
+
78
+ - `pre-generation-arch-check` -> `deep-plan`
79
+ - `pre-generation-arch-check` -> `structured-dev-cycle`
80
+ - `pre-generation-arch-check` -> implementation
@@ -0,0 +1,63 @@
1
+ ---
2
+ name: product-strategy
3
+ description: YC-style product pressure test and scope framing for ideas, features, and workflow bets
4
+ scope: core
5
+ user-invocable: true
6
+ argument-hint: "<idea-or-feature>"
7
+ ---
8
+
9
+ # Product Strategy
10
+
11
+ Use this skill when a request needs product pressure, not immediate implementation. It borrows the useful part of the "office hours" pattern: force the conversation to answer hard product questions before work expands.
12
+
13
+ ## When To Use
14
+
15
+ - feature framing
16
+ - product tradeoff review
17
+ - CEO / founder style pressure test
18
+ - scope negotiation before implementation
19
+
20
+ ## Workflow
21
+
22
+ ### 1. State the bet
23
+
24
+ Write the feature or idea in one sentence:
25
+
26
+ - who it is for
27
+ - what changes for them
28
+ - why it matters now
29
+
30
+ ### 2. Run the six questions
31
+
32
+ Answer these before moving forward:
33
+
34
+ 1. What user pain becomes meaningfully smaller?
35
+ 2. Why will the user notice this quickly?
36
+ 3. What simpler alternative did we reject?
37
+ 4. What metric or behavior would prove this worked?
38
+ 5. What gets harder if we ship this?
39
+ 6. What would we deliberately not build in v1?
40
+
41
+ ### 3. Choose a scope mode
42
+
43
+ Assign one mode:
44
+
45
+ - `Expand` — increase ambition because the upside justifies it
46
+ - `Selective` — keep only the highest-signal slice
47
+ - `Hold` — wait for a prerequisite or stronger evidence
48
+ - `Reduce` — cut scope because the current ask is inflated
49
+
50
+ ### 4. Output contract
51
+
52
+ Return:
53
+
54
+ - problem statement
55
+ - strongest argument for shipping
56
+ - strongest argument against shipping
57
+ - chosen scope mode
58
+ - next 2-3 concrete actions
59
+
60
+ ## Related References
61
+
62
+ - `guides/browser-automation/README.md` for grounded product review through real browser flows
63
+ - `.codex/skills/deep-plan/SKILL.md` for implementation planning once the strategy is accepted
@@ -104,7 +104,7 @@ oh-my-customcodex로 구동됩니다.
104
104
  | 릴리즈 | `/pipeline auto-dev`, `/omcodex-release-notes`, `/release-plan` | 자동 개발, 릴리즈 노트 |
105
105
  | 리서치 | `/research`, `/scout`, `/deep-plan`, `/omcodex:agora` | 병렬 분석, URL 평가, 연구 계획 |
106
106
  | 메모리 | `/memory-save`, `/memory-recall` | 세션 메모리 관리 |
107
- | 시스템 | `/token-efficiency-audit`, `/omcodex:lists`, `/omcodex:status`, `/omcodex:help` | 토큰 효율 감사, 전체 목록, 상태, 도움말 |
107
+ | 시스템 | `/token-efficiency-audit`, `/pre-generation-arch-check`, `/omcodex:lists`, `/omcodex:status`, `/omcodex:help` | 토큰 효율/아키텍처 감사, 전체 목록, 상태, 도움말 |
108
108
 
109
109
  > 전체 커맨드 목록 (60+ 커맨드): `/omcodex:lists` 실행
110
110
 
@@ -115,7 +115,7 @@ project/
115
115
  +-- AGENTS.md # 진입점
116
116
  +-- .codex/
117
117
  | +-- agents/ # 서브에이전트 정의 (48 파일)
118
- | +-- skills/ # 스킬 (108 디렉토리)
118
+ | +-- skills/ # 스킬 (109 디렉토리)
119
119
  | +-- rules/ # 전역 규칙 (R000-R022)
120
120
  | +-- hooks/ # 훅 스크립트 (보안, 검증, HUD)
121
121
  | +-- contexts/ # 컨텍스트 파일 (ecomode)
@@ -118,6 +118,7 @@ NO EXCEPTIONS. NO EXCUSES.
118
118
  | `/optimize-report` | Generate optimization report |
119
119
  | `/research` | 10-team parallel deep analysis and cross-verification |
120
120
  | `/deep-plan` | Research-validated planning (research → plan → verify) |
121
+ | `/pre-generation-arch-check` | Check architecture risks before implementation |
121
122
  | `/omcodex:sauron-watch` | Full R017 verification |
122
123
  | `/structured-dev-cycle` | 6-stage structured development cycle (Plan → Verify → Implement → Verify → Compound → Done) |
123
124
  | `/omcodex:lists` | Show all available commands |
@@ -131,7 +132,7 @@ project/
131
132
  +-- AGENTS.md # Entry point
132
133
  +-- .codex/
133
134
  | +-- agents/ # Subagent definitions (48 files)
134
- | +-- skills/ # Skills (108 directories)
135
+ | +-- skills/ # Skills (109 directories)
135
136
  | +-- rules/ # Global rules (22 files)
136
137
  | +-- hooks/ # Hook scripts (security, validation, HUD)
137
138
  | +-- contexts/ # Context files (4 files)
@@ -118,6 +118,7 @@ oh-my-customcodex로 구동됩니다.
118
118
  | `/optimize-report` | 최적화 리포트 생성 |
119
119
  | `/research` | 10-team 병렬 딥 분석 및 교차 검증 |
120
120
  | `/deep-plan` | 연구 검증 기반 계획 수립 (research → plan → verify) |
121
+ | `/pre-generation-arch-check` | 구현 전 아키텍처 위험 점검 |
121
122
  | `/omcodex:sauron-watch` | 전체 R017 검증 |
122
123
  | `/structured-dev-cycle` | 6단계 구조적 개발 사이클 (Plan → Verify → Implement → Verify → Compound → Done) |
123
124
  | `/omcodex:lists` | 모든 사용 가능한 커맨드 표시 |
@@ -131,7 +132,7 @@ project/
131
132
  +-- AGENTS.md # 진입점
132
133
  +-- .codex/
133
134
  | +-- agents/ # 서브에이전트 정의 (48 파일)
134
- | +-- skills/ # 스킬 (108 디렉토리)
135
+ | +-- skills/ # 스킬 (109 디렉토리)
135
136
  | +-- rules/ # 전역 규칙 (22 파일)
136
137
  | +-- hooks/ # 훅 스크립트 (보안, 검증, HUD)
137
138
  | +-- contexts/ # 컨텍스트 파일 (4 파일)
@@ -0,0 +1,113 @@
1
+ # Browser Automation
2
+
3
+ This guide captures the browser-automation patterns that are useful in `oh-my-customcodex` without importing an external browser-control stack wholesale. It is intentionally pragmatic: keep the browser session real enough to validate user flows, but do not turn automation into a second product inside the harness.
4
+
5
+ ## Core Principles
6
+
7
+ ### 1. Prefer existing browser surfaces
8
+
9
+ Start from the browser tooling the repository already has:
10
+
11
+ - Playwright tests under `packages/serve/tests/`
12
+ - the repository Playwright config at `packages/serve/playwright.config.ts`
13
+ - the `playwright` skill and any existing MCP/browser surfaces
14
+
15
+ Do not add a separate browser orchestration system unless the current surfaces are clearly insufficient.
16
+
17
+ ### 2. Treat authenticated sessions as sensitive
18
+
19
+ Cookies, session storage, and browser profiles are credentials.
20
+
21
+ - Never commit cookies, storage state, or exported browser profiles.
22
+ - Keep imported cookies in ignored local files or ephemeral temp directories.
23
+ - Strip secrets from screenshots, logs, and copied traces before sharing them.
24
+
25
+ ### 3. Anti-bot measures are for resilience, not abuse
26
+
27
+ Use browser automation to validate real product flows and reproduce bugs. Do not optimize for adversarial scraping or abusive evasion.
28
+
29
+ Allowed patterns:
30
+
31
+ - realistic viewport and locale settings
32
+ - waiting for stable DOM state instead of brittle sleeps
33
+ - authenticated session reuse for testing flows behind login
34
+ - evidence capture for failures
35
+
36
+ Avoid:
37
+
38
+ - aggressive stealth plugins with unclear behavior
39
+ - retry storms against rate-limited or protected sites
40
+ - automation that bypasses product safeguards
41
+
42
+ ## Cookie And Session Handling
43
+
44
+ ### Importing cookies
45
+
46
+ When a flow requires an existing session:
47
+
48
+ 1. Export only the minimum cookies needed.
49
+ 2. Store them outside tracked files.
50
+ 3. Load them into a fresh browser context rather than a shared global context.
51
+
52
+ ### Isolate contexts
53
+
54
+ Use one browser context per scenario or per worker:
55
+
56
+ - prevents cross-test leakage
57
+ - makes failures reproducible
58
+ - keeps captured evidence attributable to one flow
59
+
60
+ ### Prefer storage state snapshots for repeatable tests
61
+
62
+ If a workflow is run often, promote manual cookie import into a reproducible storage-state fixture rather than redoing browser login ad hoc.
63
+
64
+ ## Evidence Capture
65
+
66
+ Browser automation is only useful if it leaves evidence behind.
67
+
68
+ Capture at least one of:
69
+
70
+ - screenshot on failure
71
+ - console logs
72
+ - network failures
73
+ - trace or HAR when the flow is flaky
74
+ - the exact page URL and visible state when an assertion fails
75
+
76
+ When summarizing evidence for the model, preserve reference tokens and URLs so follow-up steps can still target the right page elements.
77
+
78
+ ## Design And Strategy Workflows
79
+
80
+ ### Product strategy sessions
81
+
82
+ Browser automation is helpful when a product-strategy review needs to ground abstract questions in the actual product surface:
83
+
84
+ - what the first-time user sees
85
+ - where onboarding friction appears
86
+ - how many decisions a user must make before value
87
+
88
+ ### Design shotgun sessions
89
+
90
+ Use browser capture to compare alternatives consistently:
91
+
92
+ - same viewport
93
+ - same user state
94
+ - same content seed
95
+ - same evidence format
96
+
97
+ That keeps visual comparisons honest and makes "taste memory" reusable.
98
+
99
+ ## Operational Checklist
100
+
101
+ - Use an isolated browser context.
102
+ - Keep credentials out of tracked files.
103
+ - Capture evidence for every meaningful failure.
104
+ - Reuse existing Playwright surfaces before adding new tooling.
105
+ - Prefer stable selectors and deterministic waits over timing hacks.
106
+
107
+ ## Related Surfaces
108
+
109
+ - `.codex/skills/product-strategy/SKILL.md`
110
+ - `.codex/skills/design-shotgun/SKILL.md`
111
+ - `.codex/skills/playwright-compress/SKILL.md`
112
+ - `guides/web-scraping/README.md`
113
+ - `packages/serve/playwright.config.ts`
@@ -0,0 +1,20 @@
1
+ # Browser Automation Guide
2
+
3
+ metadata:
4
+ name: browser-automation
5
+ description: Browser automation patterns for authenticated sessions, cookie handling, and evidence capture
6
+
7
+ source:
8
+ type: internal
9
+
10
+ topics:
11
+ - authenticated-sessions
12
+ - cookie-import
13
+ - anti-bot-caution
14
+ - evidence-capture
15
+ - session-isolation
16
+
17
+ used_by:
18
+ - product-strategy
19
+ - design-shotgun
20
+ - playwright-compress
@@ -1,6 +1,6 @@
1
1
  # Token Efficiency Layers
2
2
 
3
- Token efficiency in oh-my-customcodex has three layers. They solve different problems and should not be mixed together blindly.
3
+ Token efficiency in oh-my-customcodex has four layers. They solve different problems and should not be mixed together blindly.
4
4
 
5
5
  ## Layer 1: Plugin-Level Protection
6
6
 
@@ -22,7 +22,19 @@ Use R013 ecomode and existing runtime guards when you want to compress active-se
22
22
 
23
23
  This layer changes how the session behaves while work is running.
24
24
 
25
- ## Layer 3: Settings-Level Optimization
25
+ ## Layer 3: Tool-Specific Compression
26
+
27
+ Use `playwright-compress` when the problem is not the whole session, but one extremely verbose browser tool result.
28
+
29
+ This layer is intentionally narrow:
30
+
31
+ - compress verbose Playwright MCP output after the tool succeeds
32
+ - preserve `ref=` tokens and URLs for follow-up interaction
33
+ - keep browser evidence actionable without keeping the full raw payload in context
34
+
35
+ This layer complements runtime compression instead of replacing it.
36
+
37
+ ## Layer 4: Settings-Level Optimization
26
38
 
27
39
  Use `/token-efficiency-audit` when you want configuration-level changes before the session burns tokens.
28
40
 
@@ -52,12 +64,14 @@ Typical settings-level levers:
52
64
  |------|------------|
53
65
  | Protect cache value across pauses | Layer 1 |
54
66
  | Compress runtime behavior in large sessions | Layer 2 |
55
- | Reduce baseline token spend from configuration | Layer 3 |
67
+ | Compress one noisy browser interaction | Layer 3 |
68
+ | Reduce baseline token spend from configuration | Layer 4 |
56
69
 
57
70
  Use layers together, but keep responsibilities separate:
58
71
 
59
72
  - plugin layer for cache and resume
60
73
  - runtime layer for in-session behavior
74
+ - tool-specific layer for noisy browser interactions
61
75
  - settings layer for pre-session defaults
62
76
 
63
77
  ## Tradeoffs
@@ -34,6 +34,12 @@ guides:
34
34
  origin: github
35
35
  url: https://github.com/vercel-labs/agent-skills
36
36
 
37
+ - name: browser-automation
38
+ description: Browser automation patterns for authenticated sessions, cookie handling, and evidence capture
39
+ path: ./browser-automation/
40
+ source:
41
+ type: internal
42
+
37
43
  # Languages
38
44
  - name: golang
39
45
  description: Go language reference from Effective Go
@@ -1,6 +1,6 @@
1
1
  {
2
- "version": "0.1.8",
3
- "lastUpdated": "2026-04-19T08:34:00.000Z",
2
+ "version": "0.2.0",
3
+ "lastUpdated": "2026-04-19T08:50:00.000Z",
4
4
  "components": [
5
5
  {
6
6
  "name": "rules",
@@ -18,13 +18,13 @@
18
18
  "name": "skills",
19
19
  "path": ".codex/skills",
20
20
  "description": "Reusable skill modules (includes slash commands)",
21
- "files": 108
21
+ "files": 112
22
22
  },
23
23
  {
24
24
  "name": "guides",
25
25
  "path": "guides",
26
26
  "description": "Reference documentation",
27
- "files": 38
27
+ "files": 39
28
28
  },
29
29
  {
30
30
  "name": "hooks",