Agent skill
hard-cut
Enforce a hard-cut product policy: keep one canonical current-state implementation and delete compatibility, migration, fallback, adapter, and dual-behavior code unless the user explicitly asks for transition support. Use when a task changes product behavior, persisted state, startup recovery, routing, contracts, configuration, schema or enum shapes, feature flags, or architecture where old-state compatibility might otherwise be preserved.
Install this agent skill to your Project
npx add-skill https://github.com/regenrek/agent-skills/tree/main/skills/hard-cut
SKILL.md
Hard-Cut Policy
Overview
Apply a hard-cut policy as the default decision filter for product and architecture changes. Keep one current-state codepath, fail fast on invalid old state, and prefer explicit recovery steps over compatibility logic.
Operating Rules
- Treat historical local state as non-authoritative unless the user explicitly requests migration or compatibility support.
- Delete compatibility bridges, fallback paths, dual reads/writes, adapter layers, old enum aliases, legacy route parsing, and silent coercions when touching the primary codepath.
- Update contracts, validation, flags, constants, and configuration in one canonical location. Do not preserve parallel policy logic.
- Fail fast when persisted state, inputs, or contracts do not match the canonical format.
- Prefer explicit operator or user recovery steps over automatic migration.
- If a change makes old local state invalid, surface that clearly and keep the canonical implementation clean.
Decision Test
- Ask whether there is a real external-user compatibility requirement.
- If not, remove the old path and keep only the canonical current-state behavior.
- If yes because the user explicitly asked for transition support, keep it narrow and temporary.
- In the same diff, state why the compatibility code exists, why the canonical path is insufficient, the exact deletion criteria, and the tracking ADR or task.
Review Checklist
- Remove dead migration and fallback code once the canonical path exists.
- Collapse duplicated validation or policy logic into one source of truth.
- Replace silent fallback with an explicit error, assertion, or mark as removed entirely if not needed anymore.
- Prefer invalid-state diagnostics over best-effort parsing or coercion.
- Call out any unavoidable temporary compatibility code in the final summary or PR body.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
shadcn-vite-iconify-landing-page
Build, critique, and iterate high-converting marketing or product landing pages using React + Vite + TypeScript + Tailwind and shadcn/ui components, with all icons sourced from Iconify. Use when the user asks for a landing page, sales page, signup page, CRO improvements, above-the-fold vs below-the-fold structure, hero + CTA copy, section order, or wants production-ready shadcn + Vite code.
security-leak-guardrails
Sets up secret-leak prevention guardrails with forbidden path checks, gitleaks config, CI secret scanning, and dependency updates. Use when hardening repos against credential leaks or when adding gitleaks, trufflehog, git hooks, or security checks.
homebrew-publish
Publish CLIs/TUIs to Homebrew via a personal tap. Use when asked to create or manage a Homebrew tap repo, generate or update formulae, compute sha256, test installs, or ship new releases for Go, Rust, Node/TypeScript, Python, or prebuilt binaries.
architecture-ownership
Determine runtime owner, first-fix layer, and canonical long-term module or package owner in layered codebases. Use when placing code across UI vs platform shell vs runtime orchestration vs domain or application vs shared core vs adapter or integration layers, debugging ownership issues, removing duplicate policy paths, or answering "where should this live?" architecture questions.
codex-analysis
Run Codex CLI for deep code analysis and second-opinion reviews. Use when the user explicitly asks for Codex analysis, Codex help, or wants a second opinion from Codex on code, architecture, or debugging questions.
go-local-health
Run local Go health checks (tests, coverage, lint) in Go repositories that contain go.mod/go.sum. Use when the user asks to run or interpret local Go test/coverage/lint workflows using tools like lazygotest, gocovsh, tparse, and golangci-lint. Do not use for Rust or non-Go projects.
Didn't find tool you were looking for?