Safe to use a BCrypt hash directly as a key to HMAC-SHA256?

Is it safe (or optimal) to use a BCrypt hash directly as the key to an HMAC-SHA256? I ask because all the BCrypt hashes I will use contain the same salt, version, and cost, so the first 29 characters of the hashes will all look the same, e.g. "$2a$06$/H63GWnve78WGVBSDouFTO". I'm not comfortable with this much known structure in a key. Should I run the BCrypt hash through a SHA256 first before using it as the key to an HMAC-SHA256, or is it ok to use it as-is?

In principle HMAC can use a key fo any size. However, I'd argue that only the final 31 characters of the returned string are of importance, as that consists of the calculated bcrypt hash / the HMAC secret. Obviously you'll need to store the salt somewhere public if you want to just keep the password secret. As such it doesn't count towards the security of the resulting secret.

Now there is something of a problem: those 31 characters only represent 23 bytes of generated secret information. In principle HMAC should take a key of 32 bytes. So the output of bcrypt seems to be fall somewhat short of the recommended size for HMAC. Generally I'd say that 184 bits offer plenty of security, but switching to PBKDF2 or Argon2 could an idea.

For HMAC I say it doesn't matter much if the characters are used "directly" by interpreting them as bytes (using one specific character encoding) or if they are base 64 decoded first.

I don't see much point of hashing the output of bcrypt before putting it into HMAC. HMAC can take any size of key, and will automatically hash the input using the internal hash if it would hamper the efficiency of the algorithm.