Built-in deploy recipes and deploy targets. Use when a task asks you to set up or change a stage/preprod/prod deploy workflow, including the system's "Set up <env> deploy" tasks.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Deploying is a defined step like build and test, not improvisation. Every environment
(stage, preprod, prod) of a repository has a deploy target: a provider, its
variables, a health URL and a rollback policy. Each provider has a template: the
workflow to write, the secrets it needs, the smoke check and the rollback.
<env> deploy" task already carries the rendered recipe in its description —
start from that rather than asking the tools for it again.get_deploy_target with the repository id and env to re-read what this repo ships to,
plus the recipe rendered with its variables, whenever you need it again mid-task.load_deploy_template for the full raw recipe (secrets, smoke check, rollback) when the
rendered version in the task description is not enough, or the task gives no recipe
(a change to an existing deploy rather than a new one) — list_deploy_templates,
optionally filtered by repo kind, to see what is available first..github/workflows/ exactly as the recipe describes. Keep the
workflow_dispatch trigger: the board dispatches deploys by workflow file.name: per ci-cd-pipeline-authoring so the detector maps
it to the right slot (stage_deploy / preprod_deploy / prod_deploy). If the slot still
shows unmapped after that, say so in one comment: mapping the detected slot is the human's
action, not something you can force from here.if: failure()).
If a provider cannot roll back automatically, document the exact manual command.kubectl rollout status, aws ecs wait services-stable and
their equivalents are what make the result honest; dropping them for speed hides
crash-looping releases.concurrency.group),
otherwise two releases race and the environment ends up in an undefined state.{{key — SET THIS}}), ask
for it. Do not guess a project id, region or cluster name.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 writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
The English summary is being prepared. Showing the original description.
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
The English summary is being prepared. Showing the original description.
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
The English summary is being prepared. Showing the original description.
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
The English summary is being prepared. Showing the original description.
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
The English summary is being prepared. Showing the original description.
Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here
The English summary is being prepared. Showing the original description.