Rule: When evaluating whether to ship a SKILL.md for a religious or jurisdictional inheritance domain (faraid, hsa, halakhic, future-jurisdictions) under code-inheritkit/skills/{name}/SKILL.md, recognise that the actual consumer is partner-firm developers running Claude Code sessions against the InheritKit plugin — not a runtime SDK caller, not IAS, not the conformance gate. The skill auto-loads when the partner-firm session’s task matches the description: field. That is the distribution model. Keep them in scope; do not recommend dropping them on “no current consumer” grounds.
Why: Rich confirmed on Friday 22 May 2026 (this session) after I had recommended dropping hsa-skill and halakhic-skill from batch-imp-14 Wave 5+ scope on the (wrong) grounds that “no one runs these at production.” His response: “ah i understand — these skills are very useful. i am happy to continue building them.” The InheritKit-as-Claude-Code-plugin distribution model means SKILL.md files ARE the developer-experience product surface. A partner-firm developer editing Hindu intestacy Catala rules or extending a LinkML class for a yerushah-aware estate has hsa-skill / halakhic-skill load automatically and gets the domain framework with them. The faraid skill (already shipped at A-265-area) was authored on this assumption and is the format precedent.
The “first-mover claim” framing in batch-imp-14 §1.2 and similar launch prompts is real — verify at landing time per §13.5 (WebSearch + AAIF Anthropic Skills directory) before asserting in frontmatter, but assume it’s valid until disproven. The acquirer-DD §3.5.6 N+1 resilience claim has a thin but genuine moat here: once TT registers hsa-skill and halakhic-skill in the Anthropic Skills directory, a later competitor either matches TT’s coverage or builds a different one — friction either way.
How to apply:
- When Wave 5+ / Wave 6+ scope-trim conversations come up about religious or jurisdictional inheritance Skills, DO NOT propose dropping them on the “no current consumer” / “speculative first-mover” framing I used in this session. That framing was wrong.
- Keep
hsa-skill,halakhic-skill, and any successor jurisdictional/religious inheritance skills in scope unless Rich himself trims them. - The distinction I made between “internal tool skills” (catala, cedar) and “domain reference skills” (faraid, hsa, halakhic) is real but not load-bearing — both are valuable; both have consumers. Catala/cedar have TT itself as the consumer plus partner firms; faraid/hsa/halakhic have partner firms working in those jurisdictions as the consumer.
- When justifying or scoring a new Skill in a launch prompt or scorecard, name the partner-firm Claude Code session as the consumer, not just the abstract acquirer-DD claim. The consumer makes the value concrete.
- Still apply §13.5 verify-before-author at landing time: WebSearch for prior art in the Anthropic Skills directory + AAIF registries before asserting first-mover.
Companion files:
~/testatetech/code-inheritkit/skills/faraid/SKILL.md— format precedent (description field carries explicit first-mover claim)~/testatetech/code-inheritkit/skills/catala/SKILL.md— internal-tool precedent (consumer = TT’s own Catala body sweeps)~/testatetech/code-inheritkit/skills/cedar/SKILL.md— A-270 landingdocs/superpowers/specs/2026-04-29-multi-phase-audit/batch-imp-14-wave-5-continuation-launch-prompt.mdv1.0 §1.2 — scope keeps hsa + halakhic[[feedback_skill_discipline_2026_04_26]]— DIFFERENT topic (using skills as a discipline, not authoring them as product); do not conflate