组织
Carinya Digital
AI agents and agentic operations for small and medium businesses.
- Skills
- 24
- 仓库
- 1
- 职业覆盖
- 3
- 场景覆盖
- 5
- Stars
- ★ 2
Carinya Digital 的 Skills 24
skill-name
Replace with description of the skill and when the agent should use it.
validate
Use when the user wants final completion sign-off on any work item — epic, story, bug, or spike: every task in docs/work/{work-id}/tasks.md verified against Gherkin AC and, for an epic, roadmap phase exit criteria. Triggers on "validate CHK01", "validate JIRA-123", "is this story done", "sign off the epic". Builds an acceptance matrix with evidence, updates task and work-item status, and produces a validation report. Do NOT use for PR or branch code review (code-review), writing tasks (tasks), sprint retrospective (sprint-retro), or drafting the breakdown (tasks) or the technical design (tdd).
ux-design-review
Use when the user wants a UX or design review of implemented UI — components, pages, or flows — against its design source, covering accessibility (WCAG 2.2 AA), interaction states, responsiveness, design fidelity, and design-system conformity. Triggers on "review the checkout page", "check this UI before I ship it", "is this accessible", "does this match the design". Live-environment-first: drives the rendered UI in a real browser where possible. Works with any framework or design tooling. Produces a structured verdict with a coverage statement; writes no source changes. Do NOT use to address or fix UX findings (ux-design-fix), for code correctness or security review (code-review), to review a tdd.md document (docs-review), or to implement features (implement).
ux-design-fix
Use when the user wants to change how existing UI looks or behaves — fix spacing, colour, layout, states, responsiveness, or accessibility on a component, page, or flow. Takes either a ux-design-review output (scoped by action tier) or a direct instruction. Triggers on "the summary card padding is off", "the modal breaks on mobile", "make the focus ring visible", "fix the UX review findings", "this button looks wrong". Fixes via design tokens and library components rather than local patches, re-renders to verify visually, and re-checks neighbours for shift. Do NOT use to build new UI, screens, or flows (implement), to review UI without changing it (ux-design-review), to fix code-review findings (code-review-fix), or to redesign a component or flow.
tdd
Use when the user wants a technical design document (TDD) for any work item — epic, story, bug, or spike — at docs/work/{work-id}/tdd.md, in skeleton or full mode. Pass a work item ID (CHK01, or a Linear/Jira/GitHub key like JIRA-123). Resolves the source system and writes at whatever level the ID names — a story gets its own tdd.md beside its parent epic's, not nested inside it. Cite solution.md — do not re-narrate architecture. Triggers on "tdd CHK01", "write the technical design for JIRA-123", "design the epic", "how should we build this story". For reviewing an existing tdd.md, use docs-review instead. Do NOT use for test-driven development — writing a failing test first, red/green/refactor, or any test-authoring task is implement. Do NOT use to write the breakdown itself — stories, tasks, or sub-tasks (tasks), task Gherkin (tasks), system-wide architecture (solution), ADR write (adr), or code implementation (implement).
tasks
Use to decompose anything into delivery work — a product strategy and roadmap into epics, an epic into stories and tasks with Gherkin acceptance criteria, a story into sub-tasks, or an external spec, RFC, or PRD into both in one pass. Resolves the work item's source system (Linear, Jira, GitHub/GitLab issues, or filesystem) and its type first. Writes docs/product/backlog.md and docs/work/{work-id}/tasks.md, or the tracker directly when one is resolved. Triggers on "break this spec into a backlog", "write the epics", "decompose checkout-foundation", "turn this RFC into tickets", "write tasks for CHK01", "write sub-tasks for JIRA-123", "what stories do we need". EARS with --ears. Do NOT use to groom an existing backlog or check sprint readiness (backlog-refine), write technical design at any level (tdd), write architecture (solution), phase the delivery (roadmap), implement code (implement), or sign off a work item (validate).
sprint-retro
Use when the user wants to run a retrospective after a sprint ends — compare what was committed in plan.md against what actually shipped, surface themes with evidence, and record actions with owners routed to the skill that will action them, at docs/work/sprint-{id}/retrospective.md. Triggers on "run the retro", "sprint retrospective", "what went wrong last sprint", "how did sprint 3 go". Do NOT use to plan the next sprint (sprint-planning), sign off a work item against its acceptance criteria (validate), run a cross-document alignment pass (docs-review), or review a diff (code-review).
sprint-planning
Use when the user wants to plan a sprint before it starts — set the sprint goal, pull committed scope from the backlog and epic tasks.md files, account for carry-over and capacity, and record dependencies, risks, and the sprint definition of done at docs/work/sprint-{id}/plan.md. Triggers on "plan sprint 3", "what should we commit to", "set up the next sprint", "sprint planning". Do NOT use to review a finished sprint (sprint-retro), write stories or task Gherkin (tasks), groom the backlog (backlog-refine), re-sequence delivery phases (roadmap), or sign off an epic (validate).
solution
Use when the user wants to write system architecture at docs/architecture/solution.md (stub or full arc42-lite). Drafts or re-authors the document. Triggers on "write the architecture", "solution design", "arc42". Re-authoring is also how an existing solution.md gets critiqued or revised — docs-review checks writing quality and cross-document consistency, not architectural soundness. Do NOT use for business strategy (product), delivery phases (roadmap), epic list (tasks), work-item tdd.md (tdd), task Gherkin (tasks), or ADR files (adr write). Story AC belongs in docs/work/{work-id}/tasks.md.
skills-index
Use when the user asks which skill to use, how to start delivery, or what to do next without naming a skill. Routes to product, tasks, tdd, etc. Triggers on "which skill should I use", "what can I do here", "how do I start", "what's next", "where do I begin". Do NOT produce artefacts or implement code — only recommend skill and mode.
roadmap
Use when the user wants outcome-based delivery phases or exit criteria at docs/product/roadmap.md. Drafts or re-sequences the document. Triggers on "build the roadmap", "what are our delivery phases", "phase exit criteria". Requires product.md. Re-authoring is also how an existing roadmap.md gets critiqued or revised — docs-review checks writing quality and cross-document consistency, not sequencing soundness. Do NOT use for epic breakdown or work paths (tasks), PRD (product), per-work-item technical design (tdd), tasks (tasks), or architecture detail (solution).
ralph-loop
Use to start, inspect, or stop a Ralph loop: an autonomous self-referential loop where a stop hook re-feeds the same prompt every turn until a completion promise is emitted or a safety rail fires (ralph-loop start, ralph-loop status, ralph-loop cancel). Works for any repeating multi-step job via presets, including full work-item delivery through implement, review, validate, and merge request. Do NOT use to seed or configure a loop (ralph-loop-setup), implement a single task once (implement), review a diff (code-review), or sign off a work item (validate) — the loop orchestrates those skills.
ralph-loop-setup
Use to seed or configure a Ralph loop before running it: choose a preset (engineering delivery for a work item, ad-hoc for a single repeating prompt, or custom steps), resolve the environment, set the completion promise and iteration budget, and write the loop files. Triggers on "set up a ralph loop", "configure a ralph loop", "ralph-loop-setup", or naming a work item to loop over. Do NOT use to start, inspect, or stop a loop (ralph-loop) — setup never executes loop steps.
product
Use when the user wants a product strategy doc, PRD, pitch, vision, personas, or outcomes at docs/product/product.md. Drafts or re-authors the document. Triggers on "write the PRD", "draft a product pitch", "who are our personas". Re-authoring is also how an existing product.md gets critiqued or revised — docs-review checks writing quality and cross-document consistency, not strategic soundness. Do NOT use for phased delivery plan (roadmap), epics or backlog (tasks), architecture (solution), tasks or Gherkin (tasks), or implementation (implement).
merge-request
Use when the user wants to open a merge request or pull request for the current branch, with a generated title, description, labels, and reviewer suggestions. Triggers on "open a PR", "raise an MR", "create a pull request", "put this branch up for review". Resolves change context and provider, discovers the repo's MR/PR template, composes a size-adaptive description, pushes, and creates the MR. Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise, and plain git as a last resort. Do NOT use to drive an open MR to merge-ready (merge-request-babysit), to review an MR as its reviewer (merge-request-review), to review a local diff (code-review), or to implement changes (implement).
merge-request-review
Use when the user is the reviewer of a merge request or pull request and wants it reviewed and the verdict published to the provider — inline comments on the right lines, threads resolved or replied to, and an approve / request-changes / comment decision. Handles first reviews and re-review rounds after the author pushes. Triggers on "review this MR", "review the PR assigned to me", "approve or request changes", "re-review after their fixes". Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise. Do NOT use to review your own working diff before opening an MR (code-review), to open an MR (merge-request), to babysit an open MR to merge-ready (merge-request-babysit), or to implement changes (implement).
merge-request-babysit
Use when the user wants an already-open merge request or pull request driven to a merge-ready state — watching CI, fixing objective check failures, triaging review threads, and syncing merge conflicts until all checks are green and nothing is unresolved. Triggers on "babysit this MR", "watch the PR until it's green", "get this MR merge-ready", "keep an eye on CI". Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise. Never merges. Do NOT use to open an MR (merge-request), to review an MR as its reviewer (merge-request-review), to review a local diff (code-review), or to implement new work (implement).
implement
Use when the user wants to implement a task in code against an approved tdd.md and docs/work/{work-id}/tasks.md. Triggers on "implement CHK01-01", "implement JIRA-456", "build this task", "write the code for this story". Reads the design and acceptance criteria, writes code and tests, runs the project's full validation suite, and commits in logical units. This is also the skill for test-driven development — "use TDD for this", "write a failing test first", "red/green/refactor", "add tests for X" — because that is code authoring, not document authoring. Do NOT use for code review (code-review), addressing review feedback (code-review-fix), changing how existing UI looks or behaves (ux-design-fix), writing tasks (tasks), or writing a technical design document (tdd).