oh-my-customcode 0.178.0 → 0.180.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
- 49 agents. 116 skills. 23 rules. One command.
16
+ 49 agents. 117 skills. 23 rules. One command.
17
17
 
18
18
  ```bash
19
19
  npm install -g oh-my-customcode && cd your-project && omcustom init
@@ -132,13 +132,13 @@ Each agent declares its tools, model, memory scope, and limitations in YAML fron
132
132
 
133
133
  ---
134
134
 
135
- ### Skills (116)
135
+ ### Skills (117)
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
- | Workflow | 13 | structured-dev-cycle, deep-plan, research, evaluator-optimizer, dag-orchestration, worker-reviewer-pipeline, reasoning-sandwich, pipeline, and more |
141
+ | Workflow | 14 | structured-dev-cycle, deep-plan, research, evaluator-optimizer, dag-orchestration, worker-reviewer-pipeline, reasoning-sandwich, pipeline, fsd, and more |
142
142
  | Development | 8 | dev-review, dev-refactor, analysis, create-agent, intent-detection, web-design-guidelines, omcustom-takeover, skill-extractor |
143
143
  | Operations | 9 | update-docs, audit-agents, sauron-watch, monitoring-setup, fix-refs, release-notes, and more |
144
144
  | Memory | 3 | memory-save, memory-recall, memory-management |
@@ -270,7 +270,7 @@ your-project/
270
270
  ├── CLAUDE.md # Entry point
271
271
  ├── .claude/
272
272
  │ ├── agents/ # 49 agent definitions
273
- │ ├── skills/ # 116 skill modules
273
+ │ ├── skills/ # 117 skill modules
274
274
  │ ├── rules/ # 23 governance rules (R000-R023)
275
275
  │ ├── hooks/ # 15 lifecycle hook scripts
276
276
  │ ├── schemas/ # Tool input validation schemas
package/dist/cli/index.js CHANGED
@@ -241,7 +241,7 @@ var init_package = __esm(() => {
241
241
  workspaces: [
242
242
  "packages/*"
243
243
  ],
244
- version: "0.178.0",
244
+ version: "0.180.0",
245
245
  description: "Batteries-included agent harness for Claude Code",
246
246
  type: "module",
247
247
  bin: {
package/dist/index.js CHANGED
@@ -2031,7 +2031,7 @@ var package_default = {
2031
2031
  workspaces: [
2032
2032
  "packages/*"
2033
2033
  ],
2034
- version: "0.178.0",
2034
+ version: "0.180.0",
2035
2035
  description: "Batteries-included agent harness for Claude Code",
2036
2036
  type: "module",
2037
2037
  bin: {
package/package.json CHANGED
@@ -3,7 +3,7 @@
3
3
  "workspaces": [
4
4
  "packages/*"
5
5
  ],
6
- "version": "0.178.0",
6
+ "version": "0.180.0",
7
7
  "description": "Batteries-included agent harness for Claude Code",
8
8
  "type": "module",
9
9
  "bin": {
@@ -200,6 +200,19 @@ triage-dispatch.yml 실패 원인을 파일 Read 전에 "triaged 라벨 부재 +
200
200
 
201
201
  Origin: #1266 ④.
202
202
 
203
+ ### Proxy Signal vs Canonical Ground-Truth (#1336 ①②)
204
+
205
+ > Origin: #1336 ①② — transcription was alarmed as "stopped" because `.txt` files looked stale, but the canonical DB had transcripts current to 06-09 21:30 (.txt is not the whisper collector's output — it emits only to the DB). Separately, SMS was over-diagnosed as "fully blocked" from one empty OneDrive XML path + a single 401, while the DB held 17 SMS rows ingested via the app path.
206
+
207
+ When diagnosing pipeline/data state, verify the CANONICAL store (the authoritative datastore — DB, the system of record) BEFORE characterizing state from a secondary proxy (a `.txt`/file artifact) or a single ingestion path. Two failure modes share this meta-pattern:
208
+
209
+ | Anti-pattern | Required |
210
+ |--------------|----------|
211
+ | Characterize pipeline health from a filesystem proxy (`.txt` presence/mtime) | Query the canonical store (DB transcript count/recency) first |
212
+ | Generalize one ingestion path's failure (one empty XML / one 401) to "whole pipeline blocked" | Check the final landing store's count across ALL paths before concluding blockage |
213
+
214
+ A single path's failure does NOT prove the whole multi-path pipeline is down. Confirm the system-of-record before alarming or dispatching reprocessing.
215
+
203
216
  ### Directory-Context Before Multi-Copy Unification/Deletion
204
217
 
205
218
  다중 사본(동일 파일이 N곳에 존재)을 통일하거나 삭제하기 전, 각 사본이 위치한 **디렉토리 전체 맥락**을 확인한다(`ls`로 형제 파일 파악). 사본 파일 하나만 보고 "orphan"·"stub"으로 특성화하면, 같은 디렉토리의 형제 파일(다른 역할을 가진)이 함께 덮이거나 맥락이 누락된다. Read-Before-Characterize를 파일 단위에서 디렉토리 단위로 확장한 규칙이다.
@@ -256,6 +269,21 @@ A CI publish/deploy step that LOGS an error has NOT necessarily failed — the s
256
269
 
257
270
  This is the publish-domain extension of Read-Before-Characterize ("actual outcome ≠ attempt"). Re-running a publish that actually succeeded risks duplicate-publish errors; permanently changing a workflow on a misdiagnosis is worse (cf. #1217 — npm E403 misdiagnosed as a `--provenance` conflict → wrong workflow change → repeated failure; real cause was token scope).
258
271
 
272
+ ### State-Change Claim → Live System Verification (#1335 ①)
273
+
274
+ > Origin: #1335 ① — issue #101 (secretary teardown) was closed as "대체 완료·teardown 보류", but the secretary LaunchAgents (onedrive-bridge / calendar-worker / minikube-mount) were STILL running on the host. The user caught it ("secretary 리소스 다 내려가있는거 맞지?") — they were not.
275
+
276
+ Before closing or marking-done an issue/task that CLAIMS an infrastructure or resource STATE change (a service stopped, a resource torn down, a deployment removed, a process killed), verify the ACTUAL live system state — not just that the change command was issued. "Issued the teardown" ≠ "the resource is down".
277
+
278
+ | Claimed state change | Live ground-truth check |
279
+ |----------------------|-------------------------|
280
+ | LaunchAgent/service stopped | `launchctl list` / `systemctl status` shows it absent/inactive |
281
+ | k8s resource torn down | `kubectl get <resource>` returns NotFound |
282
+ | Container removed | `docker ps -a` does not list it |
283
+ | Process killed | process check (`pgrep`/`ps`) returns empty |
284
+
285
+ This is the infra/state extension of "actual outcome ≠ attempt". Closing on the command-issued assumption leaves orphaned running resources.
286
+
259
287
  ## Integration
260
288
 
261
289
  | Rule | Interaction |
@@ -192,3 +192,15 @@ The list form mirrors the tool-call `[N]` prefix pattern and scales better to 3+
192
192
  ✓ agent-1: success
193
193
  ✗ agent-2: failed (reason)
194
194
  ```
195
+
196
+ ## Parallel Feature Integration Gate
197
+
198
+ > Origin: #1335 ③ — parallel lang-kotlin-expert rounds each reported "build green", but the COMBINED runtime had a DataStore singleton crash, a Settings→Dashboard nav crash, a recording 400, and cursor pre-advance bugs — caught only by on-device testing.
199
+
200
+ Per-subagent "build green" does NOT guarantee integrated runtime correctness. When parallel feature subagents edit interdependent code, the orchestrator MUST run an INTEGRATION verification gate after the parallel work merges — a combined build PLUS a runtime/smoke check (or device test for apps) — before declaring the feature done. Independent green builds can still combine into runtime crashes (shared singletons, navigation, API contracts).
201
+
202
+ | Anti-pattern | Required |
203
+ |--------------|----------|
204
+ | Trust each parallel subagent's "build green" and declare done | Orchestrator runs a combined build + runtime/smoke gate on the merged result first |
205
+
206
+ Cross-reference: R020 (actual outcome ≠ attempt; completion verification).
@@ -70,6 +70,30 @@ Prefer a reversible action (disable/detach/stop) over delete when the goal can b
70
70
 
71
71
  > **Ask-before-scan (#1327 찐빠 #4)**: When a credential/token is needed, request it from the user BEFORE running BLIND/DISCOVERY credential scans (`env | grep`, repo-wide token greps), which trip the Credential Exploration classifier. Reading a SPECIFIC file the user named to obtain a value is not a discovery scan and is fine. If a scan trips the classifier, do not retry it (R010 Subagent Scope-Creep STOP Protocol).
72
72
 
73
+ ### Infra-Diagnostic File Checks — Metadata, Not Contents (#1334 ①)
74
+
75
+ > Origin: #1334 ① — during a hermes 502 diagnosis, a `cat .env` + `credentials.json` key inspect was reflexively bundled into a diagnostic batch and tripped the Credential Exploration classifier. The secret values were never needed for the 502 diagnosis.
76
+
77
+ When diagnosing infrastructure/health issues (502s, container state, env presence), file checks MUST use metadata-only commands — `ls -la` (existence, size, perms, mtime) — NEVER `cat .env`, `cat credentials.json`, or any command that reads secret CONTENTS or keys into the transcript. Confirming a file EXISTS is a metadata check; reading its values is a credential scan.
78
+
79
+ | Anti-pattern | Required |
80
+ |--------------|----------|
81
+ | `cat .env` / inspect OAuth/credential keys to "confirm config present" during a health diagnosis | `ls -la .env` — existence/size/perms only; request a specific value from the user if genuinely needed |
82
+
83
+ Cross-reference: the Ask-before-scan note above (discovery scans), R010 Subagent Scope-Creep STOP.
84
+
85
+ ### Standing User-Deny + Classifier Block → Immediate user-runs Switch (#1335 ④)
86
+
87
+ > Origin: #1335 ④ — with a standing user constraint "절대 시크릿 건드리지 마" plus a classifier block, an `.env.local` edit (DATABASE_URL, LLM_MAX_TOKENS) was retried and blocked repeatedly instead of handing the edit to the user.
88
+
89
+ When the user has a STANDING "don't touch X" constraint AND the safety classifier blocks an action on X even once, immediately switch to the `!` user-runs pattern — surface the exact command for the user to run themselves — and do NOT retry the blocked edit. A standing deny + one classifier trip is a hard signal to delegate to the user, not to find another path in.
90
+
91
+ | Anti-pattern | Required |
92
+ |--------------|----------|
93
+ | Retry a blocked edit on a user-deny-listed path via a different mechanism | Stop after the first block; emit the command for the user to run via `!` and wait |
94
+
95
+ Cross-reference: R010 Subagent Scope-Creep STOP Protocol (2-trip stop), R015 Failed Tool Re-Try Discipline.
96
+
73
97
  Cross-reference: R010 Subagent Scope-Creep STOP Protocol, R002 (permission tiers).
74
98
 
75
99
  ## Required Before Destructive Operations
@@ -21,6 +21,18 @@ Agent frontmatter `memory: project|user|local` enables persistent memory:
21
21
  | `project` | `.claude/agent-memory/<name>/` | Yes |
22
22
  | `local` | `.claude/agent-memory-local/<name>/` | No |
23
23
 
24
+ ## Subagent memory:project Source-Tree Pollution Guard
25
+
26
+ > Origin: #1335 ② — lang-kotlin-expert with `memory: project`, working in a Kotlin source subdirectory, wrote memory to `mobile/.../com/baekenough/secondbrain/.claude/agent-memory/` — INSIDE the source package. Caught and removed just before commit.
27
+
28
+ A subagent with `memory: project` working in a SUBDIRECTORY can create `.claude/agent-memory/` relative to its current working directory, polluting the source tree (e.g., inside a source package). Memory MUST resolve to the PROJECT ROOT `.claude/`, never a nested working dir.
29
+
30
+ | Anti-pattern | Required |
31
+ |--------------|----------|
32
+ | Accept a subagent's `.claude/agent-memory/` written under a source package | Verify memory writes land at project-root `.claude/`; remove any nested `.claude/agent-memory/` from source dirs before commit |
33
+
34
+ Check for nested `.claude/agent-memory/` (e.g., `find . -path '*/src/*/.claude' -o -path '*/main/*/.claude'`) before committing subagent work.
35
+
24
36
  ## Best Practices
25
37
 
26
38
  - Consult memory before starting work
@@ -0,0 +1,147 @@
1
+ ---
2
+ name: omcustom:fsd
3
+ description: Full Self Driving — autonomous release loop that processes all auto-dev-eligible GitHub issues until none remain, by repeatedly running /pipeline auto-dev then /homework.
4
+ scope: harness
5
+ user-invocable: true
6
+ argument-hint: "[<max-releases>]"
7
+ version: 0.1.0
8
+ effort: high
9
+ ---
10
+
11
+ # /omcustom:fsd — Full Self Driving
12
+
13
+ Autonomous release loop. Equivalent to running:
14
+
15
+ ```
16
+ /goal "모든 이슈가 처리될 때까지" /loop "/pipeline auto-dev -> /homework"
17
+ ```
18
+
19
+ This is a **thin alias / orchestrator skill**. It does not implement loop, issue-polling, release, or verification logic — it delegates entirely to existing skills.
20
+
21
+ ## Usage
22
+
23
+ ```
24
+ /omcustom:fsd # Run until all auto-dev-eligible issues are exhausted
25
+ /omcustom:fsd 3 # Optional: cap at N releases (default: unlimited)
26
+ ```
27
+
28
+ No arguments are required. The default behavior runs until the auto-dev-eligible issue set is empty.
29
+
30
+ ## What It Does
31
+
32
+ FSD expands into:
33
+
34
+ 1. **`/goal` wrapper** — applies disciplined goal-to-execution workflow:
35
+ - Objective: "모든 이슈가 처리될 때까지"
36
+ - Delegates planning, gap detection, and R020 completion verification to the `goal` skill
37
+ 2. **`/loop` recurrence** — self-paced loop (model decides cadence), each iteration runs:
38
+ 1. `/pipeline auto-dev` — full release pipeline for the next eligible issue
39
+ 2. `/homework` — retrospective 찐빠 audit gate
40
+
41
+ ### Loop Convergence
42
+
43
+ The loop converges naturally when the auto-dev-eligible issue set reaches 0. Issue eligibility follows `/pipeline auto-dev` label selection exactly:
44
+
45
+ - **Included**: `verify-ready` (preferred), unlabeled auto-dev candidates
46
+ - **Excluded**: `verify-done`, `needs-review`, `decision-needed` labels
47
+
48
+ Do NOT invent new label logic here — defer to the `pipeline` skill's auto-dev issue selection.
49
+
50
+ ### Iteration Flow (per iteration)
51
+
52
+ ```
53
+ [FSD Iteration N]
54
+ ├── /pipeline auto-dev → one release (PR create → merge → npm publish → milestone close)
55
+ ├── /homework → extract 찐빠, confirm gate (or --dry-run if requested)
56
+ └── Check: any eligible issues remain?
57
+ ├── YES → next iteration
58
+ └── NO → [FSD Done] converged naturally
59
+ ```
60
+
61
+ ## Safety and Discipline
62
+
63
+ Each iteration operates under full project rules — no relaxation because FSD is autonomous:
64
+
65
+ | Rule | Applies |
66
+ |------|---------|
67
+ | R001 (safety) | Destructive ops still require explicit approval. Credential guardrails always active. |
68
+ | R009 (parallel) | Independent subtasks within each pipeline iteration run in parallel. |
69
+ | R010 (orchestration) | All file modifications delegated to specialist subagents. mgr-gitnerd for git ops. |
70
+ | R017 (sync verification) | mgr-sauron passes required before any commit. |
71
+ | R020 (completion verification) | Each release verified via `npm view`, `gh release view`, closed issues before `[Done]`. |
72
+
73
+ `/homework` runs as a **retrospective gate** between iterations — findings go through `omcustom-feedback`'s Phase 4A confirmation gate. The loop does NOT skip homework on the grounds that it is "automated". If homework requires user confirmation (e.g., to file a feedback issue), the loop pauses and waits.
74
+
75
+ If a release operation triggers the safety classifier, the current iteration stops and surfaces the block to the user before continuing.
76
+
77
+ ## When to Use
78
+
79
+ | Scenario | Use FSD? |
80
+ |----------|----------|
81
+ | Multiple eligible issues ready to process autonomously | YES |
82
+ | Session where the user wants to "let it run" through the backlog | YES |
83
+ | Verifying the autonomous release loop pattern from session memory | YES |
84
+ | Single targeted issue fix | NO — use `/pipeline auto-dev` directly |
85
+ | Exploratory research / planning only | NO — use `/research` or `/deep-plan` |
86
+ | Only one issue and it needs human judgment | NO — use `/pipeline auto-dev` with manual oversight |
87
+
88
+ ## When NOT to Use
89
+
90
+ - When issues require stakeholder approval or design decisions before implementation
91
+ - When the issue set includes `decision-needed` or `needs-review` items only (loop converges immediately — just use `/pipeline auto-dev` once)
92
+ - When cost sensitivity is high and the issue backlog is large — inspect the eligible set first before running FSD
93
+
94
+ ## Optional Release Cap
95
+
96
+ Pass a numeric argument to cap at N releases:
97
+
98
+ ```
99
+ /omcustom:fsd 3 # Process at most 3 issues this FSD run
100
+ ```
101
+
102
+ This corresponds to the `-max` parameter used in the manual pattern. Default is unlimited (run until eligible issues exhausted). The cap is advisory — the pipeline itself may stop earlier if the eligible set runs out before the cap is reached.
103
+
104
+ ## Session 114 Precedent
105
+
106
+ This skill was extracted from the manual pattern used in Session 114 (2026-06-09):
107
+
108
+ ```
109
+ /goal "모든 이슈가 처리될 때까지" /loop "/pipeline auto-dev -> /homework"
110
+ ```
111
+
112
+ That session ran 2 iterations (v0.177.0 and v0.178.0) before converging with 0 eligible issues remaining. FSD codifies this pattern as a first-class invocable command.
113
+
114
+ ## Cross-References
115
+
116
+ | Skill / Rule | Role |
117
+ |--------------|------|
118
+ | `goal` | Disciplined goal-to-execution wrapper — objective parse, gap detection, R020 verification |
119
+ | `omcustom-loop` | Session auto-continuation via SubagentStop hook — keeps the loop alive during background agent work |
120
+ | `pipeline` | `/pipeline auto-dev` — the core release pipeline per iteration |
121
+ | `homework` | Retrospective 찐빠 audit gate per iteration |
122
+ | R001 (safety) | Destructive ops require approval; credential guardrails |
123
+ | R009 (parallel execution) | Parallel subtasks within each pipeline iteration |
124
+ | R010 (orchestrator coordination) | All file writes delegated; mgr-gitnerd for git |
125
+ | R017 (sync verification) | mgr-sauron required before commit/push |
126
+ | R020 (completion verification) | Actual outcome verified before declaring each release done |
127
+
128
+ ## Design Notes
129
+
130
+ This skill is intentionally a **thin alias**. It does NOT duplicate:
131
+ - Issue polling logic (owned by `pipeline`)
132
+ - Loop cadence / auto-continuation (owned by `omcustom-loop` + SubagentStop hook)
133
+ - Release pipeline steps (owned by `pipeline auto-dev`)
134
+ - Retrospective analysis (owned by `homework`)
135
+ - Completion verification (owned by R020 + `goal`)
136
+
137
+ If any of those underlying skills evolve, FSD automatically benefits — its only responsibility is declaring the intent and forwarding to the right components.
138
+
139
+ ## Permission Mode Note
140
+
141
+ When this skill delegates work via Agent tool calls, ALL Agent tool calls MUST include `mode: "bypassPermissions"` per R010 Universal bypassPermissions.
142
+
143
+ ## Artifact Output
144
+
145
+ Artifacts from each iteration follow the conventions of the constituent skills:
146
+ - Pipeline artifacts: `.claude/outputs/sessions/{YYYY-MM-DD}/pipeline-auto-dev-{HHmmss}.md`
147
+ - Homework artifacts: `.claude/outputs/sessions/{YYYY-MM-DD}/homework-{HHmmss}.md`
@@ -168,6 +168,17 @@ If `--dry-run` is active, skip this phase and output the draft directly to the c
168
168
  └── 다음 액션: {harness 제안 있으면 표시, 없으면 "없음"}
169
169
  ```
170
170
 
171
+ ## Cross-Project Import Compatibility
172
+
173
+ When `homework` is imported into a project OTHER than oh-my-customcode, its automatic `omcustom-feedback` invocation (the retrospective-filing phase) depends on `omcustom-feedback` being model-invocable in that project.
174
+
175
+ | Condition | Behavior |
176
+ |-----------|----------|
177
+ | `omcustom-feedback` model-invocable (default in oh-my-customcode) | Auto-invoke files the retrospective normally |
178
+ | `omcustom-feedback` has model invocation DISABLED (`disable-model-invocation`) in the importing project | Auto-invoke FAILS — fall back to MANUAL submission: present the drafted findings to the user and ask them to file the feedback (or run `omcustom-feedback` manually) |
179
+
180
+ > Origin: #1336 — in the second-brain project, `omcustom-feedback` was model-invocation-disabled, so homework Phase 5's automatic invoke failed; the retrospective was filed manually. Document this dependency so cross-project imports degrade gracefully instead of silently failing the auto-file step.
181
+
171
182
  ## Options Reference
172
183
 
173
184
  | Option | Default | Description |
@@ -116,7 +116,7 @@ project/
116
116
  +-- CLAUDE.md # 진입점
117
117
  +-- .claude/
118
118
  | +-- agents/ # 서브에이전트 정의 (49 파일)
119
- | +-- skills/ # 스킬 (116 디렉토리)
119
+ | +-- skills/ # 스킬 (117 디렉토리)
120
120
  | +-- rules/ # 전역 규칙 (R000-R023)
121
121
  | +-- hooks/ # 훅 스크립트 (보안, 검증, HUD)
122
122
  | +-- contexts/ # 컨텍스트 파일 (ecomode)
@@ -1,5 +1,5 @@
1
1
  {
2
- "version": "0.178.0",
2
+ "version": "0.180.0",
3
3
  "lastUpdated": "2026-05-20T00:00:00.000Z",
4
4
  "omcustomMinClaudeCode": "2.1.121",
5
5
  "omcustomMinClaudeCodeReason": "Sensitive-path direct Write/Edit on .claude/** under bypassPermissions (R010 deprecation, #1101)",
@@ -20,7 +20,7 @@
20
20
  "name": "skills",
21
21
  "path": ".claude/skills",
22
22
  "description": "Reusable skill modules (includes slash commands)",
23
- "files": 116
23
+ "files": 117
24
24
  },
25
25
  {
26
26
  "name": "guides",