Responsibilities make many commonly discussed rules unnecessary. Responsibilities are also generative in that they don't just tell you what to do with existing code, but the help you figure out what to create in the first place.

Responsibilities:
	* Imply things so you have a start for objects and method names in your system.
	* OnceAndOnlyOnce and DuplicatedCode are implemented by default because something is made responsible for a behaviour it will only be in one place. 
	* OneResponsibilityRule is easy to follow because you are thinking in responsibilities in the first place so it is easier to partition them.
	* YouArentGonnaNeedIt is followed because responsibilities create things to solve actual problems. 
	* Refactoring should be along the lines of responsibilities and will tell you where code should go to implement a responsibility.
	* Reuse is had because you should use the thing that already is responsible for what you want to do. 

Making responsibility the overriding rule is simpler than keeping in mind a bunch of different rules that aren't as clear in purpose.
----
''OnceAndOnlyOnce and DuplicatedCode are implemented by default because something is made responsible for a behaviour it will only be in one place.''

I don't see how this is guaranteed. Two different nouns could have duplicate methods or parts of methods.

''YouArentGonnaNeedIt is followed because responsibilities create things to solve actual problems.''

This is also a stretch in my opinion.

''Reuse is had because you should use the thing that already is responsible for what you want to do. ''

Only if you can reuse something as-is, which is often not the case in reality. If not, then you are faced with the choice of whether to expand the interface of an existing thing, copy it and change the copy, subclass, or split into smaller parts.

-------

Responsibilities deal with the Problem Domain (the "what") of the system at hand.
YAGNI deals with the scope that applies to the software to be developed on a given iteration. 

The classes developed in any given iteration do have responsibilities, but these responsibilities belong to the Solution Domain (the "how" of the system at hand).

For any given set of classes and their responsibilities from the Problem Domain of the system at hand, you could have many different sets of classes and responsibilities in the Solution Domain,that is, many different implementations for the very same set of requirements.

The set of responsibilities from the Problem Domain of a given system will change only if requirements change. 

If requirements do not change throughout the duration of the project, the set of responsibilities from the Problem Domain will stay put.

The set of responsibilities from the Solution Domain present on any given iteration will change from iteration to iteration (the set of responsibilities tends to grow with time), and that is what YAGNI helps us to achieve.

So, it would seem that there is no rule that strictly links Problem Domain responsibilities with YAGNI.

--GastonNusimovich