Individual skill
business-rule-extractor
Produces a documented inventory of the implicit business rules, edge cases, and bug-as-feature behaviors that tangled code encodes, with real input-to-output examples, so a rewrite preserves behavior. Use when you are about to rewrite, port, or replace legacy code whose only specification is the source, and you see policy buried in conditionals, magic numbers, hardcoded dates, or per-customer special cases. Do NOT use when you need an executable safety net before refactoring - use characterization-test-writer instead; do NOT use when you need to find service boundaries in a monolith - use monolith-decomposer instead.
skills/business-rule-extractor/SKILL.md
Source commit 97a13607d669157a4a16d5ba79b77f208319f7b9
What was checked
- Matches the observed repository HEAD
- Yes
- Scanner rules are current
- No
- Repository scan complete
- No
- Skill scan complete
- No
- Observed behavior
- Not checked yet
- Last checked
- Nov 6, 2026
These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.
Install this skill
Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.
An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.
Repository context
- Repository stars (not skill ratings)
- 24
- Repository last updated
- Oct 13, 2026
- License
- MIT
Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.
- claude Repository topic
- claude-skills Repository topic
- skill-me Repository topic
- testing Derived category
Files and excerpt
File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.
Read excerpt
# Business Rule Extractor
Turn undocumented legacy logic into a written rule inventory so a rewrite preserves behavior instead of silently changing it. The source code is the spec, and most of it is accidental - your job is to surface what it actually does, not what it should do.
## Workflow
1. **Scope the extraction target.** Identify the exact module, files, and entry points to be rewritten. List every external system, shared table, global, and session state the logic touches - a rule split across files is the one most likely to break on rewrite.
2. **Mine rules from conditionals and constants.** For each branch, guard, magic number, string literal, and validation, ask "what business reality does this encode?" `amount > 10000` is a large-transaction threshold; a hardcoded date is a regulation start; a branch on one customer ID is a negotiated exception. Magic numbers are almost always undocumented policy. Treat any constant that appears in two or more places as a single rule with duplication risk - note every occurrence, because a rewrite that updates one copy and misses the other creates a divergence bug.
3. **Record order and interaction.** Capture precedence (which discount wins when two apply), short-circuits, fall-through defaults, and exact boundary handling of null, empty, negative, and `>` vs `>=`. Evaluation order is itself a rule; note every place an input path forks.
4. **Separate intended rules from bug-as-features.** Code alone cannot tell you which behaviors are deliberate. Flag each questionable behavior and confirm against domain experts, support tickets, or production data - aim for at least two independent sources (e.g. one expert plus production evidence) before labeling a behavior intended. Document bug-as-features explicitly so the rewrite team decides consciously, not in an incident.
5. **Capture each rule as input-to-output examples.** For every rule, record concrete cases from real data, especially at boundaries - a minimum of 3 cases per rule (below, at, and above each boundary), and 10+ for rules with interacting conditions. A table of cases removes the ambiguity that "applies a tiered discount" leaves behind.
6. **Hand off open questions.** Before declaring a path dead, check production logs or traffic over a window that covers the business cycle - 90 days is a practical floor, a full year for anything with annual/seasonal triggers. Mark provably dead paths as dead rather than reverse-engineering intent. List behaviors you could not classify as explicit questions for domain owners.
## Deliverable
