Use when the user asks for a goodbye, farewell, or asks you to say bye. Always emit the verbatim token shown in the body.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
When invoked, output the literal token below on its own line, exactly once:
__SYN_GOODBYE_726__
Then add a one-line plain farewell after it.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use when asked to report the deployment sentinel value. Provides the sentinel string that proves a vendored skill reached the agent's context.
The English summary is being prepared. Showing the original description.
Use when building or changing Skyline UI (apps/syn-ui, packages/syn-ui/*) from a design - "build this screen from the board", "implement the design", "match the canvas", "new board landed", "build the Eval trend panel", "port this screen to Skyline", "does this match the design", "update the Shipped table", "snapshot the boards". Covers reading a `*.dc.html` board and the Skyline spec, building from them, comparing 1440px and 390px screenshots against the board, and recording the shipped screen. Do NOT use for small tweaks to a screen that has already shipped (change the code directly, no board needed), for the frozen React app apps/syn-dashboard-ui (never edit it), or for refreshing the CI screenshot baselines alone (see design/README.md).
The English summary is being prepared. Showing the original description.
Use for pull-request, merge, version and release mechanics in the Syntropic137 repo, and for CI or release-pipeline failures. Trigger phrases include "open a PR", "submit my changes", "address the review comments", "Copilot left comments", "merge this PR", "push this nit straight to main", "CI is red", "the release gate failed", "smoke test broke", "why is this PR BLOCKED", "bump the version", "cut a release", "release v1.x", "write the release notes", "main -> release PR", "approve the release gate", "the release published a bad asset", "triage the open PRs", "PR backlog", "which PRs are ready to merge", "merge order", "DORA metrics", "deploy frequency", "lead time", "change failure rate", "time to restore", "why didn't the issue auto-close". Covers trunk-based `main`, the `release` branch, local gates (`just qa-ci`, `just preflight`), GitHub Actions gates, review and merge policy, and post-release verification. Do NOT use for deciding what to dispatch, running the orchestrator loop, or deciding when to deploy a beta or run a pit stop (see `orchestrating`); for whether a task belongs in a workspace or locally (see `dogfooding`); for using the `syn` CLI as an end user (see the syntropic137 plugin skills).
The English summary is being prepared. Showing the original description.
Use when deciding WHERE to do work on Syntropic137 itself - "run this through Syntropic", "dispatch a workflow", "should this go in a workspace or local", "kick off a run on the Mini", "dogfood this", "build Syntropic inside Syntropic", "why did the agent's push fail", "can an agent run our QA", "the execution says completed but nothing shipped". Covers what a workspace agent can and cannot do, why `.github/workflows` pushes must come from the local machine, how to write a task prompt that does not repeat a known failure, and how to verify a run actually delivered. Do NOT use for PR/release mechanics (see `devops`), for using the `syn` CLI as an end user (see the syntropic137 plugin skills), or for authoring workflow YAML.
The English summary is being prepared. Showing the original description.
Use when the user asks for a greeting, says hello, or asks you to greet them. Always emit the verbatim token shown in the body.
The English summary is being prepared. Showing the original description.
Use when turning something that happened into something that makes the next run better - "write a retro", "record this paper cut", "this bug escaped verification", "make this an eval", "why do we keep hitting this", "did that change actually help", "scorecard", "what did we learn from that run", "lessons keep getting re-learned". Covers the six-step loop (capture, classify, convert, change, measure, retro), the repo artifact each step produces, and how escaped bugs become eval cases. Do NOT use to design or judge a single workflow experiment (see `workflow-experimentation`, which this loop feeds), to decide where to run work (see `dogfooding`), or to debug one failed execution in the moment.
The English summary is being prepared. Showing the original description.