Today, there are two ways that a user may be asked to grant permissions to a skill: At the time they enable the skill, and when the skill returns a Permission card with its response. For a developer of a skill that uses permissions, the second of these approaches is optional, and entirely controlled by the skill. The first is mandatory, and completely out of our control.

As a developer, I would like the ability to configure whether any individual permission is prompted for upon skill enablement (and concordantly, whether a permission upsell is triggered when voice enablement is used).

Rationale:
Just because my skill uses permissions does not mean that EVERY user of my skill needs to grant me those permissions. It is reasonable to assume that a skill can contain both permission-gated and permission-free use cases concurrently. Requiring all users to hear about permissions up front, before they need them, has several undesirable effects:

1. Users grant me permission I don't need to have yet, which frankly runs contrary to Amazon's security policies, and which makes me liable in a way I don't want to be.
2. I am robbed of the opportunity to explain the permissions I'm requesting before the user makes a choice, thereby forcing them into an uninformed decision.
3. It drives away users. It has long been known in the mobile world that asking users to agree to permissions at install time causes many users to just drop entirely, even if their use cases would've been covered outside of the permissions in question.

My own skills provide two perfect examples of this:

Astrobot is a skill about providing space launch information. For the most part, it's an information querying skill. You can open a session, ask questions, and be done. But it also provides the option to subscribe to push notifications. A very small fraction of users choose to do this, and it was added on later to the skill which had been working just fine without the feature. But now every single user who enables astrobot is going to be asked for push notifications, regardless of the fact that the vast majority of them have no reason to use it.

Even more frustrating for the user would be how InsultiBot's permissions work. InsultiBot is currently undergoing a massive update to add ISP. As part of that, new "premium" features have been added, and these features require permissions to be granted, where none were requested before. So it is extremely likely that some portion of my users will now enable the skill and grant me permissions, only to find out that not only were the permissions not absolutely required, but that the permissions cannot even be relevant unless they spend money on my skill.

In both of these cases, I would absolutely choose to manage permissions only through the Permission cards.