factory-environment-maintenance

Topics in the source

• Maintain factory repository environments
• Review failures

Run on an admin-chosen schedule, such as weekly, and after a repeated failure cluster. The schedule invokes this local skill with the target factory and time window; the skill itself performs no background polling. Read the configured factory bindings first. Treat each work item as a tracker issue plus a separate code-host repository; Jira issues may correspond to Bitbucket or GitHub pull requests. Use provider tools or APIs available to the operator for the actual binding. Do not assume GitHub labels, issue numbers, or PR URLs exist on every provider. GitHub uses issues and pull requests; GitLab uses issues and merge requests; Jira Cloud issues pair with the bound GitHub or Bitbucket Cloud/DC pull requests. Preserve each provider's immutable project and issue identity. 1. Read recent curie cluster work-items --json outcomes (or the local tier when appropriate), then inspect failed items and their tracker notices, run details, and code-host CI or review history. State the time window and count. The current work-items list is bounded; if truncated is true, continue through the provider's failure history when available and report any remaining coverage gap. Never claim to have examin

This is an excerpt. Refer to the complete source and its current requirements.