CRM/RevOps Is Methodology, Not Automation
Revenue operations was a thin domain before this batch. Six skills from one repository now average 8.47, and the reason is that they are methodology skills, not API wrappers.
| Skill | Score |
|---|---|
| deal-qualification-gates | 9.0 |
| crm-migration-consolidation | 8.7 |
| qbr-ebr-builder | 8.7 |
| neon-rutger-lead-routing | 8.4 |
| cs-operations | 8.3 |
| pipeline-visibility | 7.7 |
What they encode
deal-qualification-gates is the best example. It defines the gates a deal must pass, the evidence required at each gate, and the conditions under which a deal should be disqualified. That is a decision procedure, not a CRM API tutorial.
crm-migration-consolidation handles a specific, high-stakes decision: when two CRM records conflict, which fields win. It states the precedence rules and the merge logic. The output is an auditable decision.
qbr-ebr-builder defines the structure of a quarterly business review: the metrics to bring, the narrative arc, the questions to anticipate.
None of these files are primarily about which endpoint to call. They are about how a revenue team decides.
The contrast
lead-routing from a different repository scores 6.3. It describes routing features — scoring, territory mapping, round-robin — but the workflow score is 4.0. The NEON version, neon-rutger-lead-routing, scores 8.4 because it encodes the decision logic and the service-level framework, not just the feature list.
Same domain, same name, different kind of file. The difference is methodology.
The lesson for other domains
If you are building a skill for a business function, the valuable part is usually the decision procedure: the gates, the precedence rules, the exceptions, and the audit trail. The tool integration is necessary but not sufficient. The same pattern applies to HR and customer support.