I love taking a great idea and running with it. This system outlined in the video isn't perfect, but it's a great start. I didn't need most of the functionality of the base Ability class in this video (btw I'm only naming my class "Skill" over "Ability" because I prefer shorter identifiers), so I stripped my "Skill" class down to just an abstract "Invoke" method that simply accepts a parameter of type "SkillBehaviour" (derived from MonoBehaviour and references a Skill to invoke). I attempted to make more scripts deriving from SkillBehaviour that cached certain components for it's referenced Skill to read/manipulate, but that would require users to cast in the Invoke method, which is not really user-friendly and fairly error-prone. Instead, I decided to make abstract generic versions of the Skill class, with each generic type constrained to Component. In doing so, I could create skills that read from and manipulate multiple Components at once if the Components were cached in a list within SkillBehaviour. I implemented a little Editor Scripting to SkillBehaviour so that each element type in the cached component list matched the types in generic parameter list of the skill it referenced and to automatically attempt to populate the component list with valid existing components within the hierarchy of the gameobject the SkillBehaviour is attached to. Also, the components in the SkillBehaviour component list don't even have to be attached to the same game object which can be especially useful for Collision and Trigger Events.