本文へ移動
cccskills
無料GitHub で公開

rt-unify-duplicates

Finds duplicated implementations across modules and merges each into one canonical helper, respecting the workspace import DAG (operator→types←backend; cli imports no sibling); inherent two-sided duplication gets a drift-guard test instead. Use when the user asks to run the rt-unify-duplicates routine, deduplicate code, or unify parallel helpers.

日本語の概要は準備中です。原文の説明を表示しています。

bex-co/bexスター 577(GitHub 577 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(2)

  • SKILL.md4.6 KB
  • agents/openai.yaml214 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Routine: Dup Unifier

Merge duplicated implementations into one canonical home — or, where duplication is inherent to the design, guard it against drift.

Routine ground rules

  • A user request to run this routine authorizes the full cycle: plan, fix, verify, then invoke $ship (Codex) or /ship (Claude) directly in the same run. Honor explicit user limits such as audit-only or no-ship.
  • Keep a concise execution plan in the conversation and update it as findings are confirmed. Continue into implementation without a planning approval pause. Do not create or file a .pm milestone/task as a prerequisite or substitute for fixing; use the board only if the user requests it.
  • After the verification phase, follow the shipping phase below without asking the user to invoke ship separately. Preserve the ship skill's branch, conflict-resolution, and safety rules.
  • Fix everything you find directly in the working tree. If a fix can't be finished safely in this run, revert only your partial work for that fix and list it under Deferred in the report — never leave the tree half-refactored.
  • Scope: parse $ARGUMENTS per Phase 1 — an optional path/module scope or skill-specific target. No argument = the skill's stated default (usually the whole repo via parallel agents per module: lego/types, lego/operator, lego/backend, lego/cli, dashboard).
  • False-positive discipline: if a finding is intentional, load-bearing, or ambiguous, skip it with a one-line reason — don't argue it into a change.
  • Every change must pass the verification gates for the modules it touched before being reported as done: operator make test + make lint (from lego/operator/), cd lego/backend && go test ./..., cd lego/cli && go test ./..., dashboard yarn test + typecheck.
  • Run npx prettier@3.4.2 --write on any markdown touched.
  • Before shipping, summarize results in commentary using: Fixed (file:line + one-line rationale) / Deferred (item + why) / Skipped (finding + reason) / Gates (commands run + outcomes).

Phase 1 — Scope

Parse $ARGUMENTS as an optional path/module scope. Empty = whole repo; the backend↔operator pair is the hot spot.

Phase 2 — Find duplicates

Start from the known candidates, then scan wider:

  • lego/backend/internal/id vs lego/operator/internal/identity — two id/identity implementations split by module.
  • Naming helpers in lego/backend/internal/store/reconciler.go vs lego/operator/internal/controller/app_controller.go — backend computes desired CRs, operator reconciles them.
  • Scan: same-named functions across modules (grep -rn "^func " lego/{backend,operator}/internal), copy-paste blocks ≥10 lines, parallel dashboard/backend logic.

Phase 3 — Classify

  • Accidental duplication → unify.
  • Inherent two-sided design (the store/reconciler mirroring is intentional) → do NOT merge; instead add or verify a cross-checking test that fails when the two sides drift.

Phase 4 — Unify

Pick the canonical home along the import DAG: code both operator and backend need goes to lego/types — the only module both import. cli stays standalone; never fold it into a sibling. Respect the depguard-fenced id convention (ids mint only via lego/backend/internal/id, id.New(kind)). Migrate all callers, delete the duplicate, and confirm nothing dangles via make lint (whole-program deadcode is wired in).

Phase 5 — Verify and report

Types changes ripple everywhere: run all Go gates (operator make test + make lint, backend and cli go test ./...), plus dashboard gates if touched. Report per the standard format.

Final phase — Ship

After all required gates pass, read and execute the ship skill for the routine's completed changes. Stage only intended changes from this run; preserve unrelated work. Do not end at a plan, findings report, milestone, or request for shipping approval. If there are no changes, report that outcome without creating an empty commit. If a required gate remains blocked or fails after reasonable repairs, report the exact blocker and do not ship unverified changes.

Once the push succeeds, report the shipped HEAD SHA and subject per the ship skill and stop; do not monitor CI or deployment.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Sets up and configures background workers on bex for queue-based job processing. Use when the user needs to process async jobs, consume from a queue, run Celery/Sidekiq/BullMQ/Asynq/Oban workers, handle graceful shutdown with SIGTERM, wire a worker to Key Value, or choose between workers and cron jobs for background work. Trigger terms: background worker, async jobs, queue consumer, Celery, Sidekiq, BullMQ, Asynq, Oban, job processing, SIGTERM, graceful shutdown.

日本語の概要は準備中です。原文の説明を表示しています。

bex-co/bex5772026年10月29日 更新

Authors and validates render.yaml Blueprints for bex infrastructure. Use when the user needs to write or edit a render.yaml, wire services together with fromDatabase/fromService/fromGroup, set up projects and environments for multi-service apps, configure preview environments, validate against the schema, or fix immutable field errors. Trigger terms: render.yaml, Blueprint, IaC, fromDatabase, fromService, envVarGroups, previews, projects, environments.

日本語の概要は準備中です。原文の説明を表示しています。

bex-co/bex5772026年10月29日 更新

bex-cli

無料

Installs and uses the bex CLI for deploys, logs, SSH, psql, Blueprint validation, and automation. Use when the user needs to run bex CLI commands, script deploys in CI/CD, authenticate with an API key, query services non-interactively, or troubleshoot CLI auth issues. Trigger terms: bex CLI, bex login, bex deploys, bex logs, bex ssh, bex psql, bex blueprints validate, bex skills, BEX_ACCESS_TOKEN, non-interactive, CI/CD deploy.

日本語の概要は準備中です。原文の説明を表示しています。

bex-co/bex5772026年10月29日 更新

Configures and troubleshoots scheduled tasks on bex using cron job services. Use when the user needs to run something on a schedule, write a cron expression, set up a periodic job, migrate from Heroku Scheduler, choose between cron jobs and background workers, or fix a cron that isn't firing. Trigger terms: cron job, scheduled task, periodic job, cron expression, schedule, run every, timer, Heroku Scheduler migration.

日本語の概要は準備中です。原文の説明を表示しています。

bex-co/bex5772026年10月29日 更新

bex-debug

無料

Debug failed bex deployments by analyzing logs, metrics, and database state. Identifies errors (missing env vars, port binding, OOM, etc.) and suggests fixes. Use when deployments fail, services won't start, or users mention errors, logs, or debugging.

日本語の概要は準備中です。原文の説明を表示しています。

bex-co/bex5772026年10月29日 更新

Deploy applications to bex by analyzing codebases, generating render.yaml Blueprints, and providing Dashboard deeplinks. Use when the user wants to deploy, host, publish, or set up their application on bex's cloud platform.

日本語の概要は準備中です。原文の説明を表示しています。

bex-co/bex5772026年10月29日 更新

bex-co のスキルをすべて見る

このスキルの問題を報告する