Conditional Includes, Roles and Multiple Playbooks

I am trying to figure out the structure for how I am going to use Ansible and am having some design issues.

I would like to have multiple playbooks in my roles, each with a subset of tasks I need to be done. E.g. - a playbook for System Updates, a playbook for deploying our app, a playbook for building a system.

Right now, I have playbooks in place with conditional includes in each roles main.yml file.

In my books/ directory I have my playbook for each role, and here is an example of the whole series of playbooks:

// books/dev.yml

I am trying to figure out the structure for how I am going to use Ansible
and am having some design issues.

I would like to have multiple playbooks in my roles, each with a subset of
tasks I need to be done. E.g. - a playbook for System Updates, a playbook
for deploying our app, a playbook for building a system.

Right now, I have playbooks in place with conditional includes in each
roles main.yml file.

Just as a general tip, "group_by" usually produces much cleaner output than
conditional includes.

In my books/ directory I have my playbook for each role, and here is an
example of the whole series of playbooks:

*// books/dev.yml*
---
- hosts: dev
  serial: 1
  roles:
   - common-dev

*// roles/common-dev/tasks/main.yml*
---
- include: build.yml
  when: pbook == "build"

- include: update.yml
  when: pbook == "update"

I'd try to write your playbook to be a bit declarative so th build and
update process can be run repeatedly without specifying which is which - it
just gets it into the desired state.

So, when I run ansible-playbook, I include --extra-vars="pbook=update",
for example. It works great, but I get 'skipping' for every task out of the
build.yml playbook.

I would really like to suppress this, if at all possible. I know what the
tasks are not running, but I am afraid of causing confusion as I hand off
the actual running of the playbooks to other folks. Is there some better
way to be handling this?

Possibly tags, or two top level playbooks, but really the above. A good
playbook shouldn't specify a build or update step, it should work to bring
a system to a desired version without knowing if it's the first install or
just an update.

i.e. it should never assume anything about the state of the remote system
that it does not infer.