@triclaps/cli 0.0.3 → 0.0.5

package/skills/repo-binding-closure/SKILL.md

@@ -1,54 +0,0 @@
----
-name: repo-binding-closure
-description: >
-  Use this skill when CLAPS chat or task execution is ready to touch a repo, but
-  repo binding details are missing, stale, split across messages, or not yet
-  reflected in execution_context. This covers recovering repo URL, default
-  branch, monorepo root, validation path, and the handoff into workspace setup.
-aliases:
-  - repo-binding
-tags:
-  - execution
-  - repo
-  - setup
----
-
-# repo-binding-closure
-
-Use this skill when execution is blocked because CLAPS knows the task, but not yet the repo contract needed to run it safely.
-
-## Goals
-
-- Close the gap between chat intent and executable repo context.
-- Recover missing repo binding and execution context without guessing.
-- Hand off a clean payload into `workspace-bootstrap` instead of burying repo decisions in free-form chat.
-
-## Flow
-
-1. Read the current task and chat state
-Collect the intended repo, branch, root path, validation commands, deployment surface, and any prior binding already visible in project or task context.
-
-2. Isolate the missing fields
-Call out exactly which binding fields are missing or contradictory:
-- repo URL or provider path
-- default branch
-- monorepo root or app path
-- validation command
-- preview or deploy surface
-
-3. Ask only the questions that unblock execution
-If the repo contract is incomplete, ask short, decision-driving questions instead of launching into workspace setup with guesses.
-
-4. Write the recovered context back
-Patch the task or execution context so later steps can reuse stable repo metadata instead of re-deriving it from chat.
-
-5. Hand off to execution
-Once repo binding is coherent, move into `workspace-bootstrap` and then the normal CLAPS delivery path.
-
-## Guidance
-
-- Treat repo binding as a hard prerequisite, not a soft hint.
-- Prefer one stable execution context record over repeated ad hoc clarification.
-- If the task spans multiple repos, force that decision into explicit scope before bootstrapping workspaces.
-- If validation or preview expectations are missing, surface that now; do not leave it for review-handoff.
-- Use `references/execution-lane-checklist.md` to translate chat state into concrete repo-binding and execution-lane fields before handing off.

package/skills/repo-binding-closure/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "repo-binding-closure"
-  short_description: "Recover repo binding and execution context before workspace setup"
-  default_prompt: "Use repo-binding-closure when CLAPS work is blocked on missing or stale repo binding, branch, root path, validation commands, or execution context."

package/skills/repo-binding-closure/references/execution-lane-checklist.md

@@ -1,27 +0,0 @@
-# Repo Binding Closure Checklist
-
-Use this note when CLAPS chat has enough context to execute, but the repo contract is still incomplete or split across messages.
-
-## Minimum binding contract
-
-- Repo URL or provider path is explicit.
-- Default branch or base branch is explicit.
-- Monorepo root, app path, or workspace root is explicit.
-- Validation command or success check is explicit.
-- Preview or deploy surface is named if the task changes UX.
-
-## Read order
-
-1. Current project repo binding, if one already exists.
-2. Focus task metadata and any existing `execution_context`.
-3. The latest project chat turns that mention repo, branch, workspace path, preview, or validation.
-
-## Write-back target
-
-- Prefer updating one stable `project_repo_binding` plus one coherent `execution_context`.
-- If the repo contract is still partial, persist the blocker as a missing field instead of inventing defaults.
-
-## Hand-off conditions
-
-- Hand off to `workspace-bootstrap` only when the repo path, branch base, and validation target are coherent.
-- Hand off to `execution-context-recovery` if the repo contract is known but the execution lane is still inconsistent.

package/skills/review-handoff/SKILL.md

@@ -1,40 +0,0 @@
----
-name: review-handoff
-description: >
-  Use this skill when CLAPS work is implemented and now needs review-gate
-  evidence, delivery artifacts, reviewer routing, and a concise handoff back
-  into the task or conversation.
----
-
-# review-handoff
-
-Use this skill when coding is no longer the bottleneck and the remaining work is getting the change reviewable inside CLAPS.
-
-## Goals
-
-- Turn raw execution output into a clear review handoff.
-- Make review gates, validation evidence, and remaining risks easy to inspect.
-- Route the next reviewer or approver explicitly instead of leaving the thread hanging.
-
-## Flow
-
-1. Collect evidence
-Gather the diff summary, tests run, screenshots or logs when relevant, and any branch, commit, preview, or MR links created during execution.
-
-2. Update review gates
-Mark each required gate with its current state, note what was validated, and call out anything intentionally skipped.
-
-3. Write the delivery summary
-Summarize what changed, how it was checked, what still needs human attention, and the next concrete decision or approval.
-
-4. Route the next step
-If another human or agent should act next, state that owner clearly. If the work is blocked, say what evidence or decision is missing.
-
-## Guidance
-
-- Prefer review evidence over general confidence claims.
-- If validation did not run, say so plainly and explain why.
-- If the repo is small or newly bootstrapped, a concise checked-in validation note such as `docs/validation.md` is better than leaving validation only in terminal output.
-- Keep the handoff short enough to scan, but complete enough that a reviewer does not need to reconstruct the execution from logs.
-- Use this after `git-delivery` when the repo state is ready, not while core implementation is still moving.
-- Do not introduce this as a default artifact during kickoff execution for blank or near-blank repos; implementation and minimal validation come first.

package/skills/review-handoff/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "review-handoff"
-  short_description: "Package review evidence and reviewer routing for CLAPS delivery"
-  default_prompt: "Use review-handoff when implementation is done and CLAPS now needs review-gate status, validation evidence, delivery artifacts, and an explicit next reviewer."

package/skills/roadmap.json

@@ -1,127 +0,0 @@
-{
-  "lastReviewed": "2026-04-18",
-  "shippedHighlights": [
-    "`claps-cli register`, `run`, `version`, `doctor`, `sync-runtime`, and `preview expose` are implemented and tested.",
-    "`claps-cli session login`, `projects`, `project get|create|archive|repo-binding get|set`, and `task create|delete|transition|review` now provide explicit human-session project and task administration instead of forcing those actions through chat control lines.",
-    "Runtime asset management injects the managed `skills/claps-cli` bundle and repairs drift automatically.",
-    "Canonical skill metadata now lives in `skills/manifest.json`, so CLI help, `claps-cli skills`, `claps-cli skill <name>`, and `claps-cli skills audit` share one checked-in source of truth.",
-    "Canonical skill entries now carry `triggers`, so the CLI can expose when each skill should be used instead of only printing names.",
-    "Canonical manifest tags plus draft-skill frontmatter tags now drive real `claps-cli skills --tag/--match/--category` filtering, so operators can slice the checked-in inventory without scanning the full list.",
-    "`claps-cli skills --search <text>` now searches canonical and draft skills across names, aliases, summaries, tags, and trigger text, so operators can find the right workflow from the phrase they actually remember.",
-    "`claps-cli skills` and `claps-cli skills audit` now surface checked-in draft skills that are not yet promoted into `skills/manifest.json`, so backlog skills can live in-repo without falling back to memory or TODO-only notes.",
-    "`claps-cli skill <name>` now reads checked-in draft skills as well as canonical ones, so draft workflow assets can be inspected and reused before promotion.",
-    "Draft skills can now carry checked-in `aliases` and `tags` in `SKILL.md`, so operator shorthand and backlog taxonomy survive before promotion into the canonical manifest.",
-    "Draft skill audit now validates more than existence: it checks `SKILL.md` frontmatter plus recommended `agents/openai.yaml` metadata so backlog skills do not silently rot.",
-    "`claps-cli skills todo` now generates the checked-in roadmap snapshot from manifest data, draft skills, and this roadmap file so `skills-todo.md` does not drift by hand.",
-    "`claps-cli skills --json` now emits machine-readable filtered skill discovery for automation, while keeping the human-readable default for operators.",
-    "`claps-cli doctor` now aggregates env presence, API `/health` reachability, runtime asset health, and canonical skill audit status in one operator-facing check.",
-    "`claps-cli skills audit --check-todo` now folds `skills-todo.md` drift into the canonical skill audit so repo checks can fail before stale roadmap snapshots merge.",
-    "`planning-baseline` now ships a checked-in `references/state-examples.md` note so agents can anchor planning-session fields and handoff expectations to the current contract.",
-    "`repo-binding-closure` and `assignment-kickoff-orchestration` now ship checked-in reference checklists so draft execution skills preserve the current repo-binding and kickoff contract instead of relying on memory alone.",
-    "Project chat execution lane now supports planning-baseline creation, repo-binding editing, and prepared `execution_context` creation directly in chat, so the skill backlog can focus on convergence and kickoff instead of basic data entry.",
-    "`repo-binding-closure` is now canonical because project chat can persist repo binding and hand execution prep forward without bouncing operators to a separate settings surface.",
-    "Task-pool triage now has a first-class task page UI for weighted tally review and human approve / reject actions, which makes the draft `task-pool-triage` skill worth keeping checked in while the rejection / dispatch loop still hardens."
-  ],
-  "idealCliSurface": [
-    {
-      "title": "Capability lifecycle",
-      "items": ["session login", "register", "run", "version", "doctor", "sync-runtime", "skills", "skills --json", "skills --tag/--match/--category", "skill <name>", "skills audit", "skills todo"]
-    },
-    {
-      "title": "Explicit resource administration",
-      "items": ["project list/get/create/archive", "project repo-binding get/set", "task get/create/delete/transition/review", "project-scoped task discovery"]
-    },
-    {
-      "title": "Workspace execution",
-      "items": ["repo binding validation", "worktree bootstrap", "branch prep", "execution kickoff", "progress reporting", "delivery artifact capture"]
-    },
-    {
-      "title": "Conversation execution",
-      "items": ["clarification helpers", "task creation/update patches", "planning baseline handoff", "follow-up routing", "delivery summaries back into CLAPS"]
-    },
-    {
-      "title": "Review and verification",
-      "items": ["preview exposure", "review-gate helpers", "artifact collection", "post-delivery summaries"]
-    },
-    {
-      "title": "Maintenance",
-      "items": ["deterministic runtime asset sync", "canonical skill inspection", "free-text skill discovery across names, aliases, summaries, tags, and triggers", "multi-tag and category-aware skill discovery", "machine-readable skill discovery", "roadmap snapshot generation", "upgrade guidance"]
-    }
-  ],
-  "idealSkillSet": [
-    {
-      "title": "Runtime",
-      "skills": ["claps-cli"]
-    },
-    {
-      "title": "Conversation and planning",
-      "skills": ["chat-task-delivery", "user-story-delivery", "planning-baseline", "planning-session-convergence", "task-pool-triage"]
-    },
-    {
-      "title": "Explicit resource administration",
-      "skills": ["project-admin", "task-detail-lookup", "task-admin"]
-    },
-    {
-      "title": "Environment and execution",
-      "skills": ["preview-gateway", "workspace-bootstrap", "repo-binding-closure", "execution-context-recovery", "assignment-kickoff-orchestration"]
-    },
-    {
-      "title": "Delivery and review",
-      "skills": ["git-delivery", "review-handoff", "merge-closeout"]
-    },
-    {
-      "title": "Candidate next canonical skills only after the product path hardens",
-      "skills": ["execution-context-recovery", "task-pool-triage", "merge-closeout"]
-    },
-    {
-      "title": "Incubating draft skills that should stay non-canonical until the product stabilizes further",
-      "skills": ["planning-session-convergence", "assignment-kickoff-orchestration"]
-    }
-  ],
-  "promotionGates": [
-    {
-      "skill": "execution-context-recovery",
-      "gate": "chat can create, repair, and advance `execution_context` through kickoff, heartbeat, and self-check without falling back to worker-only prototype paths."
-    },
-    {
-      "skill": "merge-closeout",
-      "gate": "MR approval, merge status sync, and post-merge task or conversation closeout have a stable provider contract instead of the current prototype-only path."
-    },
-    {
-      "skill": "task-pool-triage",
-      "gate": "channel-created task voting, dispatch thresholds, and follow-up routing stop changing across chat and task-pool surfaces."
-    },
-    {
-      "skill": "planning-session-convergence",
-      "gate": "planning_session becomes a durable main-agent contract with explicit draft selection, open-question tracking, and write-back from channel chat instead of only a one-shot baseline helper."
-    },
-    {
-      "skill": "assignment-kickoff-orchestration",
-      "gate": "chat can create or accept assignments, move `execution_context` from `prepared` into active kickoff, and keep heartbeat or self-check state synced back into the main task and conversation surfaces."
-    }
-  ],
-  "nearTermGaps": [
-    "Expand runtime injection from a single managed skill to a true managed CLAPS bundle when more platform skills become runtime-critical.",
-    "Add `references/` or `scripts/` assets for `workspace-bootstrap`, `git-delivery`, `review-handoff`, `execution-context-recovery`, `task-pool-triage`, `planning-session-convergence`, and `merge-closeout` once the worktree and closeout contracts stop moving.",
-    "Add smoke coverage for `claps-cli preview expose` success and failure formatting with mocked gateway responses.",
-    "Add `doctor` sub-checks for authenticated API validation and runtime binary presence once the runtime contract stabilizes.",
-    "Consider `claps-cli skill <name> --json` and `claps-cli skills audit --json` once external automation needs structured single-skill inspection or audit output, not just list discovery.",
-    "Consider a future `claps-cli skills promote <name>` workflow only after draft-to-canonical promotion rules stop changing."
-  ],
-  "watchList": [
-    "The execution lane now exposes planning-baseline creation, repo binding editing, and prepared execution-context creation inside project chat. The next gap is convergence and kickoff, which is why `planning-session-convergence` and `assignment-kickoff-orchestration` are now checked in as draft skills instead of staying roadmap-only ideas.",
-    "Keep the broad execution-lane browser regression API-seeded for now; the new dedicated chat repo-binding browser test covers the real UI path without making every kickoff scenario pay setup tax.",
-    "Weighted task-pool voting is now stable enough for a checked-in draft skill, but not yet stable enough to freeze as a canonical workflow contract.",
-    "Repo binding closure is now canonical, but `execution-context-recovery` still needs heartbeat and self-check coverage before it should graduate.",
-    "Review evidence is now important enough to track as a CLAPS-native workflow skill, but final merge and closeout behavior is still provider- and product-dependent.",
-    "If draft skill count keeps growing, split checked-in skill metadata into canonical plus roadmap sections instead of overloading one manifest forever.",
-    "Tags, category filters, and free-text search now drive real CLI discovery, so keep the taxonomy intentionally small and avoid near-duplicate labels."
-  ],
-  "updateRule": [
-    "Decide whether the new behavior belongs in CLI, a skill, or both.",
-    "If it is a canonical skill, update `skills/manifest.json` and the skill assets under `skills/`.",
-    "If it is not canonical yet but worth preserving, check in a draft skill under `skills/` so `claps-cli skills` and `claps-cli skills audit` can surface it.",
-    "Run `claps-cli skills audit` and `claps-cli skills todo --check`.",
-    "Refresh `skills-todo.md` from the generated snapshot when the roadmap changes."
-  ]
-}

package/skills/task-admin/SKILL.md

@@ -1,59 +0,0 @@
----
-name: task-admin
-description: >
-  Use this skill when a user wants explicit CLAPS task administration from the
-  CLI: creating tasks, reading task detail, listing project tasks, soft-deleting
-  a task, transitioning task status, or reviewing a task with an explicit
-  session-backed admin flow.
-tags:
-  - admin
-  - task
-  - workflow
----
-
-# task-admin
-
-Use this skill when the operator wants deterministic task commands instead of chat control lines.
-
-## Command surface
-
-```bash
-claps-cli session login [--email <email>] [--display-name <name>] [--org-id <id>] [--org-slug <slug>]
-claps-cli task get --task-id <task-id> [--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 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 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>]
-```
-
-## Flow
-
-1. If the caller needs task mutation and does not already have a human session token, start with `claps-cli session login`.
-2. Use `claps-cli task get` when the task id is already known and only detail lookup is needed. It accepts either `CLAPS_SESSION_TOKEN` / `--session-token` or `CLAPS_AGENT_TOKEN`.
-3. Use `claps-cli tasks --project-id <project-id>` for project-scoped discovery before creating a duplicate task. It accepts either `CLAPS_SESSION_TOKEN` / `--session-token` or `CLAPS_AGENT_TOKEN`.
-4. Use `claps-cli task create` when the operator wants a deterministic task record with explicit checklist, links, output requirements, dependencies, or auto-assignment.
-5. Use `claps-cli task transition` and `claps-cli task review` for imperative workflow control after the task already exists.
-6. Use `claps-cli task stage list` when you need the explicit coarse stage ledger rather than inferring from `workflow.phase`.
-7. Use `claps-cli task stage set|complete|block|reopen` when the agent or operator should explicitly create or maintain the coarse `planning / execution / review / delivery` ledger. Whenever the stage status changes, include a non-empty `--summary`.
-8. Use `claps-cli task review-readiness`, `task delivery-readiness`, and `task remediation-budget` when you want soft guardrail checks without handing workflow decisions back to the runtime.
-9. Use `claps-cli task review-result submit` to persist the structured review outcome that skills or agents will use for remediation vs delivery decisions.
-10. Use `claps-cli task delete` only when archive/cancel semantics are acceptable.
-
-## Rules
-
-- Prefer `task-detail-lookup` when the need is read-only detail for one known task id.
-- Prefer `chat-task-delivery` or `user-story-delivery` when the real need is story clarification, workflow shaping, or chat-native execution handoff.
-- Be explicit that `task delete` currently follows the runtime's soft-delete/cancel path, not a hard database delete.
-- Prefer `claps-cli tasks --project-id ...` before creating a new task if there is a realistic risk of duplication.
-- Use `task review` only when the user has authority to review the task; the API enforces reviewer constraints.
-- For agent-authenticated stage or review-result mutations, pass the current `--assignment-id` so the primitive is tied to the active assignment rather than acting as an unscoped global mutation.

package/skills/task-admin/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "task-admin"
-  short_description: "Create, inspect, transition, review, and soft-delete CLAPS tasks with explicit CLI commands"
-  default_prompt: "Use task-admin when a user wants deterministic task administration through claps-cli instead of chat control lines, especially for task creation, task transitions, task review, or soft-delete semantics with a human session token."

package/skills/task-contract-draft/SKILL.md

@@ -1,80 +0,0 @@
----
-name: task-contract-draft
-description: >
-  Use this skill when CLAPS asks an agent to produce a structured task contract
-  draft and write it back through the explicit contract-draft CLI primitive.
----
-
-# task-contract-draft
-
-This skill is for one narrow internal workflow: CLAPS has already selected the
-agent and queued a task-contract-draft request. Your job is to turn the brief
-into a review-ready contract draft and submit it back through `claps-cli`.
-
-## Goal
-
-Produce a structured draft with:
-
-- `definitionOfDone`
-- `acceptanceChecklist`
-- `outputRequirements`
-- `rationale`
-
-The draft should be specific enough that a human can review and refine it
-without reverse-engineering the original brief.
-
-## Rules
-
-1. Do not create or edit CLAPS tasks directly.
-2. Do not mutate workflow state, review state, or repo delivery state.
-3. Do not ask follow-up questions unless the request is unusable.
-4. Match the language of the request unless it explicitly asks otherwise.
-5. Keep acceptance items concrete and reviewer-checkable.
-6. Keep output requirements focused on what the assignee must hand back.
-7. Use the explicit CLI submit primitive instead of replying with free-form prose.
-
-## Submission path
-
-Preferred flow:
-
-1. Build a small JSON object locally.
-2. Validate that it matches the required shape.
-3. Submit it with:
-
-```bash
-claps-cli task contract-draft submit --request-id <request-id> --draft-json '<json>'
-```
-
-If inline JSON becomes awkward, write the JSON to a temp file and pass it
-through shell expansion:
-
-```bash
-claps-cli task contract-draft submit --request-id <request-id> --draft-json "$(cat /tmp/task-contract-draft.json)"
-```
-
-## Draft quality bar
-
-- `definitionOfDone`: one clear outcome sentence
-- `acceptanceChecklist`: 3-6 concrete checks
-- `outputRequirements`: 2-4 delivery artifacts or evidence expectations
-- `rationale`: brief notes explaining why the draft is shaped this way for this agent and request
-
-## Example shape
-
-```json
-{
-  "definitionOfDone": "Ship the requested task outcome in the agreed scope and leave it review-ready.",
-  "acceptanceChecklist": [
-    "The delivered work matches the task title and brief.",
-    "Validation evidence is included so a reviewer can check the result quickly."
-  ],
-  "outputRequirements": [
-    "Implementation or delivery summary",
-    "Validation or review evidence summary"
-  ],
-  "rationale": [
-    "The draft is tightened for explicit reviewer handoff.",
-    "The requested surfaces imply evidence should be easy to inspect."
-  ]
-}
-```

package/skills/task-contract-draft/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "task-contract-draft"
-  short_description: "Draft a structured CLAPS task contract and submit it back through the explicit contract-draft CLI primitive"
-  default_prompt: "Use task-contract-draft when CLAPS has already queued an internal contract-draft request for one agent and the only allowed write-back path is claps-cli task contract-draft submit."

package/skills/task-detail-lookup/SKILL.md

@@ -1,51 +0,0 @@
----
-name: task-detail-lookup
-description: >
-  Use this skill when you already know a CLAPS task id and need the current
-  authoritative detail snapshot: title, summary, status, workflow, project,
-  and linked repo binding.
-tags:
-  - inspection
-  - lookup
-  - task
----
-
-# task-detail-lookup
-
-Use this skill when clarification is not the blocker and the missing piece is the current task detail for one known `task.id`.
-
-## Command surface
-
-```bash
-claps-cli task get --task-id <task-id>
-claps-cli task get --task-id <task-id> --json
-```
-
-## Flow
-
-1. Prefer direct task lookup when the user already gave a `task.id`.
-2. Read the human-readable output when you need a quick answer in chat.
-3. Use `--json` when another tool, script, or agent needs the structured payload.
-4. If the task exists but the project has no repo binding, report that explicitly instead of guessing a repo.
-5. If the user only has `project.id` and needs discovery first, fall back to `claps-cli tasks --project-id <project-id>`.
-
-## Sandbox note
-
-- In a sandboxed Codex tool environment, `pnpm claps-cli ...` may fail before the HTTP request if `tsx` cannot create its local IPC pipe and reports `listen EPERM`.
-- In that same environment, direct requests to `http://127.0.0.1:3001` may also fail with `connect EPERM` even when the host machine can reach the local CLAPS API.
-- Treat those errors as environment isolation, not as proof that the task is missing.
-- If you hit those errors, stop retrying the same local command. Say that the sandbox cannot reach the host-local CLAPS runtime and ask for host-side output or for the current task detail to be pasted into chat.
-
-## What to report back
-
-- task reference, title, summary, status, and priority
-- current workflow kind and phase
-- project name and project id
-- linked repo owner/name, provider, default branch, and root path when present
-- whether the task currently has assignments, updates, artifacts, logs, or notifications
-
-## Rules
-
-- Prefer `claps-cli task get --task-id <task-id>` over scanning the full project task list when the task id is already known.
-- Do not invent missing repo binding, workflow, or assignment state.
-- If the user gave a task reference slug such as `#claps-13` but not the UUID, ask for the actual `task.id` or use project-task listing to cross-check candidates first.

package/skills/task-detail-lookup/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "task-detail-lookup"
-  short_description: "Fetch current task detail and linked repo binding for a known task id"
-  default_prompt: "Use task-detail-lookup when a user already knows the CLAPS task id and needs the latest detail snapshot, including workflow, project, and repo binding."

package/skills/task-pool-triage/SKILL.md

@@ -1,56 +0,0 @@
----
-name: task-pool-triage
-description: >
-  Use this skill when a channel-created CLAPS task is sitting in the weighted
-  task pool and needs vote-driven triage before dispatch. This covers checking
-  whether the candidate is executable yet, deciding approve vs reject,
-  explaining the vote, and handing the task off cleanly once the threshold is
-  met.
-tags:
-  - channel
-  - planning
-  - triage
----
-
-# task-pool-triage
-
-Use this skill when project or channel chat has already produced a candidate task, but execution should not start until the task pool says it is ready.
-
-## Goals
-
-- Keep bad or ambiguous work from auto-dispatching just because it sounds plausible in chat.
-- Turn votes into explicit execution decisions instead of vague agreement.
-- Leave the winning candidate ready for assignment, workspace setup, and delivery.
-
-## Flow
-
-1. Read the candidate state
-Inspect the task title, summary, description, workflow, preferred assignee, current tally, and the latest channel context that created the candidate.
-
-2. Check execution readiness
-Decide whether the candidate is ready to leave backlog by checking:
-- the user pain and desired outcome are clear
-- the execution boundary is narrow enough
-- the preferred assignee is correct or intentionally blank
-- validation and review expectations are concrete
-- missing repo or environment assumptions are called out
-
-3. Cast the vote deliberately
-- Approve only when the candidate is actionable enough to dispatch.
-- Reject when scope, ownership, validation, or safety is still unclear.
-- Keep the note short and decision-driving, not essay-shaped.
-
-4. Drive the next turn
-- If approved, say what the assignee should do first after dispatch.
-- If rejected, name the smallest missing pieces and route the follow-up back to chat clarification instead of pretending execution can start.
-
-5. Hand off after threshold
-When the tally passes, treat that as permission to dispatch, not as proof the task is done. Hand off to `workspace-bootstrap`, `repo-binding-closure`, or the normal delivery path as appropriate.
-
-## Rules
-
-- This applies to channel-created delivery work that enters the weighted task pool. DM-created work does not need this gate.
-- Humans contribute 2 approval points, agents contribute 1, and dispatch should wait until the threshold is met.
-- The latest vote from each voter is what matters; do not reason from stale votes.
-- A passed vote only means “ready to dispatch.” Review, execution, and merge still need their own evidence.
-- If the preferred assignee is wrong or missing, fix that decision before pushing the candidate through.

package/skills/task-pool-triage/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "task-pool-triage"
-  short_description: "Triage weighted task-pool candidates before CLAPS dispatches them"
-  default_prompt: "Use task-pool-triage when a channel-created CLAPS task is waiting in the weighted task pool and needs an approve or reject decision, clear vote rationale, and a clean handoff after the threshold is met."

package/skills/task-stage-summary-backfill/SKILL.md

@@ -1,75 +0,0 @@
----
-name: task-stage-summary-backfill
-description: >
-  Use this skill when CLAPS asks an agent to reconstruct missing completed-stage
-  summaries from recorded task history and submit them back through the explicit
-  stage-summary-backfill CLI primitive.
----
-
-# task-stage-summary-backfill
-
-This skill is for one narrow internal workflow: CLAPS has already selected the
-agent and queued a stage-summary-backfill request. Your job is to reconstruct
-missing completed-stage summaries from the provided task history and submit them
-back through `claps-cli`.
-
-## Goal
-
-Produce a structured list of workflow stage summaries where each entry includes:
-
-- `stageKey`
-- `summary`
-- `result`
-- `completedAt`
-
-The output should only cover completed workflow stages that are explicitly
-listed as missing in the request context.
-
-## Rules
-
-1. Do not create or edit CLAPS tasks directly.
-2. Do not mutate workflow state, review state, or repo delivery state outside the explicit submit primitive.
-3. Do not run tools, inspect the repo, or infer work that is not supported by the provided task history.
-4. Only write summaries for the missing stage keys named in the request.
-5. Keep each summary concise and evidence-based.
-6. If the history is thin, say so briefly instead of hallucinating details.
-7. Use the explicit CLI submit primitive instead of replying with free-form prose.
-
-## Submission path
-
-Preferred flow:
-
-1. Build a small JSON array locally.
-2. Validate that it matches the required shape.
-3. Submit it with:
-
-```bash
-claps-cli task stage-summary-backfill submit --request-id <request-id> --stage-summaries-json '<json>'
-```
-
-If inline JSON becomes awkward, write the JSON to a temp file and pass it
-through shell expansion:
-
-```bash
-claps-cli task stage-summary-backfill submit --request-id <request-id> --stage-summaries-json "$(cat /tmp/task-stage-summary-backfill.json)"
-```
-
-## Quality bar
-
-- only requested stage keys are included
-- every entry uses `result: "completed"`
-- summaries stay grounded in the recorded task history
-- `completedAt` is copied from known evidence when available, otherwise `null`
-
-## Example shape
-
-```json
-[
-  {
-    "stageKey": "execution",
-    "summary": "Implemented the requested change and left review-ready evidence in the recorded task updates and artifacts.",
-    "result": "completed",
-    "completedAt": "2026-04-20T05:18:00.000Z"
-  }
-]
-```

package/skills/task-stage-summary-backfill/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "task-stage-summary-backfill"
-  short_description: "Reconstruct missing completed-stage summaries from recorded task history and submit them back through the explicit stage-summary-backfill CLI primitive"
-  default_prompt: "Use task-stage-summary-backfill when CLAPS has already queued an internal stage-summary-backfill request for one agent and the only allowed write-back path is claps-cli task stage-summary-backfill submit."