The necessity of ``@no_requirements`` is actually a little more subtle. It returns ``_executed`` if a method was executed and is necessary (right now) for pruning a workflow to only those methods that are executed. 

Playing with the prototypes, ``@priority`` is very beneficial in situations where there is an indirect dependence on another workflow method. 

An additional observation I've had while working with prototypes is that having a notion of a workflow group is very handy, which is what the ``wf_`` methods are right now. There is no naming restriction necessarily. For instance:

```python
@priority(100)
@requires(valid_state=_has_qual)
def wf_quality(self, item):
    self._quality_max_bad_run_length()
    self._quality_min_per_read_length_fraction()
    # ...snip other quality methods...

@requires(option='max_bad_run_length')
def _quality_max_bad_run_length(self):
    pass

@requires(option='min_per_read_length_fraction')
def _quality_min_per_read_length_fraction(self):
    pass
```

I like option 2, but I do really like the logical organization in the code as well. The downside to the current approach is that there are additional noop function calls within the ``wf_`` methods, but the code organization is much cleaner.