◇ Could this help me?
Yes, and this is one of the more complete workflows in circulation because the rules reinforce each other rather than being a list of tips. The two that carry most of the value are planning before any multi-step change, which converts an expensive wrong direction into a cheap conversation, and refusing to mark work done without evidence, since a confident completion claim on untested code is the most common way agent work goes wrong. The subagent rule is sound for the reason given, that separate context windows keep the main thread from filling with exploration. General practice, with two honest adjustments: the ninety percent figure is rhetoric rather than data, and fix bugs autonomously with zero hand-holding needs the proof rule bolted to it, because autonomy without verification is how a plausible non-fix gets committed.
Set up these working rules for this project and tell me which ones conflict with how I currently work. One: for any task with three or more steps, plan first, write the plan as a checkable list, and wait for my approval before changing anything. Two: hand research and exploration to subagents, one task each, so the main thread stays clean. Three: keep a lessons file, and every time I correct you, write the rule that would have prevented it and read that file at the start of each session. Four: never tell me something is done until you have run the tests and checked the logs, and show me the evidence rather than asserting it. Then tell me honestly which of these will slow us down on small tasks, and where the threshold should be.