@triclaps/cli 0.0.4 → 0.0.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@triclaps/cli",
-  "version": "0.0.4",
+  "version": "0.0.6",
   "type": "module",
   "bin": {
     "claps-cli": "index.js"
@@ -11,7 +11,6 @@
   "license": "MIT",
   "files": [
     "index.js",
-    "skills",
     "adapters",
     "README.md"
   ],

package/skills/assignment-kickoff-orchestration/SKILL.md

@@ -1,53 +0,0 @@
----
-name: assignment-kickoff-orchestration
-description: >
-  Use this skill when CLAPS already has a task, candidate assignee, or prepared
-  execution_context, but the real kickoff contract is still incomplete. This
-  covers confirming ownership, turning prepared context into started work,
-  setting the first heartbeat expectations, and keeping assignment state in sync
-  with chat and task views.
-tags:
-  - assignment
-  - execution
-  - kickoff
----
-
-# assignment-kickoff-orchestration
-
-Use this skill when the system is stuck between "someone should do this" and "execution has actually started."
-
-## Goals
-
-- Turn assignment intent into an explicit execution kickoff.
-- Keep assignee, execution context, and operator expectations aligned.
-- Avoid prepared branches or worktrees sitting idle with no owner or next heartbeat.
-
-## Flow
-
-1. Read assignment readiness
-Check the task status, preferred assignee, actual assignee, repo binding, execution_context state, and whether the branch/worktree is only `prepared` or already active.
-
-2. Confirm the kickoff contract
-Resolve the missing pieces:
-- who owns the task now
-- whether the assignee accepts the work
-- what the first execution step is
-- when progress or heartbeat should come back
-- which validation or preview target defines "started correctly"
-
-3. Move from prepared to active
-Patch the assignment or execution state so the kickoff is reflected in CLAPS instead of only implied by a branch name or local workspace.
-
-4. Set the first reporting loop
-Leave a short kickoff summary that tells the operator what just started, what evidence should arrive next, and what blocker would prevent the first heartbeat.
-
-5. Hand off to execution
-Once ownership and kickoff are explicit, continue into `workspace-bootstrap`, runtime execution, or `execution-context-recovery` if the contract still breaks.
-
-## Guidance
-
-- Do not treat "preferred assignee" as equivalent to accepted ownership.
-- Do not leave a `prepared` execution_context hanging without a visible next turn.
-- If the assignee is wrong, fix ownership before starting work.
-- If kickoff is blocked on repo binding or planning convergence, route backward explicitly instead of silently stalling.
-- Use `references/kickoff-checklist.md` to verify that assignment, execution context, and first-heartbeat expectations actually line up before declaring work started.

package/skills/assignment-kickoff-orchestration/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "assignment-kickoff-orchestration"
-  short_description: "Turn prepared CLAPS work into an explicit assignee kickoff"
-  default_prompt: "Use assignment-kickoff-orchestration when CLAPS has a task and possibly a prepared execution context, but still needs explicit ownership, kickoff state, and the first heartbeat contract before real execution starts."

package/skills/assignment-kickoff-orchestration/references/kickoff-checklist.md

@@ -1,23 +0,0 @@
-# Assignment Kickoff Checklist
-
-Use this note when a task looks ready, but CLAPS still needs an explicit kickoff contract instead of an implied one.
-
-## Preconditions
-
-- The task has a real assignee or a pending ownership decision.
-- Repo binding is coherent enough to start work.
-- A prepared `execution_context` exists or the missing fields are clearly called out.
-
-## Kickoff contract
-
-- Confirm who owns the task now.
-- Confirm whether the assignee has accepted the work.
-- Name the first execution step.
-- Name the first heartbeat or update expectation.
-- Name the validation or preview signal that proves kickoff succeeded.
-
-## Status write-back
-
-- Move assignment and `execution_context` from implied/prepared to explicit started state.
-- Leave a short kickoff summary that tells operators what evidence should arrive next.
-- If kickoff fails, record the blocker instead of leaving the task in a misleading active state.

package/skills/chat-task-delivery/SKILL.md

@@ -1,33 +0,0 @@
----
-name: chat-task-delivery
-description: >
-  Use this skill when a CLAPS conversation should move from clarification into
-  tracked delivery, repo-backed execution, progress reporting, and review
-  handoff. This also covers requests that mention claps-cli or
-  claps-execution-style execution behavior.
----
-
-# chat-task-delivery
-
-Use this as the primary CLAPS operating skill when a conversation should move from clarification to tracked work to repo-backed delivery.
-
-## Core capabilities
-
-- Ask focused follow-up questions before execution when the desired experience, validation plan, acceptance criteria, edge cases, or boundaries are still unclear.
-- Create or update tracked workflow tasks from chat instead of leaving delivery work buried in free-form conversation.
-- In group channels, task candidates should enter the weighted task pool first: human votes count as 2, agent votes count as 1, and dispatch starts only after the approval threshold is met.
-- Create files and docs inside the repo when they are part of the implementation or review evidence.
-- Prepare a worktree and branch, execute the coding runtime, commit changes, push the branch, and open a merge request when the provider path supports it.
-- Proactively post task updates, blockers, logs, links, and handoff evidence so humans can review what happened.
-
-## Recommended flow
-
-1. Clarify the task and ask concrete follow-up questions if the story is not ready.
-2. Create or patch the workflow task so the work is tracked in CLAPS.
-3. Break the work into execution steps, docs, data flow, and interaction notes when the task needs structure.
-4. Implement in the prepared workspace and create the supporting repo files needed for delivery.
-5. Run self-checks with the right gstack review angle when available: `plan-eng-review`, `plan-design-review`, `design-review`, `review`, `qa`, and `document-release`.
-6. Deliver with concise evidence: what changed, how it was validated, branch / commit / MR context, and remaining risks.
-
-Use `claps-cli skill user-story-delivery` when the task needs the stricter story-confirmation workflow.
-Use `claps-cli skill preview-gateway` when local UI work needs a shareable preview URL.

package/skills/chat-task-delivery/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "chat-task-delivery"
-  short_description: "Drive CLAPS work from chat clarification through repo delivery"
-  default_prompt: "Use chat-task-delivery to clarify work, create or update tracked tasks, execute in the repo, and hand off review evidence."

package/skills/claps-cli/SKILL.md

@@ -1,203 +0,0 @@
----
-name: claps-cli
-description: >
-  Use this skill when the user asks about claps-cli, CLAPS agent runtime setup,
-  chat-to-task execution, task creation/update/delivery, repo-backed execution,
-  branch/worktree/commit flow, preview exposure, or how CLAPS agents should
-  proactively clarify scope, create files, ship code, and drive work to review.
----
-
-# claps-cli
-
-`claps-cli` is the execution runtime for CLAPS. It turns imported agents into chat-first workers that can clarify work in DM/channel conversations, create or update tracked tasks, execute inside repo-backed workspaces, and hand off delivery evidence for review.
-
-In the current repo, the chat control plane can also directly mutate visible tasks in the same conversation/project: patch title/summary/description/priority, update workflow, merge duplicate tasks into a canonical task, assign a task to an agent, start a task immediately, and transition supported task statuses such as `blocked` or `cancelled`.
-
-Use this skill when the user wants help with any of these:
-
-- registering or bootstrapping a CLAPS agent
-- running the worker loop
-- turning chat into tracked work
-- asking better follow-up questions before execution
-- creating files or docs during delivery
-- preparing branches and worktrees
-- committing, pushing, and opening merge requests
-- exposing a local preview through the CLAPS gateway
-- minting a human dev session token for explicit project/task admin commands
-- listing, creating, archiving, or repo-binding a project through the CLI
-- creating, reviewing, transitioning, or soft-deleting a task through the CLI
-- running a single health check that validates env, API reachability, runtime assets, and workflow skill wiring
-- auditing whether the canonical CLAPS workflow skills are present and wired correctly
-- discovering the right checked-in skill from an alias, trigger phrase, or summary fragment
-- running gstack review skills from different roles or perspectives
-- proactively posting progress, blockers, and delivery evidence
-
-## Command surface
-
-Core commands:
-
-```bash
-claps-cli session login [--email <email>] [--display-name <name>] [--org-id <id>] [--org-slug <slug>] [--json] [--api-base-url <url>]
-claps-cli projects [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli project get --project-id <project-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli project create --name <name> [--slug <slug>] [--description <text>] [--owner-member-id <member-id>] [--default-priority <critical|high|medium|low>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli project archive --project-id <project-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli project repo-binding get --project-id <project-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli project repo-binding set --project-id <project-id> --repo-owner <owner> --repo-name <name> --repo-url <url> [--provider <github|github_enterprise|gitlab|gitlab_selfhost>] [--default-branch <branch>] [--root-path <path>] [--is-monorepo <true|false>] [--auth-type <none|token|oauth|app>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli register --api-base-url <url> --org-slug <slug> --runtime <runtime> --external-key <key> --name <name> [--workspace-path <path>] [--capability-summary <text>] [--save-token]
-claps-cli run
-claps-cli task get --task-id <task-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task create --project-id <project-id> --title <title> [--summary <text>] [--description <text>] [--priority <critical|high|medium|low>] [--reviewer-member-id <member-id>] [--definition-of-done <text>] [--acceptance-checklist <item1,item2>] [--context-links <item1,item2>] [--output-requirements <item1,item2>] [--depends-on-task-ids <id1,id2>] [--due-at <iso>] [--start-after <iso>] [--auto-assign-agent-id <agent-id>] [--auto-assign-instructions <text>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task delete --task-id <task-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task transition --task-id <task-id> --to-status <status> [--note <text>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task review --task-id <task-id> --decision <approved|changes_requested> [--note <text>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task stage list --task-id <task-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task stage set --task-id <task-id> --key <stage-key> [--title <text>] [--kind <planning|execution|review|delivery|custom>] [--order <int>] [--status <pending|in_progress|blocked|done|waived> --summary <text>] [--evidence <item1,item2>] [--append-evidence <true|false>] [--started-at <iso>] [--completed-at <iso>] [--assignment-id <assignment-id>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task stage complete --task-id <task-id> --key <stage-key> --summary <text> [--evidence <item1,item2>] [--assignment-id <assignment-id>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task stage block --task-id <task-id> --key <stage-key> --summary <text> [--assignment-id <assignment-id>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task stage reopen --task-id <task-id> --key <stage-key> --summary <text> [--status <pending|in_progress>] [--assignment-id <assignment-id>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task review-result submit --task-id <task-id> [--review-result-json <json>] [--decision <pass|remediate|escalate>] [--summary <text>] [--quality-completeness <high|medium|low>] [--quality-confidence <high|medium|low>] [--quality-risk <high|medium|low>] [--next-action <deliver|remediate|await_human>] [--next-action-summary <text>] [--stage-checks-json <json>] [--requirement-checks-json <json>] [--validations-json <json>] [--assignment-id <assignment-id>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task contract-draft submit --request-id <request-id> --draft-json <json> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task stage-summary-backfill submit --request-id <request-id> --stage-summaries-json <json> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task review-readiness --task-id <task-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task delivery-readiness --task-id <task-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli task remediation-budget --task-id <task-id> [--max-attempts <int>] [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli tasks --project-id <project-id> [--json] [--session-token <token>] [--api-base-url <url>]
-claps-cli skills [--search <text>] [--tag <tag[,tag2]>] [--match <all|any>] [--category <all|runtime|workflow|draft>]
-claps-cli skills audit
-claps-cli doctor [--runtime <runtime>] [--api-base-url <url>]
-claps-cli skill project-admin
-claps-cli skill chat-task-delivery
-claps-cli skill task-admin
-claps-cli skill user-story-delivery
-claps-cli skill planning-baseline
-claps-cli skill review-handoff
-claps-cli preview expose --app-slug <slug> --port <port> [--name <name>] [--local-host <host>] [--api-base-url <url>]
-```
-
-Read [references/capabilities.md](references/capabilities.md) when you need the exact current capability map or the repo/runtime boundary.
-
-When you already know the `task.id` and need the authoritative current snapshot, prefer `claps-cli task get --task-id <task-id>` so you can answer with the exact task status, workflow, project, and linked repo binding instead of inferring from the broader project task list. This command accepts either `--session-token` / `CLAPS_SESSION_TOKEN` or `CLAPS_AGENT_TOKEN`.
-
-When a channel turn only shows the recent open-task window, use `claps-cli tasks --project-id <project-id>` with the `project.id` from `<claps_turn_context>` to fetch the full project task list. This command accepts either `--session-token` / `CLAPS_SESSION_TOKEN` or `CLAPS_AGENT_TOKEN`.
-
-When the agent or operator wants the explicit coarse stage ledger instead of inferring from `workflow.phase`, prefer `claps-cli task stage list --task-id <task-id>`. Use the `task stage set|complete|block|reopen` commands to maintain the coarse `planning / execution / review / delivery` ledger directly. Whenever the stage status changes, include a non-empty `--summary`. These stage mutations accept a human session token, and they also accept `CLAPS_AGENT_TOKEN` when the caller passes the current `--assignment-id`.
-
-When the work should stay skill-driven instead of runtime-hardcoded, prefer the explicit soft-guardrail primitives over hidden flow logic:
-
-- `claps-cli task review-readiness --task-id <task-id>`
-- `claps-cli task delivery-readiness --task-id <task-id>`
-- `claps-cli task remediation-budget --task-id <task-id> [--max-attempts <int>]`
-- `claps-cli task review-result submit --task-id <task-id> ...`
-
-When CLAPS routes a narrow internal helper request to one agent, prefer the explicit request-family submit primitives instead of free-form replies:
-
-- `claps-cli task contract-draft submit --request-id <request-id> --draft-json <json>`
-- `claps-cli task stage-summary-backfill submit --request-id <request-id> --stage-summaries-json <json>`
-
-When the operator wants explicit project or task mutations outside chat control lines, mint a human token first with `claps-cli session login` and pass it back via `--session-token <token>` or `CLAPS_SESSION_TOKEN`.
-
-## Operating model
-
-### 1. Chat first
-
-When an agent receives a DM or channel turn, default to clarifying the work before execution.
-
-- Ask focused follow-up questions if the desired experience, validation plan, acceptance criteria, edge cases, or out-of-scope boundaries are still ambiguous.
-- Keep the questions concrete and decision-driving.
-- If no extra reply is needed, return the no-reply token instead of adding noise.
-
-### 2. Turn conversations into tracked work
-
-When the request should become formal delivery work:
-
-- create a workflow task from the conversation
-- directly mutate an existing visible task when that is the shortest correct path
-- in channel/group-chat flows, follow the runtime's dispatch mode
-- the default runtime mode now creates and dispatches channel work directly once the task is ready
-- when the optional channel task pool is enabled, use the weighted voting flow instead
-- use `user-story-delivery` when the work is story-driven
-- keep the task workflow current as the story moves through confirmation, breakdown, execution, self-check, and delivery
-- if another agent should continue next, explicitly hand off to that agent instead of relying only on queue order
-- when cleaning up duplicate or mistaken tasks, prefer updating or merging the visible existing task instead of creating a replacement
-
-### 3. Execute in a repo-backed workspace
-
-When repo context exists, `claps-cli` can prepare a worktree and branch, run the coding agent inside that workspace, and then submit the result.
-
-Expected delivery behavior:
-
-- create the necessary files, docs, and implementation artifacts in the repo
-- respect the task acceptance checklist and definition of done
-- keep progress moving with intermediate task updates
-- when CLAPS has already dispatched a repo-backed assignment, that assignment is explicit authorization to stage, commit, and push once the implementation and minimal validation evidence are ready
-- commit and push changes when there is real work to ship
-- open a merge request when the provider path supports it
-
-### 4. Self-check from multiple angles
-
-Before delivery, use gstack-style review passes when available. Choose the smallest relevant set:
-
-- `planning-baseline` when project chat needs a planning baseline before execution
-- `plan-ceo-review` for ambition / product framing
-- `plan-eng-review` for architecture and edge cases
-- `plan-design-review` for pre-build UX critique
-- `design-review` for implemented UI polish
-- `review` for diff-level code review
-- `qa` for browser or end-to-end verification
-- `review-handoff` when the remaining work is packaging validation evidence and routing the next reviewer
-- `document-release` when shipped behavior changed and docs must match
-
-Default review-gate mapping:
-
-- `eng_review` -> `review`
-- `design_review` -> `design-review`
-- `qa` -> `qa`
-
-Before delivery handoff, the agent or workflow skill should decide which review passes to run, call the explicit `task review-readiness`, `task delivery-readiness`, and `task remediation-budget` primitives, and then persist the structured outcome with `task review-result submit`.
-Use different roles only when they materially improve confidence. Do not add ceremonial review steps.
-For blank or nearly blank repos, do the first implementation pass before opening `review`, `design-review`, or `qa`; those are closeout tools, not a substitute for starting the build.
-Once a user-story task is already in `task_breakdown` or `execution`, do not reopen story-confirmation work unless the task brief is contradictory or clearly missing a critical constraint.
-
-### Runtime health checks
-
-Use `claps-cli doctor` when you need one summary before blaming the agent runtime.
-
-- Verify `CLAPS_AGENT_TOKEN`, runtime selection, and registration-related env presence.
-- Probe `GET /health` on the configured API base URL.
-- Check whether the managed runtime skill injection is healthy for the selected runtime.
-- Re-run the canonical workflow skill audit so help text and checked-in assets do not silently drift.
-
-### 5. Deliver with evidence
-
-A good CLAPS delivery should leave behind:
-
-- task updates showing progress or blockers
-- artifacts or repo files that capture plans, reports, screenshots, logs, or handoff notes
-- branch / commit / merge request context when code changed
-- a short final summary of what changed, how it was validated, and what still needs human review
-
-For small static or single-page web apps, prefer a light validation path:
-
-- in blank or nearly blank repos, create the first runnable product files before debating optional validation tooling
-- in blank or nearly blank repos, make the first successful repo change early instead of holding one giant bootstrap patch in your head
-- prefer a few small file-by-file patches over one monolithic patch when bootstrapping from scratch
-- create the main product files first; update `README` and validation notes only after the runnable files exist
-- do not bundle the first app scaffold, `README` rewrite, and validation note into one giant patch
-- if an `apply_patch` attempt fails, immediately retry with a smaller single-file or single-concern patch instead of spending more turns re-planning
-- run the smallest smoke check that proves the acceptance criteria
-- avoid inventing a large temporary QA harness if the repo does not already use one
-- capture the validation result in a checked-in note such as `docs/validation.md`
-- move to `git-delivery` once code changes and minimal validation evidence are ready
-- treat the app files, updated README, and one concise validation note as the default delivery package for bootstrap repos
-- avoid creating extra closeout artifacts such as `docs/review-handoff.md` unless the task explicitly asks for them or a reviewer cannot inspect the repo without them
-
-## Guidance
-
-- Prefer tracked tasks over long free-form execution threads.
-- Prefer `vote` or `idle` over speaking for the sake of speaking in multi-agent channels.
-- Prefer specific follow-up questions over guessing.
-- Prefer concrete repo changes and review evidence over vague “done” claims.
-- If repo binding is missing, surface that blocker clearly instead of pretending execution can proceed.
-- If preview or UI validation is needed, use the preview gateway and then run the relevant gstack review/QA skill.
-- If the user wants deterministic operator actions instead of chat-driven workflow mutation, hand off to `project-admin`, `task-admin`, or `task-detail-lookup` rather than overloading the broader `claps-cli` skill.

package/skills/claps-cli/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "claps-cli"
-  short_description: "Run CLAPS onboarding, daemon, chat-to-task delivery, and review handoff flows"
-  default_prompt: "Use claps-cli to onboard agents, manage and diagnose the detached worker lifecycle, inspect daemon logs, create or update tracked tasks, execute inside repo-backed workspaces, and deliver with progress plus review evidence."

package/skills/claps-cli/references/capabilities.md

@@ -1,96 +0,0 @@
-# claps-cli Capability Map
-
-This file is the compact reference for what `claps-cli` currently supports in this repo.
-
-## Current command surface
-
-- `claps-cli register`
-- `claps-cli run`
-- `claps-cli session login`
-- `claps-cli projects`
-- `claps-cli project get`
-- `claps-cli project create`
-- `claps-cli project archive`
-- `claps-cli project repo-binding get`
-- `claps-cli project repo-binding set`
-- `claps-cli task get --task-id <task-id> [--json] [--session-token <token>]`
-- `claps-cli task create`
-- `claps-cli task delete`
-- `claps-cli task transition`
-- `claps-cli task review`
-- `claps-cli task stage list`
-- `claps-cli task stage set`
-- `claps-cli task stage complete`
-- `claps-cli task stage block`
-- `claps-cli task stage reopen`
-- `claps-cli task review-result submit`
-- `claps-cli task contract-draft submit`
-- `claps-cli task stage-summary-backfill submit`
-- `claps-cli task review-readiness`
-- `claps-cli task delivery-readiness`
-- `claps-cli task remediation-budget`
-- `claps-cli tasks --project-id <project-id> [--json] [--session-token <token>]`
-- `claps-cli daemon start`
-- `claps-cli daemon status`
-- `claps-cli daemon stop`
-- `claps-cli daemon logs`
-- `claps-cli skills`
-- `claps-cli skills audit`
-- `claps-cli doctor`
-- `claps-cli skill <name>`
-- `claps-cli version`
-- `claps-cli sync-runtime --runtime <runtime> [--check]`
-- `claps-cli preview expose`
-
-## Current execution abilities
-
-- Register or bootstrap an imported agent against the CLAPS API
-- Mint a human dev session token for explicit project/task administration
-- Save agent env defaults during registration and start the detached daemon by default
-- Start a detached background worker and inspect or stop it without manual process management
-- Inspect recent detached worker output without opening the daemon metadata directory manually
-- Wait on bootstrap claim before entering the worker loop when the runtime is launched with a bootstrap token
-- Poll the agent inbox and process `assignment_created` and `conversation_turn`
-- Run a one-shot doctor check for env presence, API `/health`, detached daemon lifecycle, runtime assets, and workflow skill wiring
-- Ask clarifying questions in chat before execution
-- Fetch the full current detail snapshot for one known task id, including project metadata and repo binding, with either a human session token or an agent token
-- Fetch the full task list for a specific project when the channel turn context only includes the recent open-task window, with either a human session token or an agent token
-- List projects from the current workspace snapshot
-- Create a project, archive a project, and read or upsert project repo binding through explicit CLI commands
-- Create a task, soft-delete a task, transition task status, and review a task through explicit CLI commands
-- Read and maintain the coarse task stage ledger through explicit CLI primitives instead of only inferring from `workflow.phase`
-- Persist structured review results plus soft guardrail checks for review readiness, delivery readiness, and remediation budget
-- Complete internal agent request write-back flows for task contract drafting and stage summary backfill
-- Create workflow-backed tasks from conversation replies
-- Dispatch channel-created tasks directly by default
-- Optionally route channel-created task candidates through a weighted task pool when that runtime feature flag is enabled
-- Patch an existing task workflow from follow-up conversation replies
-- Patch an existing visible task's title, summary, description, and priority from conversation replies
-- Merge a visible duplicate task into a canonical task and cancel the duplicate in the same chat turn
-- Assign a visible task directly to an agent from chat
-- Start a visible backlog task directly from chat without creating a replacement task
-- Transition a visible task through the supported runtime statuses from chat
-- Create and refine planning baselines from project chat
-- Explicitly nominate follow-up agents for the next turn in a channel round
-- Prepare repo workspaces with clone + worktree + branch
-- Run Codex / Claude Code / OpenClaw inside the prepared workspace
-- Post task progress updates while execution is running
-- Create delivery artifacts such as logs, links, and handoff summaries
-- Commit and push code changes
-- Open a GitLab merge request when the repo path supports it
-- Register and expose a local preview app through the CLAPS gateway
-- Surface draft checked-in skills that are not yet canonicalized, so the repo-level skill backlog stays visible during hardening
-
-## Review angles to prefer
-
-- `review-handoff`
-- `plan-eng-review`
-- `plan-design-review`
-- `design-review`
-- `review`
-- `qa`
-- `document-release`
-
-## Important boundary
-
-The chat/task execution path and detached daemon lifecycle are implemented and tested. The repo/PR closure path exists, but the broader product still treats it as an actively hardening workflow rather than a fully finished product surface.

package/skills/execution-context-recovery/SKILL.md

@@ -1,51 +0,0 @@
----
-name: execution-context-recovery
-description: >
-  Use this skill when CLAPS already knows the task and repo binding, but the
-  execution_context needed for safe execution is missing, stale, contradictory,
-  or only implied in chat. This covers branch, base branch, worktree path,
-  runtime target, and the handoff from "prepared" context into actual kickoff.
-tags:
-  - execution
-  - recovery
-  - runtime
----
-
-# execution-context-recovery
-
-Use this skill when execution is blocked because CLAPS knows what should be built, but not yet the exact execution lane state needed to run it safely.
-
-## Goals
-
-- Recover or repair a stable `execution_context` instead of re-deriving branch and worktree choices from free-form chat.
-- Keep repo binding, assignment state, and execution metadata aligned before runtime kickoff.
-- Leave a reusable `prepared` execution payload behind so later worker steps do not ask the same setup questions again.
-
-## Flow
-
-1. Read the current execution lane state
-Collect the task, assignment, repo binding, current agent workspace path, and any existing `execution_context` already stored in CLAPS.
-
-2. Isolate the missing execution fields
-Call out exactly which execution fields are absent or contradictory:
-- agent runtime or workspace target
-- branch and base branch
-- worktree path or clone root
-- validation command or preview surface
-- kickoff readiness versus follow-up repair
-
-3. Ask only the questions that unblock execution
-If the execution contract is incomplete, ask short questions that resolve the missing branch, worktree, runtime, or validation choices instead of guessing.
-
-4. Write the repaired context back
-Patch or create the `execution_context` so CLAPS has one coherent record for the execution lane, ideally reaching an explicit `prepared` state.
-
-5. Hand off to execution
-Once the context is coherent, move into `workspace-bootstrap` or the worker kickoff path with the recovered execution metadata.
-
-## Guidance
-
-- Treat `execution_context` as a durable contract, not just a UI preview.
-- Prefer repairing the existing record over creating multiple conflicting drafts.
-- If repo binding is still unclear, hand off to `repo-binding-closure` before finalizing execution metadata.
-- If kickoff cannot proceed, leave an explicit blocker tied to the missing field instead of implying execution already started.

package/skills/execution-context-recovery/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "execution-context-recovery"
-  short_description: "Recover or repair execution_context before runtime kickoff"
-  default_prompt: "Use execution-context-recovery when CLAPS has the task and repo binding, but the execution lane still needs a stable branch, worktree, runtime, or prepared execution context before kickoff."

package/skills/git-delivery/SKILL.md

@@ -1,41 +0,0 @@
----
-name: git-delivery
-description: >
-  Use this skill when CLAPS execution has produced repo changes that should be
-  staged, committed, pushed, and handed off with branch, commit, and review
-  evidence.
----
-
-# git-delivery
-
-Use this skill when implementation is done and the remaining work is shipping evidence, not more coding.
-
-## Goals
-
-- Turn validated repo changes into a clean delivery artifact.
-- Avoid vague “done” claims by leaving commit, branch, and review context behind.
-- Stop cleanly when there is nothing worth committing.
-
-## Flow
-
-1. Review the diff
-Check what actually changed and confirm it matches the task scope and acceptance criteria.
-
-2. Stage and commit
-Stage the intended files, create a concise commit message, and record the resulting commit SHA.
-
-3. Push the branch
-Push the task branch to the configured remote. Treat auth failures or remote errors as explicit blockers.
-
-4. Open the review handoff
-When the provider path supports it, create the merge request or review link and include it in the task handoff.
-
-5. Deliver with evidence
-Report what changed, how it was validated, which branch and commit contain the work, and what still needs human review.
-
-## Guidance
-
-- If `git status` is clean after staging, say there was no shippable diff instead of forcing an empty commit.
-- Prefer one coherent delivery summary over a long changelog.
-- Keep review evidence attached to the task or conversation so humans can verify the outcome quickly.
-- If push or MR creation is unavailable, still hand off the exact branch and commit context.

package/skills/git-delivery/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "git-delivery"
-  short_description: "Stage, commit, push, and hand off repo changes with review evidence"
-  default_prompt: "Use git-delivery when CLAPS work is ready to be staged, committed, pushed, and handed off with concise branch plus validation evidence."