violin-tools

Triggers on intent-to-run-the-pipeline phrases. Use when the user says "run the feature pipeline", "start the pipeline for X", "kick off the orchestration", "automate feature X end-to-end", "feature pipeline", "run the pipeline for X", "start the orchestration", or "pipeline a new feature". Does NOT trigger on "create an issue", "review a PR", "open a PR", "merge a branch", or "deploy" — those stay in their own skills.

Use when reviewing WIP Figma frames for a feature before any issues or code are created — the pre-code design gate. Triggers on: - "review the Figma design for feature X" - "approve the WIP frames for X" - "design review before issue creation" - "gate the pipeline on the Figma design" - "check the Figma frames before we create issues" - "run the pre-code Figma review for X" - "does the Figma design pass the design system check?" - "review the WIP page frames before coding starts" Does NOT trigger on: - "review the PR" → use `reviewing` (PR diff review) - "review the built UI" → use `design-reviewer` (Playwright/built-UI pass) - "build the frames" → use `figma-design` (P8, the frame builder) - "implement the component" → use the implementer skill - "update DESIGN.md tokens" → out of scope for this skill - "judge whether code matches the design" → use `design-reviewer` <example> Context: The feature-pipeline engine is at phase 4 (pre-code Figma review) for feature "tuner-display". The figma-design (P8) skill

Use when a new feature needs a research-backed epic spec synthesized into tmp/docs/ before child issues are drafted. Triggers on "research and write the epic", "author the epic spec", "write the feature epic", "run the research phase for the epic", "synthesize a feature brief into an epic", "draft the epic from the brainstorm brief", "produce the epic spec for issue fan-out", "build the epic for this feature", "epic research for <feature>", or "I need an epic spec before filing child issues". Invoke when phase(2) of the feature pipeline fires, when the caller has a brainstorm brief and needs a structured epic before calling issue-authoring, or when any session asks to research and produce an epic spec for a new product feature. Self-contained for worktree dispatch — all hard constraints restated in-body.

Use when building or modifying Figma frames for a feature before any issues or code are created. Triggers on: - "build the Figma frames for feature X" - "create the WIP design page for X" - "design feature X in Figma" - "lay out the screens in Figma before issue creation" - "build the pre-code design for X" - "create WIP frames for the X feature" - "set up the Figma WIP page for X" - "place the designs for X on the WIP page" Does NOT trigger on: - "review the Figma design" → use `reviewing-figma-designs` (P9) - "approve the Figma frames" → use `reviewing-figma-designs` (P9) - "implement the component" → use the implementer skill - "update DESIGN.md tokens" → DESIGN.md edits are out of scope for this skill - "judge whether the frames are correct" → use `reviewing-figma-designs` (P9) - "does this design pass?" → use `reviewing-figma-designs` (P9) <example> Context: The feature-pipeline engine is at phase 3 (pre-code Figma design) for feature "tuner-display". user: "Build the Figma frames for tuner-display fro

Asset-specific review pass for pipeline skills, agents, and the dashboard server in julianken/violin-tools. Use when reviewing a pipeline skill PR, reviewing the epic-authoring skill, reviewing the feature-pipeline workflow, reviewing the dashboard server (P2), reviewing a pipeline agent, asset review for the pipeline, or when @julianken-bot needs to review any P2/P3/P5/P6/P8/P9 asset PR. <example> Context: PR for the epic-authoring skill (P3) is open. user: "Review the P3 epic-authoring skill PR with asset checks" assistant: "Dispatching reviewing-pipeline-assets — apply R1–R12 first (reviewing/SKILL.md), then A1–A6 asset checks against the skill frontmatter, trigger corpus, evals, and mirror state." </example> <example> Context: PR for the feature-pipeline workflow engine (P5) is open. user: "Run the pipeline asset review on PR #111" assistant: "Applying reviewing-pipeline-assets: R1–R12 base rubric first, then A3/A5/A6 (A1/A2/A4 N/A for a .js workflow with no frontmatter description)." </example> <examp

Use when reviewing a PR diff on julianken/violin-tools and you need the anti-slop rubric — verify-before-claim, ≤3 findings, severity tiers, mandatory second pass, prompt-injection defense. Bot-agnostic: applies whether a human or any bot identity posts the review. Triggers on "review this diff", "anti-slop review", "review rubric", "what severity is this finding". Self-contained for worktree dispatch; carries no credentials.

Use when creating a PR, dispatching a review, or merging on `julianken/violin-tools` (local folder `violin-scales/`). Triggers on "create PR", "open PR", "merge PR", "review PR", "dispatch the bot", "julianken-bot", "ship this branch", "squash-merge", "Mergify", "queue". Self-contained because a worktree-isolated subagent does NOT load CLAUDE.md / AGENTS.md, so the PR/review/merge rules it needs are restated here in-body. Merges go through Mergify's queue (`@Mergifyio queue`).

Use when drafting a PR body or deciding what goes in the description on julianken/violin-tools. Triggers on "draft a PR description", "what should the PR body say", "fill the PR template", "PR body sections", or a PR that came back with template-shaped feedback. The generic five-section method, conventional-commit rules, and plan-reference discipline — bot-agnostic, no credentials. Self-contained for worktree dispatch.

Use when opening or rewriting an implementation issue or plan spec on julianken/violin-tools. Triggers on "create issue", "write the issue", "issue spec", "implementation plan issue", or batch prep/planning work. Self-contained for worktree dispatch.

Use when reviewing an implementation issue or plan spec before work starts, posting as @julianken-bot. Triggers on "approve the issue spec", "plan review", "review issue

Use when a fresh agent or human session needs to orient in this repo before doing work — confirm the instance is coherent (paths exist, pointers resolve, no contradictions with DESIGN.md). Triggers on "bootstrap", "orient in this repo", "where do I start", "validate the instance", "is this repo coherent", "get my bearings". Self-contained for worktree dispatch. Validate mode only; fill mode is documented but not implemented.