oh-my-project

A summative gate that mechanically checks a project folder against .omp/rules.json and manifest.json — it judges structure violations, naming violations, dataset checksum drift, split leakage, and lineage/orphan integrity as read-only PASS/FAIL. The "CI" of code. Evidence-based only (fresh hashes, grep, tree walk); no critique, no advice, no self-correction. It does not fix violations directly — it only hands them off as lists to the organizer (moves) and dataset-curator (re-registration). Triggers: 감사해줘, 규칙 준수 확인, audit, 위반 검사, PASS 판정, 체크섬 확인, drift 검사, split 누수, 구조 위반 찾아, omp audit, 규칙 어긴 거 찾아, 게이트 확인

Pull-style briefing — regenerates `.hq/config/project/secretary/BRIEF.md` from current ledger/todo/raid/journal state: traffic light, state-of-play, top-5 tasks, open blockers, a next-session goal suggestion, and decision paths. Every number is `derive_status(root)` output quoted verbatim — never an LLM-authored count or percentage (D8). Gated by `brief_hash_check`: a hand-edited BRIEF.md STOPs regeneration instead of silently overwriting it. Triggers: 브리핑, 어디까지 했지, 현황, 다음 뭐하지, 상태 보고, brief, status, what's the status, where did I leave off, what's next, give me a briefing

The management stage that codifies and updates structure/naming rules — writes rules.json (machine) + STRUCTURE.md/NAMING.md (human) together in one pass to prevent drift. Takes the existing .hq/config/project/rules.json as input, has rule-architect propose changes, and any rule change (a heavy decision that triggers file moves) must pass a human approval gate. Not a generation pipeline but a loop that updates a living .hq/ — rules are only proposed; the human gates enforcement. Triggers: 규칙 성문화, 규칙 갱신, codify, 구조 규칙 정리, 명명 규칙 정리, rules 갱신, STRUCTURE 갱신, NAMING 갱신, 규칙 바꿔, 폴더 규칙 명문화, codify rules, update rules, organize structure rules, organize naming rules, change rules, formalize folder rules

dataset registration and tracking — records each data file's SHA-256 (hashlib), size, rows, split, and lineage in `.hq/config/project/manifest.json` and refreshes the human-readable `.hq/config/project/DATASETS.md` catalog. Metadata-only: never copies, moves, or pushes the actual data; it only tracks "has it changed / where did it come from / is there leakage". On detecting DVC/git-lfs it does not claim ownership but delegates (mirrors metadata only). Triggers: dataset 등록, 데이터셋 추적, 체크섬, SHA256, manifest 갱신, split 추적, lineage, register dataset, track dataset, data inventory, train val leakage, 데이터 카탈로그

Human-facing project documentation generation and refresh — writes or updates the human-readable .md files like `.hq/community/PROJECT.md`·`STRUCTURE.md`·`NAMING.md`·`DATASETS.md`, grounded in the project-scanner inventory. It absorbs the "read the codebase and produce professional documentation" spirit of readme-project, but omp centers on the `.hq/` docs rather than the repo root — the output is knowledge *about* the project, not the project itself. Reflects only the actual tree, no guessing. omp stage 4. Triggers: 문서 갱신, PROJECT.md 써줘, 프로젝트 문서, 개요 정리, STRUCTURE.md 갱신, 폴더 설명 써줘, document the project, update project docs, write PROJECT.md, refresh .omp docs

omp installation/prerequisite self-diagnosis — checks hook registration, python3 availability, and the presence of reference cards to report "is omp ready to work in this environment" as PASS/WARN/FAIL. Unlike omp-audit, which *assumes the store already exists* and inspects rule compliance, doctor looks at the installation layer that comes before that (it does NOT perform the rules.json schema validation that overlaps with audit). read-only, no auto-fix. Triggers: omp 진단, doctor, 설치 점검, omp 작동 확인, 왜 안 되지, hooks 확인, omp-doctor, 설정 점검, 환경 점검, omp 안 돼, omp diagnose, install check, verify omp works, why isn't it working, check hooks, settings check, environment check, omp broken

The environment asset stage that generates and manages Dockerfile/compose canonical files into .hq/config/project/env/ — enforcing a generation gate (dry-run diff → human approval → write → disk verify), personal-value resolver (.env/${VAR} substitution, never hardcode), and a strict not-a-build-runner boundary (omp proposes commands, the user executes them). docker_naming rules are delegated to omp-codify; docker_images inventory to omp-dataset. Generation observations auto-accumulate to .hq/community/wiki/docker-*.md; rule promotion goes through omp-learn's human gate. Triggers: docker 환경 만들어, dockerfile 생성, compose 생성, 환경 자산, omp env, provision env, docker scaffold, 도커 환경, 도커파일, compose 파일 생성, env stage, generate dockerfile, generate compose, docker asset, 환경 파일 만들어

Periodic documentation gardening — sweeps the project's prose for cited paths that no longer exist on disk, counts how many sweeps each finding has survived, and escalates the ones nobody acted on. Report-only: it never edits a document and never deletes anything. omp ships no scheduler; a human makes it periodic with Claude Code's own `/loop` or `/schedule`. Triggers: 문서 정원, 낡은 문서 찾아, 문서 드리프트, 경로 드리프트, 문서 청소, 죽은 경로, 문서 관리 스윕, garden, doc drift, stale docs, dead paths in docs, documentation sweep, tend the docs

위임 직전 1회 실행하는 브리핑 조립기 — 형제 하네스(oms·omd·omx·omc·superpowers 등)에 작업을 맡기기 전, 이 프로젝트에 대한 지식을 Anthropic multi-agent 4요소 패킷(Objective / Output format / Tool·source guidance / Boundaries)으로 조립해 전수한다. 세션 내 브리핑 블록 + 감사용 `.hq/work/project/handoffs/YYYY-MM-DD-<target>.md` 사본 + ledger `handoff_prepared` 이벤트, 세 산출물을 한 pass 에서 만든다. 참조만 담고 원문 전체를 복붙하지 않는다. Triggers: 위임 브리핑, 인수인계, 맡기기 전 브리핑, 형제 하네스에 넘겨, handoff, delegation briefing, brief the sibling, hand off to, prepare a briefing

One-time bootstrap — inductively scans a project folder, matches the best-fitting preset, and **synthesizes** the entire `.hq/` SSOT (PROJECT/STRUCTURE/NAMING/DATASETS.md + rules.json/manifest.json + learned.md + wiki/). The draft rules.json is finalized only after a human approval gate — starts generic and immediately becomes a starting point specialized to this project. If the omp store already exists (a parseable `.hq/.anchor` or a legacy `.omp/`), it warns "re-initialize?" and stops. Triggers: omp 초기화, 프로젝트 초기화, .omp 만들어, init, 부트스트랩, 폴더 스캔해줘, 이 프로젝트 파악해, 프로젝트 세팅, omp init, project init, initialize project, scan this folder

Observation → rule promotion (omp's core evolution gate) — rule-architect reviews the observations accumulated in `.hq/config/project/learned.md` during operation plus the auto-accumulated patterns in `.hq/community/wiki/`, and judges which of them qualify to be promoted into `rules.json` rules. The heavy channel (rules) must always pass a human approval gate, and each promotion raises rules.json's specificity, advancing "generic → specialized to this project" by one notch. No auto-promotion — the human breaks the gate. Triggers: 학습 반영, 규칙 승격, 관찰 정리, learned 검토, 패턴 굳혀, 이거 규칙으로, omp learn, promote observation, learn rules, specificity 올려, 진화 게이트

Universal capture router for the secretary axis — one entry point, five destinations. Routes an event/attempt/failure narrative to journal/, a to-do to todo.txt, a blocker/risk to raid.md, a recurring decision to decisions/ (ADR), and a structure/naming observation to the existing learned.md channel (this skill never intercepts that lane). Single chronicler dispatch, redact before write, ledger event per write via hooks/omp_secretary.py. Triggers: 기록해줘, 오늘 한 거, 막힌 거, 결정 기록, 블로커, journal, log this, todo 추가, 할 일 기록, 리스크 기록, 결정 남겨, 일지 써줘

Rule-violation detection → safe relocation — the auditor detects violations against .hq/config/project/rules.json, and the organizer moves files via the mv→verify→delete safety protocol. Human approval + dry-run enforced before any move. Detection (auditor read-only) ≠ execution (organizer write) separation. The only stage that moves files. Triggers: 정리해줘, 규칙대로 정리, 재배치, 파일 옮겨, 위반 정리, 폴더 정리, organize, reorganize, move files, 제자리에 놓아줘, 어긋난 파일, tidy up

Point at one project folder → full `.hq/` SSOT orchestration. If no omp store exists yet (neither `.hq/.anchor` nor a legacy `.omp/`), absorb init (scan → inductive + preset synthesis → draft rules.json → human gate) to bootstrap, then weave the codify → organize → dataset → doc management loop with a user confirmation at every gate. The project-management counterpart of OMC autopilot — not a generation pipeline but a loop that updates a living `.hq/`. Supports `--from <stage>` re-entry. Triggers: 이 프로젝트 정리해줘, 폴더 통째로 관리, 프로젝트 셋업, .omp 만들어줘, omp 부트스트랩, project pilot, manage this project, end to end 프로젝트, 알아서 정리해줘, omp pilot

Weekly (or on-demand) re-evaluation of the secretary axis — BuJo-style migration for every open todo.txt task (migrate/strike/done, human-judged per item, never auto-carried-over), a `scan_stale` sweep (stale task/blocker, BRIEF drift, sync-conflict copies), a `raid.md` reconfirmation pass (still valid? human closes only), a `scan_journal_tags` tally that *presents* repeated [LESSON:]/[BLOCKER:] tags as wiki-promotion candidates without promoting them, and a closing recommendation to run `omp-brief`. Triggers: 주간 리뷰, 정리하자, 리뷰 돌려, migration, weekly review, 재평가, 이번 주 리뷰, todo 정리, stale 스캔, review todo, weekly cleanup

The stage that induces a project's implicit CODE idioms from its existing source and turns them into machine-checkable rules — in-file declaration order, state/flag naming, where cross-cutting utilities live, and error/logging shape. Reads the code that is already there, proposes `content_conventions[]` entries with code globs (the same axis omp-audit already verifies deterministically), and hands the write to omp-codify. Detection only — it never writes rules.json itself and never edits source. Exists because an agent dropped onto a hand-written legacy codebase imposes its pretrained mainstream idiom unless the house style is written down first. Triggers: 코드 스타일 성문화, 관용구 규칙, 우리 코드 스타일대로, 스타일 드리프트, 레거시 스타일 상속, 코드 컨벤션 정리, 기존 코드 스타일 파악, omp style, code idiom, code conventions, inherit legacy style, style drift, house style, codify code style