Simple CMD turn-based game made in C
Formatting &amp; Conventions
Always run your code through an autoformatter. On Linux, I use clang-format, and on Win10 I use VSCode's autoformatting intellisense features. I'm not sure of your exact setup, but formatting is big.
Next, variable names. The variable choose is wonderfully descriptive. I know immediately what it's for. The variable P_h on the other hand is vague and undescriptive. Don't worry about how long your variable names are. The compiler won't care. Instead focus on making variable names that are descriptive, like Player_health so that anyone who reads your code immediately understands it.
Program Flow
Ignoring all the messy specifics, this is what I read your program's flow as:
while playing:
    setup variables.
    get player input
    if player doesn't want to play
        exit
    otherwise:
        main game loop
    if lose:
        ask to replay
    if win:
        ask to replay

I'm purposefully ignoring the main game loop for now. Right off the bat, I see one big problem: You do the same thing twice down at the bottom. That whole choose==0 thing can be moved outside the if statements because in either case, you'll encounter it. (In the case where E_h&gt;0 &amp;&amp; P_h&gt;0, you won't have exited the main game loop, so we can ignore that.)
That would look like this:
if (E_h &lt;= 0) {
    puts(&quot;You killed the enemy!\nWould you like to play again? [0 to exit, Press anything else to play again]&quot;);
}
else if (P_h &lt;= 0) {
    puts(&quot;You died. Would you like to play again to try to defeat the enemy. [0 to exit, anything else to play again]&quot;);
}
scanf(&quot;%d&quot;, &amp;choose);
if (choose == 0) {
    play = false;
    break;
}
else {
    play = true;
}

Even here, we can optimize further. Watching program flow, anytime we hit the scanf on this code, we can assert that play==true and so we can remove the whole section that sets it. Furthermore, since the very next thing we do is run while (play) we can cut out the break, since it'll exit the loop naturally. Finally, conditionals that only run a single statement don't need brackets. (That one's up to personal choice, and doesn't really affect your code. I like to knock them off of there.) Thus, we can take 25 lines of code down to
if (E_h &lt;= 0)
    puts(&quot;You killed the enemy!\nWould you like to play again? [0 to exit, Press anything else to play again]&quot;);
else if (P_h &lt;= 0)
    puts(&quot;You died. Would you like to play again to try to defeat the enemy. [0 to exit, anything else to play again]&quot;);
scanf(&quot;%d&quot;, &amp;choose);
if (choose == 0)
    play = false;

just seven.

Next, let's look at the part of the code where you initially ask if the player wants to play. Logically, if the player runs your code, you can assume that they meant to. The whole initial choice section can be removed. (If you choose to leave it in there, think about what might happen if the player decides to replay the game. Right now, they have to say they want to (re)play the game twice!)
Main Game Loop
Ok, here's the meat of it. First thing you can do is move this little number to the end:
if (P_h &lt;= 0) {
    puts(&quot;You have died&quot;);
    break;
}
if (E_h &lt;= 0) {
    puts(&quot;you win!&quot;);
    break;
}

and remove the second break. That functions the same, but you don't have to calculate attack values for a round you're not going to use.
As for your actual 'attack' section, it looks like you can significantly reduce that as well. You've got two options here: Either use switch statements or modify the program flow. switch would look like:
switch at_p
{
    case 0: 
        super_attack code;
    break;
    case 1: 
        regular_attack code;       
    break;
    default:
        idiot_code;
}

As for program flow: Notice that in both of the attacks, you have very similar/identical code.  If you code for the boundary conditions right, imagine what you could do with P_at = SP. You could significantly refactor your main loop.
I'd personally go for the switch statement simply because it's more amenable to future upgrades.
Other suggestions
Don't use stdbool.h. It's a lot easier to operate using int. Generally, false maps to 0 and true maps to anything that isn't false. (Plus, ints are normally 4 bytes big and bools are 1 byte big. You've got gigs of space to use.) I never use bools, and if I need to use them, I'll declare a union and make a utility variable that holds boolean flags.
Watch for program flow. A good maxim to work towards is having only one return location. Whether that's return, break, exit() or continue, minimizing the number of ways a program can escape a particular section of code makes it easier to debug. Oftentimes you can move things at the beginning of loops to the end, negate the conditional inside of an if statement, or otherwise simplify your code just by jimmying around with it a bit.
Keep track of variable's possible values throughout your code. If something has to be a certain value at a particular point in the code, then there's no point checking that value or setting it to what it already is. This can get a little more complicated with bigger code, but it's a powerful skill.
Suggestions for future features
Perhaps look at implementing some more options in the main game, such as

defending and armor
quitting from within the main game loop
breaking the attack/defend portions out into their own functions

Also take a look at

do-while loops
Switch statements
constants

All in all, your code is good, but there's a few modifications to program flow that can be made to cut down on operational complexity.