@triclaps/cli 0.0.3 → 0.0.5

package/skills/user-story-delivery/SKILL.md

@@ -1,76 +0,0 @@
----
-name: user-story-delivery
-description: >
-  Use this skill when chat requests should be reframed into a confirmed user
-  story, broken into tracked work, implemented in a repo workspace, and
-  delivered with review evidence.
----
-
-# user-story-delivery
-
-Use this flow when chat is the primary surface and the request should become tracked delivery work in CLAPS.
-
-## Recommended flow
-
-1. User story creation
-Confirm the target end-user experience before talking about implementation.
-- Capture the user narrative, desired experience, validation plan, acceptance criteria, edge cases, and explicit out-of-scope boundaries.
-- If repo execution is likely, also confirm what evidence should exist at delivery time: docs, screenshots, review notes, commits, preview URLs, or QA output.
-- If the story is still fuzzy, ask the smallest set of decision-driving questions instead of guessing.
-
-2. Task breakdown
-Turn the confirmed story into tracked execution work.
-- Move the task workflow from `story_confirmation` into `task_breakdown` only after the story is clear enough to execute.
-- Write a concrete plan that covers docs updates, task shaping, data flow, interaction/layout thinking, implementation, self-check, and delivery evidence.
-- Call out assumptions, dependencies, and anything that could block repo execution or review.
-- Once the story is already confirmed and the workflow is in `task_breakdown` or `execution`, do not restart the story-creation loop unless the brief is contradictory or materially incomplete.
-
-3. Execution
-Implement inside the prepared workspace.
-- Create the supporting docs and artifacts needed for later review, not just code changes.
-- Keep progress visible with task updates instead of waiting until the very end.
-- If repo binding, execution context, preview access, or runtime setup is missing, surface that blocker explicitly.
-
-4. Self-check
-Before delivery, verify the work against both the acceptance criteria and the intended end-user experience.
-- Prefer concrete evidence over generic claims.
-- Re-read the original user story and confirm that the shipped result still matches it.
-- If the story drifted during implementation, update the task workflow and explain why.
-
-5. Review gates
-Run or prepare evidence for gstack review gates when available:
-- `plan-eng-review`
-- `plan-design-review`
-- `design-consultation`
-- `design-review`
-- `review`
-- `qa`
-- `document-release`
-
-Default gate-to-skill mapping once implementation is ready:
-- `eng_review` -> `review`
-- `design_review` -> `design-review`
-- `qa` -> `qa`
-
-Before final delivery submission, proactively run the pending mapped review gates as a self-check and fix any in-scope findings before handing off.
-
-6. Delivery
-Hand off with a concise summary of what changed, how the end-user experience was validated, and any remaining risks or follow-up items.
-
-## Definition of done
-
-Treat the flow as complete only when all of the following are true:
-
-- the user story is explicit enough that another agent or reviewer could restate it without guessing
-- the workflow phase reflects reality instead of staying stuck in `story_confirmation`
-- implementation artifacts exist in the repo or task record
-- review evidence exists for the relevant eng, QA, and design gates
-- the final handoff says what changed, how it was validated, and what still needs human review
-
-## Common failure modes
-
-- Jumping straight into coding before the user story is clear enough to validate
-- Reopening story confirmation after the user already confirmed scope, burning the execution window on work that is no longer the bottleneck
-- Treating a task title as a complete story even though desired experience and boundaries were never confirmed
-- Shipping code without updating workflow state, review gates, or delivery evidence
-- Claiming “done” with no proof that the user-facing experience actually improved

package/skills/user-story-delivery/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "user-story-delivery"
-  short_description: "Confirm a user story, then turn it into tracked CLAPS delivery"
-  default_prompt: "Use user-story-delivery to confirm the desired experience, break the work down, execute it, self-check it, and hand off with evidence."

package/skills/workspace-bootstrap/SKILL.md

@@ -1,41 +0,0 @@
----
-name: workspace-bootstrap
-description: >
-  Use this skill when CLAPS work needs a repo-backed workspace prepared before
-  execution, including clone, worktree, branch naming, root-path handling, and
-  repo binding validation.
----
-
-# workspace-bootstrap
-
-Use this skill when execution needs a real workspace, not just a prompt.
-
-## Goals
-
-- Validate that repo binding details are present before starting runtime execution.
-- Prepare a clean worktree and branch without corrupting the main checkout.
-- Surface missing repo metadata or git auth as explicit blockers.
-
-## Flow
-
-1. Confirm repo binding
-Make sure the task or project includes repo URL, default branch, repo name, and any monorepo root path.
-
-2. Build the workspace path
-Use the stable workspace root plus repo name and task slug so repeated runs land in predictable paths.
-
-3. Prepare the base clone
-Clone the repo when the base checkout does not exist yet. Reuse it when it is already present.
-
-4. Create the execution branch and worktree
-Create the branch from the configured default branch, then attach a dedicated worktree for the task instead of mutating the base clone.
-
-5. Hand off execution context
-Pass the prepared worktree path, branch name, and repo context into the runtime invocation and later delivery steps.
-
-## Guidance
-
-- Treat missing repo binding as a blocker worth reporting immediately.
-- Prefer deterministic branch and worktree naming over ad hoc paths.
-- Keep the base clone stable; execution should happen inside the task worktree.
-- If the workspace already exists, reuse or repair it instead of recloning blindly.

package/skills/workspace-bootstrap/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "workspace-bootstrap"
-  short_description: "Prepare clone, worktree, branch, and repo context before execution"
-  default_prompt: "Use workspace-bootstrap when CLAPS delivery needs repo binding validation plus deterministic clone, worktree, and branch preparation."