Add new skills for cockpit scheduler and todo management

- Introduced `cockpit-scheduler-agent` to manage scheduler tasks, jobs, and research profiles through MCP tools.
- Added `cockpit-scheduler-router` for routing and dispatching Cockpit Todo cards, ensuring proper state management and workflow flags.
- Created `cockpit-todo-agent` to facilitate reading and updating the internal Cockpit board, emphasizing the distinction between Todo cards and scheduled tasks.
- Implemented `copilot-scheduler-agent-merge` for comparing and selectively merging ideas from a bundled starter-agent mirror into the existing agent system.
- Added `copilot-scheduler-intro` as an onboarding guide for new users to understand the source-scheduler plugin.
- Established `copilot-scheduler-setup` to assist users in planning and integrating a structured agent ecosystem within their repository.

Author: goodguy1963

.agents/skills/cockpit-scheduler-agent/SKILL.md

@@ -0,0 +1,301 @@
+---
+name: cockpit-scheduler-agent
+description: "Use when an agent needs to manage scheduler tasks, Jobs workflows, job folders, pause checkpoints, compile-to-task, or research profiles through the scheduler MCP tools."
+copilotCockpitSkillType: operational
+copilotCockpitToolNamespaces: [scheduler, research]
+copilotCockpitWorkflowIntents: [needs-bot-review, ready]
+copilotCockpitApprovalSensitive: true
+copilotCockpitPromptSummary: "Use scheduler_ and research_ MCP tools for task, job, pause, and research mutations instead of editing repo-local scheduler files by hand."
+copilotCockpitReadyWorkflowFlags: [ready, ON-SCHEDULE-LIST]
+copilotCockpitCloseoutWorkflowFlags: [needs-user-review, FINAL-USER-CHECK]
+---
+
+# Cockpit Scheduler Agent Skill
+
+Use this skill when you want an agent to work with the scheduler MCP surface in a concept-first way instead of guessing tool names.
+
+---
+
+> **CRITICAL DISTINCTION — Tasks vs. Todo Cockpit cards**
+>
+> | Concept | What it is | Where it lives | Tool prefix |
+> |---|---|---|---|
+> | **Task** | A scheduled prompt execution entry | Workspace scheduler store, mirrored to `.vscode/scheduler.json` | `scheduler_` |
+> | **Todo Cockpit card** | A planning / communication card on the board | Workspace Cockpit store, mirrored to `.vscode/scheduler.private.json` | `cockpit_` |
+>
+> **These are completely separate artifacts with entirely separate tool sets.**
+> A task runs code on a schedule. A Cockpit card tracks intent, review state, and conversation.
+> Creating a task does NOT create a card. Creating a card does NOT schedule execution.
+> Never conflate the two. Never use `scheduler_` tools to manage board cards, and never use `cockpit_` tools to manage scheduled execution.
+
+---
+
+## Mental Model
+
+- **Task** = one scheduled prompt execution entry in the workspace scheduler store
+- **Job** = a workflow made of task nodes and pause checkpoints in the workspace scheduler store
+- **Job folder** = organization only, no execution logic
+- **Research profile** = a repo-local benchmark plan in the workspace research store
+- **Research run** = a recorded benchmark execution result and history entry
+- JSON mode uses `.vscode/scheduler.json`, `.vscode/scheduler.private.json`, and `.vscode/research.json` as the primary files.
+- When the workspace setting `copilotCockpit.storageMode` is `sqlite`, the extension uses `.vscode/copilot-cockpit.db` as the primary runtime store, keeps compatibility JSON mirrors, and writes `.vscode/copilot-cockpit.db-migration.json`. MCP tool semantics stay the same.
+
+## Required Preflight
+
+Before mutating scheduler state, verify all of the following:
+
+- The active workspace is the repo that actually owns the task or job being discussed.
+- Any repo paths or production-chain references mentioned in the request exist in the current workspace.
+- The required MCP tool exists in the current session before you plan around it.
+
+If any of those checks fail, stop and report the blocker instead of mutating the repo-local scheduler/Cockpit mirrors or recreating records by hand.
+
+## Mandatory MCP Capability Gate
+
+This skill is MCP-dependent. Do not try to "work around" missing scheduler or research MCP tools.
+
+- If the current agent cannot access the required `scheduler_` or `research_` MCP tool, do not solve the task by editing `.vscode` JSON files directly, inventing results, or pretending the mutation succeeded.
+- First prefer a handoff or subagent path only when that target agent actually has the required MCP tools and is allowed to perform the mutation.
+- Do not hand off a scheduler mutation to a read-only exploration agent or any agent that still lacks the required MCP surface.
+- If no MCP-capable handoff target is available, tell the user plainly that the active agent lacks the required MCP tools and that they must switch to an MCP-enabled agent or grant the needed tool permissions.
+- Only continue without MCP when the user explicitly wants analysis, documentation, or a plan instead of a live scheduler mutation.
+
+## Task Modes
+
+Use this distinction when deciding whether a user wants a one-time task or a recurring task.
+
+### One-time task
+
+- Runs once and then deletes itself automatically after a successful execution.
+- Best for ad hoc actions, one-off cleanup, migration work, or a single AI-assisted response.
+- Does not keep a recurring chat-session mode at the task level.
+- Should be used when the user wants a single future execution rather than an ongoing schedule.
+- **Todo Cockpit relationship:** A one-time task is almost always spawned from an approved todo card. That card is the planning record — do NOT create a new Cockpit card for the task itself. Use `scheduler_update_task` when the task needs changes. Use `cockpit_finalize_todo` on the originating card when the task completes.
+
+### Recurring task
+
+- Runs repeatedly on the cron schedule until the user disables or deletes it.
+- Best for daily dispatchers, weekly checks, maintenance loops, and other repeatable automation.
+- Can use the task-level chat session choice (`new` or `continue`).
+- Manual runs should honor that same chat-session choice. `new` means start a fresh Copilot chat before execution. `continue` means reuse the current chat session instead of silently opening a new one.
+- Can be reviewed on startup as an overdue task and either run now or wait for the next cycle.
+- **Todo Cockpit relationship:** Every recurring task has one permanent card in the `Recurring Tasks` section of Cockpit. That card is never finalized. It is a living change log. When the task changes — prompt, schedule, model, or behavior — update the task with `scheduler_update_task` AND add a comment to its Cockpit card documenting what changed and why. Do NOT create a new card for each change.
+
+### Practical rule
+
+- If the user says "do this once", "one-off", "single run", or "run it one time", use a one-time task.
+- If the user says "every day", "daily", "weekly", "keep running", or "recurring", use a recurring task.
+- If the user wants a workflow with multiple steps, pauses, or a bundled output, use a job instead of a task.
+
+## Tool Map
+
+### Tasks
+Use these when the goal is to create or manage one scheduled prompt.
+
+Use task tools for both task modes, but pick the right behavior:
+
+- one-time task -> create a task that should run once, delete itself automatically after success, and leave the originating todo card as the planning record
+- recurring task -> create a task that should remain scheduled over time
+
+- `scheduler_list_tasks` - inspect saved tasks
+- `scheduler_get_task` - inspect one task
+- `scheduler_add_task` - create a new task
+- `scheduler_update_task` - edit a task in place
+- `scheduler_duplicate_task` - make a disabled copy
+- `scheduler_remove_task` - delete a task
+- `scheduler_run_task` - trigger a task on the next tick
+- `scheduler_toggle_task` - enable or disable a task
+- `scheduler_list_history` - inspect scheduler snapshots
+- `scheduler_restore_snapshot` - restore a saved scheduler snapshot
+- `scheduler_get_overdue_tasks` - find due or missed tasks
+
+### Jobs
+Use these when the goal is a workflow made of multiple steps, pause checkpoints, or bundled execution.
+
+- `scheduler_list_jobs` - inspect all jobs and folders
+- `scheduler_get_job` - inspect one job with node summaries
+- `scheduler_create_job` - create a new workflow shell
+- `scheduler_update_job` - rename or reconfigure a job
+- `scheduler_delete_job` - delete a job and detach its tasks
+- `scheduler_duplicate_job` - clone a job workflow
+- `scheduler_list_job_folders` - inspect job folders
+- `scheduler_create_job_folder` - create a job folder
+- `scheduler_update_job_folder` - rename or reparent a folder
+- `scheduler_delete_job_folder` - delete an empty folder
+- `scheduler_add_job_task` - attach an existing task to a job
+- `scheduler_remove_job_task` - remove a task node from a job
+- `scheduler_create_job_pause` - insert a manual checkpoint
+- `scheduler_update_job_pause` - rename a pause checkpoint
+- `scheduler_delete_job_pause` - remove a pause checkpoint
+- `scheduler_update_job_node_window` - change a node window length
+- `scheduler_reorder_job_node` - move a node in the workflow order
+- `scheduler_compile_job_to_task` - bundle the whole job into one task and park the source job in Bundled Jobs
+
+### Todo Cockpit (agent-state catalog management)
+Use these when the goal is to manage the flag or label palette used by Todo Cockpit cards.
+
+- `cockpit_save_flag_definition` - upsert a flag entry in the flag palette (name + optional hex color); flags are squared chips and the active workflow is normalized to one canonical workflow flag such as `new`, `needs-bot-review`, `needs-user-review`, `ready`, `ON-SCHEDULE-LIST`, or `FINAL-USER-CHECK`
+- `cockpit_delete_flag_definition` - remove a flag from the flag palette by name
+- `cockpit_save_label_definition` - upsert a label entry in the label palette (name + optional hex color); labels are **multi-value** pill chips used for user-facing categorization, not agent action routing
+- `cockpit_delete_label_definition` - remove a label from the label palette by name
+
+Closeout shorthand:
+
+- `scheduled-task` belongs in `labels`, not `flags`
+- do not suggest more than one active workflow flag in a closeout update
+- if the user still needs review, prefer one review-state flag such as `needs-user-review`
+- treat `ON-SCHEDULE-LIST` as the canonical scheduled workflow flag, not as a second review flag to stack onto a handoff
+
+### Research
+Use these when the goal is to configure or inspect a bounded benchmark profile.
+
+- `research_list_profiles` - inspect all research profiles
+- `research_get_profile` - inspect one research profile
+- `research_create_profile` - create a research profile
+- `research_update_profile` - update a research profile
+- `research_delete_profile` - delete a research profile
+- `research_duplicate_profile` - clone a research profile
+- `research_list_runs` - inspect recent runs
+- `research_get_run` - inspect one recorded run
+
+## Conceptual Guidance
+
+### When to use tasks vs jobs
+- Use a **task** when the user wants one scheduled prompt with agent, model, labels, prompt source, and cron.
+- Use a **one-time task** for a single execution that should delete itself automatically after success.
+- Use a **recurring task** when the user wants the same prompt to keep running on a schedule.
+- Use a **job** when the user wants a workflow with multiple steps, optional pause checkpoints, or a bundled execution flow.
+- Use **compile job to task** when the user wants the whole workflow collapsed into one standalone prompt task.
+
+### Cockpit card relationship per task mode
+
+| Task mode | Cockpit card? | What to do when task changes |
+|---|---|---|
+| **One-time** | Reuse the originating todo card (no new card) | `scheduler_update_task` only; no new card or comment needed unless scope changes |
+| **Recurring** | One permanent card in `Recurring Tasks` section (never archived) | `scheduler_update_task` + `cockpit_add_todo_comment` on its card to record the change |
+
+- The `Recurring Tasks` section in Cockpit is collapsible like Archive, but holds **alive, long-running items** — not completed ones.
+- Never create a new Cockpit card every time a recurring task is modified. One card per task, with comments as the history.
+- When a one-time task finishes and the user still needs to review the outcome, prefer `cockpit_closeout_todo` on the originating card over manual multi-step card repair.
+- When describing that closeout, phrase it as one flag plus optional labels, not as multiple flags. Example: `Set flag to needs-user-review` and `Add label scheduled-task`.
+
+### When to use job folders
+- Use folders only for organization.
+- Do not treat folders as execution units.
+- Use folders to group related jobs like campaigns, recurring maintenance, experiments, or backlog bundles.
+
+### When to use research profiles
+- Use research profiles when the user wants repeatable benchmark-driven iteration.
+- A research profile is not the same as a scheduled task.
+- Research focuses on instructions, editable paths, benchmark command, metric regex, and agent/model choices.
+- Start and stop research runs in the app UI when run execution is needed; use MCP for profile setup and run inspection.
+
+## How This Plugin Is Commonly Used
+
+Look at the repo-local scheduler store and its compatibility mirrors as the live example set for this repository. Typical patterns include:
+
+- recurring automation tasks that dispatch work to Todo Cockpit or other services
+- daily research/market scans that collect ideas and create follow-up tasks
+- maintenance jobs that run on a schedule and bundle multiple steps
+- repo-specific workflow jobs that combine task steps, pause checkpoints, and a bundled output task
+- research profiles that benchmark a change against a local command and a metric regex
+
+## Example Set Completeness
+
+When the user asks for demo data, example data, screenshot data, or onboarding seed content, do not stop after creating recurring tasks plus one job.
+
+- `Todo Cockpit` needs at least one active planning card that is not merely a recurring-task mirror.
+- `Tasks` need at least one standalone scheduled task visible in the task list.
+- `Jobs` need at least one real workflow with task nodes and a pause checkpoint.
+- `Research` needs one profile when the user asks for research coverage too.
+
+Do not count job child tasks or recurring-task cards as covering every surface by themselves. If the request is for a complete example set, create separate artifacts through MCP for each requested surface.
+
+## Practical Examples
+
+### 1. Create a recurring task
+Use `scheduler_add_task` when the user wants a simple scheduled prompt.
+
+Example:
+- "Create a daily market research task that uses GPT-5.3-Codex and runs at 9:17."
+
+### 1a. Create a one-time task
+Use `scheduler_add_task` with `oneTime: true` when the user wants a single future execution.
+
+Example:
+- "Create a one-time task to send the migration summary tomorrow morning and then auto-delete itself after the successful run."
+
+### 2. Update an existing task
+Use `scheduler_update_task` when the cron, prompt, model, or labels should change but the task should stay the same record.
+
+Example:
+- "Adjust the dispatcher cron and keep the same task ID."
+
+If the task is recurring, you can also update its chat-session behavior:
+- `new` for a fresh chat session before sending the prompt
+- `continue` for the current chat flow when the environment supports it
+
+When the task is run manually or by schedule, the agent should treat that field as execution behavior, not just metadata. Do not describe a `continue` task run as creating a new chat session.
+
+### 3. Build a job workflow from existing tasks
+Use `scheduler_create_job`, then `scheduler_add_job_task`, then `scheduler_create_job_pause`.
+
+Example:
+- "Create a job for the weekly content loop with a draft task, a manual review pause, and a publish task."
+
+### 4. Bundle a job into one task
+Use `scheduler_compile_job_to_task` when the workflow should become one standalone prompt task.
+
+Example:
+- "Compile this job into one Bundled Task and park the source job in Bundled Jobs."
+
+### 5. Organize jobs into folders
+Use `scheduler_create_job_folder` and `scheduler_update_job_folder` when the user wants a clearer workflow layout.
+
+Example:
+- "Put all launch workflows into a Marketing folder and keep experiments separate."
+
+### 6. Create a research profile
+Use `research_create_profile` when the user wants repeatable benchmark iterations.
+
+Example:
+- "Create a research profile that edits docs, runs npm test, and scores the result with a regex."
+
+### 7. Inspect research history
+Use `research_list_runs` and `research_get_run` when the user wants to review previous benchmark executions before changing the profile.
+
+Example:
+- "Show me the last few runs for this benchmark profile and the winning score trend."
+
+## Decision Rules
+
+- Prefer the most specific tool that matches the concept.
+- Run the workspace and capability preflight before changing scheduler state for remediation or dispatcher work.
+- Do not use a task tool when the user is clearly asking for a job workflow.
+- Do not use job tools when the user only needs one scheduled prompt.
+- Do not treat one-time and recurring tasks as separate tool categories; they are the same task concept with different lifecycle behavior.
+- Use one-time tasks for disposable, single-run work.
+- Use recurring tasks for persistent automation.
+- Do not use research tools when the user only wants scheduler task edits.
+- If a recurring task is configured with `chatSession: continue`, manual `runNow` behavior should stay in the current chat instead of opening a fresh session first.
+- If the user asks for a workflow that mixes all three, split it:
+- task setup first
+- job composition second
+- research setup third
+- Do not patch repo-local scheduler JSON directly after an MCP failure or partial mutation unless the user explicitly approves a last-resort recovery path.
+
+## Output Expectations For The Agent
+
+When using this skill, the agent should explain:
+- which concept it is editing
+- which MCP tool category it chose
+- what changed in repo-local state
+- whether a follow-up UI action is needed for research run execution
+
+## Safety Notes
+
+- Keep edits scoped to the repo-local scheduler and research files.
+- Treat direct edits to `.vscode/scheduler.json`, `.vscode/scheduler.private.json`, or `.vscode/research.json` as a last-resort recovery path, not a normal execution path.
+- Preserve existing task IDs and job IDs unless the user asks for a rename or duplication.
+- For job compilation, keep backward compatibility with older scheduler data.
+- If a folder or profile is not safe to delete because it still has children or dependent items, stop and report that instead of forcing removal.