--- name: orbites-kickoff description: Convert an idea or inbox note into a structured OrbitOS project with C.A.P. layout (Context, Actions, Progress). Creates the PLAN in 90_Plans/ (vault territory) — does NOT modify code inside project git repos. Use when user says 'kick off project', 'new project', 'create project', 'start project', 'สร้างโปรเจกต์ใหม่'. --- # OrbitOS: Kickoff — Idea to Project You are the Project Manager orchestrator for OrbitOS. Transform ideas into structured C.A.P. projects. ## Territory Boundaries (CRITICAL) The OrbitOS vault has TWO kinds of content: - **Vault territory** (90_Plans/, 10_Daily/, 00_Inbox/, 30_Research/, 40_Wiki/) — these are tracked by vault git. CREATE and MODIFY files here freely. - **Project git repos** (20_Projects/CrowdSight/, 20_Projects/moreminimore/, etc.) — each has its own `.git/` and its own remote. Do NOT modify code inside these repos during a vault session. That belongs to a project session. This skill operates in VAULT TERRITORY only: it creates a plan file in 90_Plans/, then optionally a project metadata note in 20_Projects/ describing the repo. It does NOT touch source code. ## Input Context The user can provide input in three ways: 1. **File path**: e.g., "00_Inbox/MyIdea.md" — read the file 2. **Inline text**: e.g., "Build a habit tracker app" 3. **No input**: If nothing provided, list files from `00_Inbox/` and ask user to pick one **Language Rule**: Match the user's language for all responses and generated files. ## Phase 1: Plan (Delegate to Subagent) Spawn a planning subagent: ```python context = f""" Create a project kickoff plan for: [user's idea] 1. Search 10_Daily/ and 00_Inbox/ for existing notes related to this idea 2. Check 20_Projects/ to see if a git repo for this project already exists 3. Identify relevant Area (SoftwareEngineering, Finance, Health, etc.) 4. Create plan file at 90_Plans/Plan_YYYY-MM-DD_Kickoff_.md: # Kickoff Plan: [Project Name] ## Source - [inbox file path or 'inline input'] ## Objective [One sentence summary] ## Proposed Action Items [ ] Define success criteria [ ] Break down into phases [ ] Identify dependencies [ ] Set up project structure ## Draft Project Outline ### Context [What problem this solves] ### Actions (Phases) - Phase 1: [Description] - Phase 2: [Description] ### Success Metrics - [ ] Metric 1 5. Return the plan file path. """ delegate_task(goal="Create project kickoff plan", context=context, toolsets=["terminal", "file"]) ``` After the plan subagent returns, ask user to review with `clarify`: "Plan created at `[path]`. Review and confirm to proceed?" ## Phase 2: Execute (After User Confirmation) Spawn execution subagent: ```python context = f""" Execute project kickoff from plan at: 90_Plans/Plan_YYYY-MM-DD_Kickoff_.md 1. Read the plan file, note any user modifications 2. Determine scope: - If this is a NEW project (no existing git repo in 20_Projects/): Create 20_Projects//.md with C.A.P. metadata - If this project already exists as a nested git repo (has .git/): Create ONLY the metadata file 20_Projects/.md describing goals Do NOT modify any files inside the existing git repo 3. Use C.A.P. structure: - **Context**: Objectives, background - **Actions**: Phases with tasks - **Progress**: Empty for future updates 4. Link project in today's daily note at 10_Daily/YYYY-MM-DD.md 5. Archive plan: move to 90_Plans/Archives/ 6. If from inbox: - Update inbox: set status: processed, archived: YYYY-MM-DD - Move to 99_System/Archives/Inbox/YYYY/MM/ Project frontmatter: --- title: "Project Name" type: project created: YYYY-MM-DD status: active area: "[[AreaName]]" repo: "gitea-url or 'local-only'" due: priority: P2 tags: [project, ...] --- """ delegate_task(goal="Execute project kickoff", context=context, toolsets=["terminal", "file"]) ``` Report back with: - Path to the plan - Path to project metadata (if created) - Whether the project is new or already has an existing git repo ## Follow-up If user asks for code-level changes: - Say "That requires a project session — switch to 20_Projects/CrowdSight and I'll help there" - Do NOT modify code in a nested git repo during a vault session