@triclaps/cli 0.0.4 → 0.0.6

package/skills/manifest.json

@@ -1,324 +0,0 @@
-{
-  "skills": [
-    {
-      "name": "claps-cli",
-      "assetDirName": "claps-cli",
-      "category": "runtime",
-      "tags": ["delivery", "onboarding", "runtime"],
-      "triggers": [
-        "agent runtime setup or registration",
-        "chat-to-task execution behavior",
-        "CLI health checks or runtime sync"
-      ],
-      "summary": "Run CLAPS chat-to-task delivery, repo execution, and review handoff flows."
-    },
-    {
-      "name": "chat-task-delivery",
-      "assetDirName": "chat-task-delivery",
-      "category": "workflow",
-      "aliases": ["claps-execution"],
-      "tags": ["chat", "delivery", "task"],
-      "triggers": [
-        "conversation should become tracked work",
-        "chat clarification before execution",
-        "task creation plus repo delivery handoff"
-      ],
-      "summary": "Drive CLAPS work from chat clarification through repo delivery."
-    },
-    {
-      "name": "user-story-delivery",
-      "assetDirName": "user-story-delivery",
-      "category": "workflow",
-      "tags": ["delivery", "planning", "story"],
-      "triggers": [
-        "story-first product work",
-        "acceptance criteria or validation planning",
-        "execution after story confirmation"
-      ],
-      "summary": "Confirm a user story, then turn it into tracked CLAPS delivery."
-    },
-    {
-      "name": "planning-baseline",
-      "assetDirName": "planning-baseline",
-      "category": "workflow",
-      "tags": ["chat", "convergence", "planning"],
-      "triggers": [
-        "project chat needs a planning baseline",
-        "main-agent selection or draft convergence",
-        "turning discussion into an executable plan"
-      ],
-      "summary": "Create or refine a CLAPS planning baseline from ongoing project chat."
-    },
-    {
-      "name": "preview-gateway",
-      "assetDirName": "preview-gateway",
-      "category": "workflow",
-      "tags": ["frontend", "preview", "qa"],
-      "triggers": [
-        "local UI needs a shareable URL",
-        "browser QA or design review",
-        "remote debugging through CLAPS preview"
-      ],
-      "summary": "Expose a local app through the CLAPS preview gateway."
-    },
-    {
-      "name": "project-admin",
-      "assetDirName": "project-admin",
-      "category": "workflow",
-      "tags": ["admin", "project", "repo"],
-      "triggers": [
-        "explicit project CRUD from the CLI",
-        "project archive or repo-binding edits",
-        "human session driven project administration"
-      ],
-      "summary": "List, inspect, create, archive, and bind projects through explicit CLAPS CLI commands."
-    },
-    {
-      "name": "task-detail-lookup",
-      "assetDirName": "task-detail-lookup",
-      "category": "workflow",
-      "tags": ["inspection", "lookup", "task"],
-      "triggers": [
-        "known task id needs current detail",
-        "task status or workflow cross-check",
-        "project and repo binding lookup for one task"
-      ],
-      "summary": "Fetch current CLAPS task detail, project metadata, and linked repo binding for a known task id."
-    },
-    {
-      "name": "task-admin",
-      "assetDirName": "task-admin",
-      "category": "workflow",
-      "tags": ["admin", "task", "workflow"],
-      "triggers": [
-        "explicit task CRUD from the CLI",
-        "task transition or review outside chat control lines",
-        "human session driven task administration"
-      ],
-      "summary": "Create, inspect, soft-delete, transition, and review CLAPS tasks through explicit CLI commands."
-    },
-    {
-      "name": "task-contract-draft",
-      "assetDirName": "task-contract-draft",
-      "category": "workflow",
-      "tags": ["contract", "draft", "task"],
-      "triggers": [
-        "internal CLAPS contract drafting request",
-        "agent should write back a structured task contract draft",
-        "task creation contract needs definition of done and acceptance criteria"
-      ],
-      "summary": "Draft a structured CLAPS task contract and submit it back through the explicit contract-draft CLI primitive."
-    },
-    {
-      "name": "task-stage-summary-backfill",
-      "assetDirName": "task-stage-summary-backfill",
-      "category": "workflow",
-      "tags": ["workflow", "stage", "backfill"],
-      "triggers": [
-        "internal CLAPS stage summary backfill request",
-        "agent should reconstruct missing completed-stage summaries",
-        "task detail asks the agent to backfill missing stage summaries"
-      ],
-      "summary": "Reconstruct missing completed-stage summaries from recorded task history and submit them back through the explicit stage-summary-backfill CLI primitive."
-    },
-    {
-      "name": "workspace-bootstrap",
-      "assetDirName": "workspace-bootstrap",
-      "category": "workflow",
-      "tags": ["execution", "repo", "workspace"],
-      "triggers": [
-        "repo binding validation",
-        "clone or worktree preparation",
-        "execution context setup before runtime"
-      ],
-      "summary": "Prepare clone, worktree, branch, and repo context before execution."
-    },
-    {
-      "name": "repo-binding-closure",
-      "assetDirName": "repo-binding-closure",
-      "category": "workflow",
-      "aliases": ["repo-binding"],
-      "tags": ["execution", "repo", "setup"],
-      "triggers": [
-        "repo binding is missing or stale",
-        "chat execution needs repo validation",
-        "execution context depends on repo metadata"
-      ],
-      "summary": "Recover and persist the repo contract before CLAPS bootstraps execution."
-    },
-    {
-      "name": "git-delivery",
-      "assetDirName": "git-delivery",
-      "category": "workflow",
-      "tags": ["delivery", "git", "review"],
-      "triggers": [
-        "validated diff is ready to ship",
-        "commit and push handoff",
-        "review evidence packaging"
-      ],
-      "summary": "Stage, commit, push, and hand off repo changes with review evidence."
-    },
-    {
-      "name": "review-handoff",
-      "assetDirName": "review-handoff",
-      "category": "workflow",
-      "tags": ["delivery", "qa", "review"],
-      "triggers": [
-        "task needs review-gate evidence",
-        "delivery summary back into CLAPS",
-        "approval routing after implementation"
-      ],
-      "summary": "Package validation evidence, review gates, and next reviewers for CLAPS delivery."
-    }
-  ],
-  "promptScopes": {
-    "conversation_turn": {
-      "primitives": [
-        {
-          "name": "no_reply",
-          "owner": "runtime",
-          "description": "Return the no-reply token when no response is needed so CLAPS can suppress unnecessary chat noise."
-        },
-        {
-          "name": "topic_title",
-          "owner": "runtime",
-          "description": "Emit TOPIC_TITLE when the DM thread needs a durable conversation name."
-        },
-        {
-          "name": "task_create",
-          "owner": "runtime",
-          "description": "Emit TASK_TITLE/TASK_SUMMARY plus optional CLAPS_WORKFLOW_JSON to create tracked work."
-        },
-        {
-          "name": "workflow_patch",
-          "owner": "runtime",
-          "description": "Emit UPDATE_TASK_ID with CLAPS_WORKFLOW_JSON to patch an existing task workflow instead of creating a replacement task."
-        },
-        {
-          "name": "task_start",
-          "owner": "runtime",
-          "description": "Emit START_TASK when an existing task should move into active execution now."
-        },
-        {
-          "name": "task_mutation",
-          "owner": "runtime",
-          "description": "Emit CLAPS_TASK_ACTIONS_JSON to patch, assign, transition, or merge an existing task directly."
-        },
-        {
-          "name": "follow_up_handoff",
-          "owner": "runtime",
-          "description": "Emit FOLLOW_UP_AGENT_IDS to hand the next turn to specific agents."
-        }
-      ],
-      "skills": [
-        {
-          "name": "claps-cli",
-          "reason": "This is the main CLAPS runtime playbook for turning chat into tracked delivery work.",
-          "whenAll": ["conversation_reply_mode"]
-        },
-        {
-          "name": "chat-task-delivery",
-          "reason": "No visible workflow task is in focus yet, so the agent should move from clarification into tracked CLAPS work.",
-          "whenAll": ["conversation_reply_mode", "conversation_missing_prompt_task"]
-        },
-        {
-          "name": "user-story-delivery",
-          "reason": "An existing task already uses the stricter story workflow and should follow that end-to-end playbook.",
-          "whenAll": ["conversation_reply_mode", "conversation_prompt_task_user_story_workflow"]
-        },
-        {
-          "name": "planning-baseline",
-          "reason": "Project chat has repo-backed execution potential, so the next step may be converging a planning baseline before implementation.",
-          "whenAll": [
-            "conversation_reply_mode",
-            "conversation_has_project",
-            "conversation_missing_prompt_task"
-          ]
-        }
-      ]
-    },
-    "assignment_execution": {
-      "primitives": [
-        {
-          "name": "workspace_execution",
-          "owner": "runtime",
-          "description": "CLAPS prepares the worktree and execution context; the model should focus on repo changes inside that sandbox."
-        },
-        {
-          "name": "progress_reporting",
-          "owner": "runtime",
-          "description": "CLAPS owns progress updates and execution-output streaming around the assignment run."
-        },
-        {
-          "name": "artifact_capture",
-          "owner": "runtime",
-          "description": "CLAPS records artifacts and delivery evidence based on the execution result."
-        },
-        {
-          "name": "task_stage_ledger",
-          "owner": "runtime",
-          "description": "CLAPS exposes explicit task stage primitives so the agent can create, update, complete, block, and reopen the coarse planning/execution/review/delivery ledger."
-        },
-        {
-          "name": "review_result_recording",
-          "owner": "runtime",
-          "description": "CLAPS exposes an explicit structured review-result primitive so the agent or skill can persist pass/remediate/escalate outcomes instead of hiding that decision inside runtime flow."
-        },
-        {
-          "name": "soft_guardrails",
-          "owner": "runtime",
-          "description": "CLAPS exposes review-readiness, delivery-readiness, and remediation-budget checks as callable primitives; the skill or agent decides when to invoke them and how to respond."
-        },
-        {
-          "name": "delivery_submission",
-          "owner": "runtime",
-          "description": "CLAPS owns git submit, merge-request creation, and delivery-evidence capture once the repo work is ready."
-        }
-      ],
-      "skills": [
-        {
-          "name": "claps-cli",
-          "reason": "This is the main runtime playbook for repo-backed CLAPS execution, progress reporting, and delivery evidence."
-        },
-        {
-          "name": "git-delivery",
-          "reason": "Once implementation and minimal validation exist, the fastest path to review is staging, committing, pushing, and handing off concrete delivery evidence."
-        },
-        {
-          "name": "user-story-delivery",
-          "reason": "This assignment is still in story confirmation, so the stricter story-completion loop should finish before repo execution starts.",
-          "whenAll": [
-            "assignment_workflow_user_story_delivery",
-            "assignment_workflow_story_confirmation"
-          ]
-        },
-        {
-          "name": "assignment-kickoff-orchestration",
-          "reason": "Ownership, kickoff, and the first reporting loop must become explicit instead of staying implicit in a prepared branch/worktree.",
-          "whenAny": [
-            "assignment_execution_context_missing",
-            "assignment_execution_context_prepared",
-            "assignment_pending"
-          ]
-        },
-        {
-          "name": "execution-context-recovery",
-          "reason": "The execution context may need repair or stabilization while work is already in flight.",
-          "whenAny": [
-            "assignment_execution_context_failed",
-            "assignment_execution_context_running"
-          ]
-        },
-        {
-          "name": "planning-session-convergence",
-          "reason": "The execution plan may still be under-specified, so the agent should converge scope and next steps instead of guessing.",
-          "whenAny": [
-            "assignment_workflow_story_confirmation",
-            "assignment_workflow_plan_missing",
-            "assignment_workflow_plan_empty"
-          ]
-        }
-      ]
-    }
-  }
-}

package/skills/merge-closeout/SKILL.md

@@ -1,46 +0,0 @@
----
-name: merge-closeout
-description: >
-  Use this skill when CLAPS work has already reached reviewable repo state and
-  now needs merge readiness, post-approval closeout, status sync back into the
-  task or conversation, and explicit completion or follow-up handling.
-tags:
-  - delivery
-  - merge
-  - review
----
-
-# merge-closeout
-
-Use this skill after implementation and review handoff are done, when the remaining risk is closing the loop cleanly instead of writing more code.
-
-## Goals
-
-- Turn approved repo work into a completed CLAPS outcome.
-- Keep merge, deploy, and conversation status aligned.
-- Surface blockers clearly when approval, CI, or provider actions are still pending.
-
-## Flow
-
-1. Confirm merge readiness
-Check the branch, review state, required validations, and whether any blocking comments or failing checks remain.
-
-2. Capture the landing action
-Record whether the change should be merged now, queued behind another dependency, or left for a human approver.
-
-3. Sync task state
-Update the CLAPS task, assignment, or conversation summary with the final repo outcome:
-- merged
-- awaiting approval
-- blocked on CI
-- blocked on provider action
-
-4. Close the loop
-Post the final summary with what landed, what was validated, and what remains after merge, such as deploy verification or rollout watch.
-
-## Guidance
-
-- Do not claim the work is complete when the branch is only pushed.
-- Keep merge blockers explicit and actionable.
-- If merge automation is unavailable, still leave exact branch, MR, and next-owner context behind.
-- If deployment is part of done, hand off explicitly to the deploy or canary workflow instead of implying it happened automatically.

package/skills/merge-closeout/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "merge-closeout"
-  short_description: "Close the loop after review with merge-ready status and task sync"
-  default_prompt: "Use merge-closeout when a CLAPS task is already reviewable and now needs merge readiness, post-approval state sync, and a clean final handoff."

package/skills/planning-baseline/SKILL.md

@@ -1,43 +0,0 @@
----
-name: planning-baseline
-description: >
-  Use this skill when a CLAPS project thread or execution lane needs a planning
-  baseline, including first-pass scope capture, main-agent selection, draft
-  convergence, and turning discussion into an executable plan.
----
-
-# planning-baseline
-
-Use this skill when project chat has enough signal to stop being vague discussion and start becoming an execution baseline.
-
-## Goals
-
-- Turn scattered project chat into a concrete planning baseline.
-- Capture the minimum useful scope, constraints, and open questions before execution starts.
-- Surface whether a main agent should own convergence or whether more discussion is still needed.
-
-## Flow
-
-1. Read the current thread state
-Collect the problem statement, intended outcome, constraints, decisions already made, and any blocking ambiguities still visible in chat.
-
-2. Define the baseline
-Write the baseline around user value, delivery boundary, validation path, and the smallest coherent execution slice.
-
-3. Choose ownership
-If one agent should drive convergence, make that explicit. If the conversation still needs human input, say exactly what is missing instead of pretending the plan is ready.
-
-4. Separate open questions from scope
-Do not bury unresolved decisions inside the main plan. Keep them as explicit questions, risks, or follow-up items.
-
-5. Hand off to tracked execution
-Once the baseline is coherent, move the work into the relevant CLAPS task or planning session so later execution is anchored to a stable plan.
-
-## Guidance
-
-- Prefer a narrow executable baseline over a broad aspirational outline.
-- If repo binding, validation strategy, or ownership is unclear, mark that explicitly.
-- When the project already has a planning baseline, refine it instead of replacing it wholesale.
-- Keep the baseline compatible with later `workspace-bootstrap`, `user-story-delivery`, and `review-handoff` steps.
-
-Read [references/state-examples.md](references/state-examples.md) when you need the current planning-session fields, commit transition, or the handoff shape into repo binding and execution context.

package/skills/planning-baseline/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "planning-baseline"
-  short_description: "Create or refine a CLAPS planning baseline from project chat"
-  default_prompt: "Use planning-baseline when a CLAPS project thread needs scope capture, main-agent selection, draft convergence, and an execution-ready baseline."

package/skills/planning-baseline/references/state-examples.md

@@ -1,75 +0,0 @@
-# Planning Baseline State Examples
-
-Use this note when `planning-baseline` needs the current CLAPS object shape instead of relying on memory.
-
-## Planning Session Contract
-
-Current request fields:
-
-- `projectId`: nullable on create, but project chat usually passes the active project id.
-- `mainAgentId`: required agent that should own convergence.
-- `title`: short baseline title.
-- `goal`: nullable summary of the intended outcome.
-
-Current stored states:
-
-- `draft`: initial planning baseline.
-- `committed`: baseline accepted and ready to anchor later execution.
-- `archived`: historical baseline that should not drive new execution.
-
-Important stored fields after creation or commit:
-
-- `latestSummary`: newest committed summary.
-- `committedAt`: set when the session moves to `committed`.
-- `updatedAt`: use this to decide whether a later draft actually replaced the baseline.
-
-## Typical Flow
-
-1. Create a draft planning session for the active project and chosen main agent.
-2. Refine the title, goal, scope boundary, validation path, and open questions.
-3. Commit the session with a short summary once the baseline is executable.
-4. Use the committed session as the source for repo binding and later execution-context preparation.
-
-## API Example
-
-Create:
-
-```json
-{
-  "mainAgentId": "agent_123",
-  "title": "Plan the repo loop",
-  "goal": "Produce a repo-bound execution plan"
-}
-```
-
-Commit:
-
-```json
-{
-  "summary": "Committed the first task contract draft."
-}
-```
-
-Committed response shape to expect:
-
-```json
-{
-  "session": {
-    "projectId": "project_123",
-    "mainAgentId": "agent_123",
-    "status": "committed",
-    "latestSummary": "Committed the first task contract draft."
-  }
-}
-```
-
-## Handoff Expectations
-
-Once a planning baseline is committed, the next CLAPS-native questions are usually:
-
-- Is there a `project_repo_binding` yet?
-- Is the default branch known?
-- Does the repo need a monorepo `rootPath`?
-- Is there already an assignment that can own the first `execution_context`?
-
-Do not pretend planning is complete if those execution handoff questions are still blockers. Keep them explicit so `workspace-bootstrap` and `execution-context-recovery` inherit a stable baseline instead of a vague conversation.

package/skills/planning-session-convergence/SKILL.md

@@ -1,50 +0,0 @@
----
-name: planning-session-convergence
-description: >
-  Use this skill when project or channel chat has already produced planning
-  fragments, but CLAPS still lacks one converged planning_session or baseline
-  that a main agent can execute from. This covers reconciling competing drafts,
-  locking the execution boundary, naming the owner, and handing the result into
-  planning-baseline or repo execution without losing the good parts of chat.
-tags:
-  - chat
-  - convergence
-  - planning
----
-
-# planning-session-convergence
-
-Use this skill when planning is happening in public and the problem is no longer "what should we discuss?" but "which plan is now real enough to execute?"
-
-## Goals
-
-- Collapse overlapping planning fragments into one reusable CLAPS planning contract.
-- Preserve the good ideas from channel discussion without leaving the operator with multiple half-valid drafts.
-- Hand off to `planning-baseline`, `repo-binding-closure`, or `workspace-bootstrap` with one clear owner and next step.
-
-## Flow
-
-1. Read the current planning state
-Collect the latest planning baseline, main-agent choice, open questions, repo assumptions, validation target, and any competing proposals still floating in chat.
-
-2. Separate solved from unresolved
-Call out:
-- what the team already agrees on
-- which decisions are still blocking execution
-- where two drafts disagree on scope, ownership, repo, or validation
-
-3. Force convergence
-Pick the narrowest plan that is executable now, or ask the smallest remaining questions needed to get there.
-
-4. Write back one source of truth
-Update the planning baseline or planning session so later agents do not need to infer "which draft won" from chat history.
-
-5. Route the next step explicitly
-Hand off to `repo-binding-closure`, `execution-context-recovery`, or the normal delivery path based on the remaining blocker.
-
-## Guidance
-
-- Do not let multiple planning drafts coexist once execution is about to start.
-- Preserve strong ideas as explicit options or follow-up tasks instead of losing them in summary prose.
-- If ownership is still unclear, stop and resolve that before pretending the plan is converged.
-- If the only remaining disagreement is sequencing, choose the smallest executable slice and record the rest as follow-up.

package/skills/planning-session-convergence/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "planning-session-convergence"
-  short_description: "Converge competing planning fragments into one executable CLAPS baseline"
-  default_prompt: "Use planning-session-convergence when project or channel chat has multiple planning fragments and CLAPS needs one converged planning baseline, owner, and next step before execution."

package/skills/preview-gateway/SKILL.md

@@ -1,58 +0,0 @@
----
-name: preview-gateway
-description: >
-  Use this skill when a local web app needs a shareable CLAPS preview URL for
-  browser QA, design review, or remote debugging through the preview gateway.
----
-
-# preview-gateway
-
-Use this flow when an agent needs to expose a localhost web service through CLAPS for browser preview or design or QA review.
-
-## Recommended flow
-
-1. Start the local web service
-Run the app locally and confirm it responds before exposing it.
-- Typical example: `localhost:8000`
-- If the app is not reachable locally first, the CLAPS preview URL will not fix it.
-
-2. Register and expose
-Run `claps-cli preview expose --app-slug my-app --port 8000`.
-- Make sure `CLAPS_AGENT_TOKEN` is present first.
-- Use a stable `app-slug` for repeated QA or design review runs.
-- If you need to override the deployed gateway host, also set `CLAPS_GATEWAY_BASE_URL`.
-
-3. Keep the tunnel open
-The command registers the preview app with CLAPS, prints the public URL, and keeps the reverse tunnel alive for both HTTP and websocket traffic.
-
-4. Share the public URL
-Use the returned gateway URL for browser testing, QA, or design review.
-- After the URL is live, hand off to the relevant playbook such as `qa`, `design-review`, or `design-consultation`.
-- If the preview is meant to support repo delivery, include the URL in task updates or review evidence.
-
-5. Inspect or clean up registrations
-Use the lifecycle commands when you need to verify or close a preview registration.
-- `claps-cli preview list` shows the registered preview apps for the current actor.
-- `claps-cli preview status --app-id <id>` shows whether the gateway currently sees the reverse tunnel as online or offline.
-- `claps-cli preview remove --app-id <id>` removes a stale registration after the preview is no longer needed.
-
-6. Stop the preview
-Terminate the command when you no longer want the preview to be reachable.
-
-## Validation checklist
-
-Before treating the preview as usable, confirm all of the following:
-
-- the local app is reachable on the expected host and port
-- `claps-cli preview expose ...` prints a public URL without auth or registration errors
-- `claps-cli preview list` or `preview status` shows the registration you just created
-- the public URL loads the intended page, not just the tunnel landing response
-- websocket features still work if the app depends on them
-
-## Common failure modes
-
-- Missing `CLAPS_AGENT_TOKEN`, which prevents preview registration entirely
-- Exposing the wrong port or host, especially when the app is not actually listening on `127.0.0.1`
-- Closing the CLI process and forgetting that the preview URL dies with it
-- Forgetting to remove stale preview registrations after the tunnel process is gone
-- Sharing the URL before checking that the tunneled page matches the local app state

package/skills/preview-gateway/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "preview-gateway"
-  short_description: "Expose a local app through the CLAPS preview gateway"
-  default_prompt: "Use preview-gateway when local UI work needs a shareable CLAPS URL for browser testing, QA, or design review."

package/skills/project-admin/SKILL.md

@@ -1,44 +0,0 @@
----
-name: project-admin
-description: >
-  Use this skill when a user wants explicit CLAPS project administration from
-  the CLI: listing projects, fetching one project, creating a project,
-  archiving a project, or reading/updating a project repo binding with a human
-  session token.
-tags:
-  - admin
-  - project
-  - repo
----
-
-# project-admin
-
-Use this skill when the operator wants deterministic project commands instead of a chat-driven workflow.
-
-## Command surface
-
-```bash
-claps-cli session login [--email <email>] [--display-name <name>] [--org-id <id>] [--org-slug <slug>]
-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>]
-```
-
-## Flow
-
-1. If the caller does not already have a human session token, mint one first with `claps-cli session login`.
-2. Use `claps-cli projects` for discovery and `claps-cli project get` when one project needs an authoritative snapshot.
-3. Use `claps-cli project create` for deterministic setup instead of creating placeholder projects in chat.
-4. Use `claps-cli project repo-binding get|set` when the task is explicit repo contract administration, not a broader execution rescue workflow.
-5. Use `claps-cli project archive` when the caller really means soft-delete/archive. Do not describe this as a hard delete.
-
-## Rules
-
-- Prefer this skill when the user wants a direct project mutation with known parameters.
-- Prefer `repo-binding-closure` when execution is blocked and the repo contract must be recovered in context, not simply edited as a project admin action.
-- Prefer `planning-baseline` when the real bottleneck is project shaping or planning-session convergence rather than project metadata mutation.
-- Be explicit that project deletion is currently archive semantics.
-- Do not invent a project update command; the current explicit CLI surface does not expose one yet.