Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add bunhine0452/Ocul-PM --skill project-inceptiongit clone --depth 1 https://github.com/bunhine0452/Ocul-PMWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/bunhine0452/ocul-pm/project-inception)<a href="https://agentmods.dev/skills/bunhine0452/ocul-pm/project-inception"><img src="https://agentmods.dev/badge/skills/bunhine0452/ocul-pm/project-inception/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/bunhine0452/ocul-pm/project-inception"><img src="https://agentmods.dev/badge/skills/bunhine0452/ocul-pm/project-inception.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00085 | $0.01863 |
| Opus 5 | $0.00043 | $0.00932 |
| Sonnet 5 | $0.00017 | $0.00373 |
| Haiku 4.5 | $0.00009 | $0.00186 |
Grade A, and why
project-inception scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 65 lines — stays where its author put it; the contents beside it link to each section on GitHub.
project-inception — 아이디어를 설계 산출물로
새 프로젝트(또는 새 기능 영역)를 시작할 때, 아이디어를 ocul-pm 파일 체계에 그대로 물리는 4종 산출물로 바꿉니다. 성공 기준은 문서를 "만드는 것"이 아니라 — 기존 도구가 무수정으로 소비하는 것입니다 (discussion→플래너 승격, EVALS→회고 추이, rules→에이전트 자동 로드).
STAGE 0 — 문제 파악 (리서치 방향을 정할 만큼만)
.oculpm/ 이 없는 새 저장소라면 먼저 사용자에게 "이 프로젝트를 ocul-pm 으로 추적할까요?" 를 물어보고, 동의를 받으면 project_init 도구(confirm=true)로 초기화합니다 — 동의 없이/선제적으로 호출하지 않습니다. 도구가 없으면 ocul-pm 앱에서 프로젝트 추가를 안내하세요.
정보가 부족한 채 계획을 지어내지 마세요. 단, 여기서는 리서치의 방향을 정하는 데 필요한 최소만 묻습니다 — 문제(누구의 어떤 문제), 완성의 정의(첫 데모 한 장면), 비목표, 플랫폼·강한 제약(기한·오프라인·보안). 아이디어에 이미 담긴 것은 다시 묻지 않습니다. 답을 받아 .oculpm/agents/discussion-spec.md 규격대로 .oculpm/discussion/<slug>/discussion.md 를 만들고 ## 문제 정의 를 채웁니다.
STAGE 1 — 환경 탐색 (웹 리서치)
사용자에게 더 묻기 전에, 웹 검색(WebSearch/WebFetch)으로 환경을 직접 조사합니다. 문제에 맞는 후보 스택 2~3개에 대해:
- 현재 안정 버전과 권장 조합 (프레임워크 + 빌드 도구 + 테스트 러너)
- 공식 스캐폴드 명령·battle-tested 보일러플레이트
- 해당 도메인의 표준 라이브러리·베스트 프랙티스·흔한 함정
- 필요한 개발 환경 (런타임 버전, 패키지 매니저, 필수 CLI)
조사 결과를 discussion 의 ### 방안 {#opt-id} 후보안에 버전·출처와 함께 기록합니다. 기억 속 버전을 단정하지 말 것 — 검색으로 확인한 것만 적습니다.
STAGE 2 — 대화로 최적 사양 확정
리서치 근거를 들고 사용자와 대화해 사양을 함께 확정합니다. 질문은 기능
나열이 아니라 제품 렌즈로 팝니다 — 누가 쓰는가, 어떤 가치 가설인가, 안
만들면 사용자는 뭘 하는가(비사용 대안), 성공을 무엇으로 알아보는가. 남은 미결(선호 언어·프레임워크, 규모, 비용 허용치, 기존 자산)을 리서치가 뒷받침하는 객관식으로 한 번에 묻습니다 — "무엇을 쓸까요?"가 아니라 "A(버전·근거) vs B(버전·근거), 이 상황엔 A 추천"처럼. 모호한 답은 재질문하고, 추측으로 메꾸지 않습니다. 사용자가 방안을 고르면 ## 결론 을 쓰고 status 를 resolved 로. 증거
게이트: 결론·계획의 모든 주장에는 근거(조사 출처·사용자 답변·측정)를
병기합니다 — 근거 없는 수식어("빠르고 확장 가능한")는 쓰지 않습니다.
STAGE 3 — 계획 (plan_create, 3-depth 로 매우 자세히)
결론을 3-depth 계획으로: plan_create MCP 도구로 phases(마일스톤) → items(작업) → children(하위 작업, 1단계)을 만듭니다. 구현이 이 계획을 따라가므로 자세할수록 좋습니다 — 리프는 반나절 이하 단위의 "검증 가능한 동사구"("로그인"이 아니라 "이메일 로그인 happy-path 가 동작한다"), 구현 순서대로 배열하고, 리프마다 확인 방법을 항목 문구에 담습니다 — 실행할 명령(테스트/빌드) 또는 재현 시나리오가 문구에서 읽혀야 /oculpm:next 가 완료 기준으로 씁니다. Phase 1 의 첫 항목은 "리서치에서 확정한 버전으로 환경 구성·스캐폴드". 도구가 없으면 AGENTS.md §4 의 폴백 규격으로 직접 작성.
STAGE 4 — 완료 정의 (EVALS.md)
프로젝트 루트에 EVALS.md 를 만듭니다: 결론의 "완성의 정의"를 실행/재현 가능한 평가 항목(체크리스트/시나리오)으로 옮기고, 맨 아래에 기록 표를 둡니다:
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 65 lines · 85 tokens per session scan A c18a1507ef2b
project-inception is a skill published in the GitHub repository bunhine0452/Ocul-PM (7 stars, last pushed 2d ago), licensed MIT. It adds 85 tokens to every session and 1,863 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
agentbro-pr-merge
Use when reviewing, fixing CI for, approving workflows for, or merging AgentBro pull requests into dev/main, especially external contributor PRs where contributor attribution matters.
linear
Manage issues, projects & team workflows in Linear. Use when the user wants to read, create or updates tickets in Linear.
product-strategy
A product-planning guide for evaluating requirements, users, scope, priorities, roadmaps, and success measures. It ties proposals to user problems, business value, boundaries, and signals that can be checked.
pm-long-horizon-planning
Audit long, complex, and potentially inconsistent PM taskbooks and compile them into one self-contained, semantically validated Product Brief with a requirement ledger, WP dependency graph, budgets, absolute schedule, gates, tests, experiment evidence, risks, recovery, and stop conditions. Use for long-horizon or…
pm-product-requirements
Turn vague ADMIN requests, chat feedback, screenshots, and workflow complaints into scoped CodeFlowMu product requirements. Use when PM needs PRD-style clarification, user stories, goals, non-goals, constraints, risks, or task input while preserving FCoP boundaries.
pm-acceptance-criteria
Convert "done" into checkable CodeFlowMu acceptance criteria. Use before PM dispatch, PM review, QA verification, or ADMIN closure to define functional, file, behavior, evidence, and forbidden-item checks.