메뉴
Pre-implementation spec check. Auto-invoke before building any feature on an existing system. Scans the project's specs directory, flags unimplemented specs in the same domain, blocks work until specs are acknowledged. Prevents reimplementing what's already been designed.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
The front door to the Pipeline Coordination system. One guided skill that doubles as installer + onboarder + meta-plan builder + first-handoff drafter + launcher. It scans a project's recent work for a goal and a candidate work-pile, sorts that pile WITH the operator, writes a coordination meta-plan PL and a first delegation handoff (HAN), installs the handoff-handling overlays into the create-note and pickup skills, teaches the three roles (orchestrator / coordinator / worker) in plain words, and prints exact launch instructions. Trigger on "meta-plan-init", "/meta-plan-init", "set up coordination", "set up the meta-plan", "bootstrap the pipeline coordination", "onboard me to the coordination system", "adopt my existing work into a meta-plan", or any request to stand up the coordinated-pipeline-execution layer for a project. Messy-work-adopt is the primary path; clean-start is the degenerate case.
Coordinator playbook for executing a delegation handoff issued by a meta-plan orchestrator. Auto-invoked by /pickup when it detects a delegation HAN (a `HAN - *.md` with `category: Handoff`, an `orchestrator_contact`, a `related_pl` pointing at a meta-plan, and `## Checkpoint log` + `## Clarification requests` sections) and this session is executing it. Also trigger when the operator says "coordinate this handoff", "I'm the coordinator", "run this HAN", "work the delegation". The coordinator is the top-level interactive instance the operator chats with: it stands up a workgroup of meta-plan-worker subagents, validates their deliverables, and posts LEAN progress to the HAN for the orchestrator. It does not own or edit the meta-plan.
Get oriented in the current project or Obsidian vault — read agent configs, guardrails, vault structure, and lessons learned. Use this skill at the start of any new session, after context compaction, when entering an unfamiliar project directory, or when the user says "orient", "get oriented", "what's the context here", "read the agents file", or "start up". Also trigger on /orient with no arguments. Even continued sessions count as new starts after compaction — always re-read the config chain.
Run a structured open-source landscape survey before designing or rebuilding a complex system. Six phases: bracket, discover (video + oracle + grounding doc), workspace (scratch clone), anchor read (manual, 1-2 closest peers), parallel deep-reads (team-dispatched), synthesis (single-worker comparative RE). Produces per-repo AREs + one comparative-analysis RE + grounding-doc cross-ref appendix; hands off to SD update and SPC drafting. Use whenever the user says "landscape survey", "deep-read these repos", "what should we borrow from X", "research before we spec", "evaluate candidates before the rebuild", "comparative source analysis", "what's the state of the art for [domain]", or invokes /landscape-survey. Also fires when the user points the assistant at a candidate set (a list of repos / libraries / approaches) and asks for a build plan before the SPC. The skill is the structural answer to "we built the system on marketing-page understanding and only discovered the failure mode after shipping."
Log work to the daily note AND project log. Use this skill when the user wants to record what they've been working on, says "log this", "log work", "add to worked on", "update the daily note", or wants to capture implementation progress. Always writes to both layers: daily note (human-readable) and PJL (agent-readable). Also trigger on "what did I work on" if the user wants to retroactively log work.
Load pickup documents (PICs) and resume work. Handles both single-PIC loading and full backlog triage. Use this skill when the user says "pickup", "pick up", "start of day", "what's on my plate", "what do I need to do", "get started", "load the pickup", "continue where I left off", "resume work", "triage pickups", "which pickups are easiest", "work through my pickups", "clear out pickups", "pickup backlog", "how many open pickups", "rank my pickups", "what's the quickest pickup to close", "batch my pickups", "group pickups by project", or points at a specific PIC document. Also trigger when the user opens a new session and says something like "ok what am I doing today" or "what was I working on".
| name | spec-guard |
| description | Pre-implementation spec check. Auto-invoke before building any feature on an existing system. Scans the project's specs directory, flags unimplemented specs in the same domain, blocks work until specs are acknowledged. Prevents reimplementing what's already been designed. |
| type | agent |
Before building anything on an existing system, verify no spec already governs the work. This skill fires BEFORE implementation, BEFORE writing code, BEFORE seeding data, BEFORE writing migrations.
Auto-invoke when ANY of these are true:
02_Projects/Do NOT invoke for:
Determine which project directory the work targets. Map from the code path or database schema to the vault project. The mapping is project-specific, so consult your vault's CLAUDE.md or project index for the canonical signals. A general heuristic:
| Signal | Likely project directory |
|---|---|
apps/<app>/ or <app>.* schema | 02_Projects/.../<app>/ |
services/<svc>/ | 02_Projects/.../<svc>/ |
Domain-specific subfolder (e.g. payments/, auth/) | Closest matching project dir |
If no project directory exists, skip to Step 4 (no specs possible).
2a. System Definitions (constitutional authority).
Glob: {project_dir}/**/SD - *.md
Glob: {vault_root}/02_Projects/**/SD - *.md (broader search if project-level finds nothing)
SDs define principles, not implementations. If an SD exists for the domain, read it first. Its principles constrain every spec and implementation beneath it. A spec that contradicts its governing SD is wrong; the SD wins.
2b. Product Definitions.
Glob: {project_dir}/**/PD - *.md
PDs define what a product does at the concept level. If a PD exists, it provides context the spec may have been written against.
2c. Specs.
Glob: {project_dir}/specs/**/*.md
Read the frontmatter of every spec found. Extract:
status: draft, reviewed, conditional, implemented, superseded# SPC - ... heading)Filter to specs that are NOT status: implemented or status: superseded. These are live design documents.
Reading order: SD first (for principles and constraints), then PD (for product context), then SPC (for implementation details). If the SD and SPC disagree, flag the disagreement to the user. The SD is authoritative for design principles; the SPC is authoritative for implementation specifics that don't contradict the SD.
For each live spec, check whether its title or purpose touches the same domain as your planned work. Use keyword overlap. Generic categories:
| Your work | Spec keywords that often match |
|---|---|
| Data ingest / import / seeding | import, ingest, audit, seed, pipeline |
| Content generation | content, generation, brief, corpus |
| Auth / login changes | auth, login, SSO, password, session |
| API endpoint changes | API, endpoint, route |
| UI component changes | component, page, view, dashboard |
| Data migration | migration, schema, table |
If ANY spec matches:
No matching specs found: Proceed with implementation. Log: "Spec guard: no governing specs found for [domain] in [project]."
Matching spec found, status = reviewed or conditional: HARD GATE. Present the spec's design to the user:
Do not proceed until the user responds. Do not silently deviate.
Matching spec found, status = draft: SOFT GATE. Present the spec but note it's a draft:
Matching spec found, your work contradicts the spec: HARD BLOCK. You cannot implement something that conflicts with a reviewed spec without user approval. Present the conflict clearly:
After the gate passes (either no specs found or user approved), log the result in your working context:
Spec guard: [PASS - no specs | PASS - spec acknowledged | PASS - user approved deviation]
Specs checked: [list of spec filenames scanned]
Governing spec: [name, or "none"]
This log survives in the conversation and can be referenced at closeout.