본문으로 건너뛰기
cccskills
무료GitHub에 공개

flag-cleanup

Inventory feature flags, switches that control feature availability, and remove eligible flags with their unused code branches. Leave ongoing rollouts and experiments untouched, run verification checks, and prepare a pull request for human review.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

Weekly reusable-session feature-flag cleanup for {{target_repo}}. Inventories every feature flag, classifies each as fully rolled out, long dead, partial rollout, or active experiment, removes the flag and the dead branch it guards on an isolated branch when the suite is green, and opens a PR — never touching a flag still mid-rollout.

연동 도구GitHub
설치 방법 보기

이럴 때 유용합니다

  • Removing flags after a feature has fully rolled out
  • Cleaning up unused flags and unreachable code branches
  • Listing ongoing rollouts and experiments for human review
  • Rechecking flags after their rollout status changes

포함된 파일(1)

  • SKILL.md9.3 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

<skill name="flag-cleanup"> <overview> Keep the feature-flag inventory in `{{target_repo}}` small without ever risking a live rollout. A weekly cron re-prompts a persistent session, which reads a ledger of every flag's known age and rollout state, re-inventories the codebase, classifies each flag, and removes only the ones that are provably safe: fully rolled out (always-on) or long dead (no live check left, unchanged past `{{min_flag_age_days}}` days). Anything still in partial rollout or an active experiment is left completely alone and reported for a human to decide.

Proactive and schedule-driven; covers the full flag inventory every run, growing the ledger over time as flags are removed or newly flagged. </overview>

<when-to-load> - The weekly cron fires the flag-cleanup sweep. - A human asks the agent to check for stale feature flags or clean up dead flag branches. - A flag that was previously flagged for human review needs re-classifying after its rollout state changed. </when-to-load> <workflow>

Step 0 — Orient and resume

# Read the durable ledger first — known flags, their last-seen rollout state,
# what's already been removed, and what's already flagged for human review.
cat memory/flag-cleanup-log.md 2>/dev/null || echo "(no ledger yet — first run)"

# Check any open cleanup PRs from a prior run.
gh pr list --repo {{target_repo}} --state open \
  --search 'in:title "chore(flags)" OR label:feature-flags' \
  --json number,title,headRefName,statusCheckRollup,url

If a prior cleanup PR is still on CI or in review, don't duplicate the work — drive a stalled-but-fixable PR to green, otherwise leave it for review and move on to flags it didn't cover.

Step 1 — Freshen the repo

DEFAULT_BRANCH=$(gh repo view {{target_repo}} --json defaultBranchRef -q .defaultBranchRef.name)
if [ -d /workspace/repo/.git ]; then
  cd /workspace/repo && git fetch origin && git checkout "$DEFAULT_BRANCH" && git reset --hard "origin/$DEFAULT_BRANCH"
else
  git clone --filter=blob:none https://github.com/{{target_repo}}.git /workspace/repo
  cd /workspace/repo
  git checkout "$DEFAULT_BRANCH"
fi

Never classify or remove a flag against a stale checkout.

Step 2 — Inventory every flag

cd /workspace/repo
# Flag definitions/registry — adapt the path to this repo's convention
# (e.g. flags.ts, feature-flags.json, a flags/ directory).
grep -rnE "(defineFlag|registerFlag|FEATURE_FLAGS|flags\.(json|ya?ml))" --include="*.ts" --include="*.tsx" --include="*.json" . 2>/dev/null

# Call sites — every place a flag is actually read.
grep -rnE "(isEnabled|useFeatureFlag|getFlag|flags\.[a-zA-Z_]+)\(" --include="*.ts" --include="*.tsx" . 2>/dev/null

For every flag found, record: name, where it's declared, every call site, and (if the rollout percentage or state is tracked in-repo, e.g. a config file) its current rollout value. Cross-reference git log -1 --format=%ai -- <flag file or last touched call site> for the flag's last-touched date.

Step 3 — Classify each flag

ClassificationCriteriaAction
Fully rolled outRollout is 100% / hardcoded true with no variant left, or explicitly marked GARemove — inline the "on" branch, delete the "off" branch
Long deadNo call site found anywhere in the repo, or unchanged (declaration and all call sites) for more than {{min_flag_age_days}} days with a rollout that was already at 0% or 100%Remove entirely, including the dead declaration
Partial rolloutRollout between 0% and 100% exclusive, percentage-based, or user/cohort-targetedDo not touch. Log in the ledger for human review
Active experimentTied to an A/B test, gradual ramp still in progress, or flag age under {{min_flag_age_days}} days with no clear rollout signalDo not touch. Log in the ledger for human review

When a flag's rollout state can't be determined from the repo alone (e.g. it's controlled by an external system this agent has no access to), treat it as ambiguous and log it for human review — never guess.

Step 4 — Isolated cleanup branch

cd /workspace/repo
BRANCH="chore/flag-cleanup-$(date +%Y-%m-%d)"
git checkout -b "$BRANCH" "origin/$DEFAULT_BRANCH"   # or check out an existing branch from this run

Step 5 — Remove each eligible flag

For every flag classified fully rolled out or long dead:

  1. Find every call site (if (flags.x), useFeatureFlag('x'), etc.).
  2. Inline the branch that survives (the "on" branch for fully-rolled-out flags; nothing survives for long-dead flags with no live call site).
  3. Delete the now-unreachable branch and any helper code that only existed to support it.
  4. Remove the flag's declaration from its registry/config file.
  5. Remove now-unused imports and any tests that only exercised the dead branch; update tests that exercised the surviving branch so they no longer gate on the flag.

Do this one flag at a time so a single bad removal is easy to isolate and revert.

Step 6 — Full verification suite (the gate)

The removal is not ready until every check is green.

cd /workspace/repo
pnpm install       2>&1 | tee /tmp/flag-install.log
pnpm typecheck     2>&1 | tee /tmp/flag-typecheck.log
pnpm lint          2>&1 | tee /tmp/flag-lint.log
pnpm build         2>&1 | tee /tmp/flag-build.log
pnpm test          2>&1 | tee /tmp/flag-unit.log
pnpm test:integration 2>&1 | tee /tmp/flag-integration.log   # if < ~10 min

Interpreting failures:

FailureAction
Typecheck/build error from a removed branch's dependencyFix the mechanical fallout (unused import, dangling type); if non-mechanical, revert that one flag's removal and log it
Test failure for the removed flagExpected if the test only covered the dead branch — delete it; if it covered the surviving branch, fix the test
Test failure in an UNRELATED areaFile it as a note (likely pre-existing); don't revert unless you can prove causation
Any failure you can't resolve in a few linesRevert that flag's removal, log it as deferred with the reason, keep the rest of the batch

Step 7 — Commit

cd /workspace/repo
git add -A
git commit -m "chore(flags): remove stale feature flags $(date +%Y-%m-%d)

Removed: <flag-a> (fully rolled out), <flag-b> (long dead)
Verification: typecheck ✓ lint ✓ build ✓ unit ✓ integration ✓"

Step 8 — Open the PR (only when Step 6 is fully green)

A partial green (checks skipped/timed out) is NOT acceptable — rerun or debug.

cd /workspace/repo
git push origin "$BRANCH"
gh pr create --repo {{target_repo}} --base "$DEFAULT_BRANCH" --head "$BRANCH" \
  --title "chore(flags): remove stale feature flags ($(date +%Y-%m-%d))" \
  --label feature-flags \
  --body "Generated by the flag-cleanup agent. The full suite passed in the
sandbox before this PR was opened.

**Removed (fully rolled out or long dead):**
- <flag-a> — fully rolled out, last touched <date>
- <flag-b> — long dead, no live call site found

**Left untouched (flagged for human review):**
- <flag-c> — partial rollout at <percentage>%
- <flag-d> — active experiment

A human owns the merge."

Step 9 — Update the ledger

Append a dated entry to memory/flag-cleanup-log.md (see <ledger-format>), then open + self-merge a scoped change request for the ledger update only.

</workflow> <ledger-format> Lives at `memory/flag-cleanup-log.md`. Every run appends/updates the current entry with: run timestamp, branch, PR link (or "not opened — why"), a **Flag inventory** table (flag / declared location / rollout state / last touched / classification), a **Removed this run** table (flag / classification / files changed), a **Flagged for human review** table (flag / classification / reason it wasn't touched), a **Verification** table, **Deferred removals** (flag / reason / re-check date), and **Blockers for next run**. </ledger-format> <guardrails> - **Partial rollout and active experiments are never removed.** These are always logged for human review, no exceptions, regardless of age. - **No direct push to the default branch.** The agent opens a PR and stops. A human merges. - **Sandbox isolation.** Removals are applied and tested on an isolated branch in the session sandbox. Nothing reaches the repo until the suite is green and `git push` runs. - **Remove the branch, not just the flag.** A removal that deletes only the flag declaration but leaves dead conditional code behind is incomplete — finish the cleanup in the same PR. - **When ambiguous, don't guess.** If a flag's rollout state can't be confirmed from the repo, log it for human review instead of classifying it as safe. - **Secrets scoped.** The GitHub token is injected at runtime; never written to disk or logged. - **One PR per run, one run per week.** If a batch fails, fix or split and push to the same branch — don't open a duplicate. - **CI must be green before merge.** The agent won't ask a human to merge a red PR. </guardrails> </skill>

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Review Slack access requests against Okta role and team information, then prepare narrowly scoped GitHub or AWS IAM permissions. Apply changes only after an eligible person's approval and record the grant, reasoning, approver, and timestamp.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reviewing GitHub repository access requests from Slack
  • Preparing AWS IAM permissions for a specific task
  • Routing sensitive access requests for additional review
kortix-ai/suna2만2026년 10월 19일 업데이트

Research companies and people before outreach or meetings. Combines business profiles, recent news, hiring signals, and key contacts into a sourced brief with talking points and suggested questions, adding relationship history when CRM data is connected.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Research a prospective customer before outreach
  • Prepare background information for meeting attendees
  • Compare a competitor's products and positioning
kortix-ai/suna2만2026년 10월 19일 업데이트

Review daily Google Ads and Meta Ads results for budget pacing, declining performance, and unusual activity. Get prioritized findings with supporting numbers and concrete recommendations for a marketing team to assess and carry out.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking whether campaign budgets are being spent on schedule
  • Investigating rising acquisition costs or falling ad returns
  • Finding ads and keywords that spend without converting
kortix-ai/suna2만2026년 10월 19일 업데이트

Automate website tasks such as navigating pages, filling forms, clicking buttons, taking screenshots, and extracting data. The skill also supports web app testing, with specialized guides for Electron desktop apps, Slack, and cloud browsers.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Automate form entry and page navigation
  • Capture screenshots and extract page data
  • Explore web apps for bugs
kortix-ai/suna2만2026년 10월 19일 업데이트

Process emailed vendor invoices by extracting details, comparing them with purchase orders and invoice history, and recording duplicates, overcharges, or missing orders. Summarize results in Slack for human review; payment approval and execution remain with people.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking incoming invoices against purchase orders
  • Finding duplicate invoices and likely resends
  • Reviewing unit prices and remaining order balances
kortix-ai/suna2만2026년 10월 19일 업데이트

billing

무료

Guide changes to Kortix billing code, admin controls, and pricing screens. Explain how plans, trials, enterprise contracts, and access exceptions should work, where pricing is defined, and which audited routes must handle account changes.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Update billing logic and its specification together
  • Review how trials and enterprise contracts are handled
  • Find the code that defines prices and allowances
kortix-ai/suna2만2026년 10월 19일 업데이트

kortix-ai의 스킬 모두 보기

이 스킬의 문제 신고