OK, the first action sets the new (reference) child note to use the same prototype as the parent (i.e. article) note. Most commonly a prototype sets a note’s Key Attributes (KAs), i.e. what is listed in the KA table. However, as values inherit from the prototype and not via the parent we need additional code to set local values in the new note so that some attributes reflect those of the parent. This is what the second and third lines of the quoted code are doing. Exactly which and how many attributes are altered will vary according to the project, i.e. it is an exercise for the user.
‘refreshing agents’. This may have been misread as suggesting use of agents. Actually, I was referring to edicts and how they me be refreshed manually, on demand. I suggest reading this article on edicts and how they work. The idea of using an edict is that if you change a value in an article note that were set in child notes when they were created, the child notes will need updating as the parent’s OnAdd only runs when a new child is created.
If you’re not bothered about the speed of such updates but rather that they do occur at all and without your intervention, you could set an edict in child notes that resets the desired attribute values to those of the parent. If going this route, it might make sense to make a new prototype based on the one for article notes but with the additional edit defined. If so, don’t forget to change the OnAdd code of the article prototype to set the the new prototype.