메뉴
{{customDescription}}
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Goal-driven taste-writing studio. The user arrives with a concrete writing goal — "write something about X", "make this read less AI" — and you drive a human-in-the-loop, no-gradient search toward prose they recognize as theirs: not one-glance-AI, and still readable. You generate across model families, the user judges, and every judgment distills into plain-text taste artifacts. Triggers when the user wants to write or rewrite a piece so it fits their own voice rather than generic AI register. The entry is always a writing goal — never "let me set up my taste."
Project-context awareness — multi-session workflows around one topic, shared materials and preferences, and cross-mode handoffs as a high-value user path.
Paper-canvas web design. Edit HTML/CSS/JS; viewer renders your content as a single paper sheet at the size locked at workspace creation. Design language adapted from tw93/kami (MIT). Triggers when the user mentions 纸张排版, 一页纸, 简历, 作品集, 白皮书, 正式信件, "make a resume", "portfolio", "one-pager", "white paper", "letter", "typeset this".
Rewrite the active Pneuma session's UI title + one-line summary so the launcher and ProjectPanel rows reflect what the session is actually about. Use this skill whenever the user asks to "整理 / 概括 / refresh / re-title / summarize this session", whenever the conversation has produced substantive work and the default title ("WebCraft session") is now uninformative, or before the user pauses a long session — the next time they reopen it, the row needs to say more than "<pneuma:env reason='opened'>". Cheap to run, persistent across reopens, mode-agnostic.
Author a new Pneuma mode end-to-end — manifest + viewer + skill + seed + showcase. Use this skill whenever the user says they want to create a new mode, fork an existing one for a different domain, scaffold mode files, design a new viewer, or asks "how should I build a mode for X". Walks the user through a discovery interview, produces a design brief that names every key choice (Source kind, ViewerAddress vocabulary, action space, seed strategy, external integrations, evolution directive), and only then generates the directory skeleton. Encodes the practice rules pulled from webcraft / slide / diagram / illustrate / remotion / kami. Pneuma Skills project only; Claude Code only.
AI-orchestrated video production on @pneuma-craft. Use whenever the user wants to generate, edit, or compose video clips, audio tracks, captions, or background music — including text-to-video / image-to-video generation, TTS narration, music generation, provenance tracking, and timeline composition. Trigger on phrases like "generate video", "make a clip", "add narration", "try another take", "add BGM", "edit project.json", "place on the timeline", "AIGC assets", "regenerate this shot", or any request that touches the exploded timeline or the dive-in panels. Also use when editing `project.json` by hand, registering assets, or wiring provenance edges. Do not assume the user knows the schema — they usually don't; read `references/project-json.md` before committing to an edit.
| name | obsidian-knowledge |
| description | {{customDescription}} |
Every session starts from zero context. But the user has been thinking about these topics for weeks, months, sometimes years — and that thinking lives in their Obsidian vault. Notes, bookmarks, project docs, design decisions, research findings. When you search the vault before starting work, you're not just gathering information — you're respecting the context the user has already built, and producing output that fits into their existing mental model rather than a generic one.
The difference between good and great output is often grounding: the same presentation about "AI agent sandboxes" is dramatically better when it references the specific project the user bookmarked last month, uses their terminology, and connects to their existing knowledge graph.
Search when the answer might already exist in the user's own words:
When a search returns nothing, that's fine — proceed with your own knowledge. The point is to check, not to force-find.
All endpoints use the Pneuma server's base URL.
Search — find notes by keyword:
POST /api/plugins/obsidian-memory/search
Body: { "query": "search terms", "limit": 5 }
→ { results: [{ entry: { path, title }, score, snippet }] }
Read — get full content of a note:
GET /api/plugins/obsidian-memory/read/{path}
→ { entry: { path, title, content } }
Write — create or update a note (only when user asks):
POST /api/plugins/obsidian-memory/write
Body: { "path": "folder/file.md", "content": "...", "tags": ["..."] }
Status — check availability (call once per session):
GET /api/plugins/obsidian-memory/status
→ { available: true/false }
Search → Read: Search returns paths and snippets. If a snippet looks relevant, read the full note. One search + one read is the typical flow.
Cite casually: "I found a note in your vault about X" — not formally, not with full paths.
Don't over-search: One or two searches per topic. No results = the user doesn't have notes on this, move on.
Write sparingly: Only when the user explicitly asks to save something to their vault.
{{customGuidance}}