DEV Community: Rocky

I Wrote the Red Team Books I Wish Existed When I Was Starting Out

Rocky — Tue, 21 Jul 2026 11:37:13 +0000

A few years ago I was exactly where a lot of you probably are right now: staring at a wall of penetration testing courses, half-finished Active Directory labs, and a YouTube playlist that promised to make me a "hacker" in 30 days. Most of it was theory. Some of it was outdated. Almost none of it explained why an attack worked, or how a defender would actually catch it.

So when I sat down to build out the Codelivly Offensive Security Series, I had one rule: no fluff. Every chapter had to earn its place by teaching something you could actually do in a lab, this week, and understand well enough to explain to someone else.

That series is now two books — Red Team Operator L1 and Red Team Operator L2 — and I want to walk you through what's actually inside them, because I think they solve a real problem in how offensive security is taught.

The problem with most red team content

Cybersecurity education has a split personality. On one side you've got theory-heavy books that explain what Kerberoasting is without ever putting you in a domain where you can try it. On the other, you've got scattered tool tutorials and one-off write-ups that teach you to run a command without teaching you why it worked or how it maps to a real engagement.

Neither builds the thing that actually gets people hired or promoted: a mental model of how enterprise attacks unfold from initial access to detection.

Red Team Operator L1: the foundation

L1 is built for the beginner who's serious about going pro — the SOC analyst who wants to cross over to offensive security, the student who's tired of tutorials that never go past "here's how Nmap works," the IT professional who wants to actually understand the attacks they're defending against.

It walks through the full arc of a foundational red team skill set: building a home lab with Kali, Windows, and Active Directory, networking fundamentals, OSINT and reconnaissance, scanning with Nmap and RustScan, web app testing with Burp Suite, the OWASP Top 10 (SQLi, XSS, SSRF, XXE, and friends), password attacks, Windows and Linux privilege escalation, and a first real pass at Active Directory — Kerberoasting, AS-REP Roasting, BloodHound, PowerView.

Every chapter follows the same shape: learning objectives, plain-English explanations, hands-on labs, real attack scenarios, command references, and — this part matters — detection and mitigation insights, so you're not just learning to break things, you're learning how a blue team would catch you doing it. Everything gets mapped back to MITRE ATT&CK, and the book closes the loop with how to write a professional pentest report, because half of red teaming is communicating what you found.

Red Team Operator L2: enterprise depth

L2 picks up where L1 leaves off and goes after the stuff that actually separates a junior tester from an operator who can run a real engagement: multi-domain Active Directory, Kerberos internals, Resource-Based Constrained Delegation, AD Certificate Services attacks, Shadow Credentials, DPAPI and credential harvesting, Pass-the-Hash and Pass-the-Ticket, lateral movement, and network pivoting with tools like Ligolo-ng and Chisel.

It also pushes into territory most beginner-to-intermediate material skips entirely: Microsoft Entra ID and Microsoft 365 security assessment, Docker and Kubernetes fundamentals, and operational security — how to plan and run an engagement without blowing your cover. The whole back half is built around Purple Team collaboration and detection engineering, because modern red teaming isn't a solo sport anymore; you're expected to work with the defenders, not just around them.

Labs are built on Kali Linux, Windows Server, Active Directory, Ubuntu, Entra ID, M365, Docker, and Kubernetes — and you'll get hands-on with the actual tools operators use day to day: BloodHound CE, SharpHound, Certipy, NetExec, Impacket, Rubeus, Responder, Wireshark, and more.

Who these are for

If you're a cybersecurity student, an aspiring ethical hacker, a SOC analyst eyeing offensive security, or a working pentester who wants a structured way to level up into enterprise engagements — this series was built for that path, in that order. L1 gets you lab-ready and confident with the fundamentals. L2 takes you into the environments and techniques that professional red teams actually operate in.

I built these because I wanted the resource I couldn't find when I was learning — something that respects your time, doesn't pad chapters with filler, and treats you like someone who's going to use this knowledge in the real world, not just pass a quiz.

Red Team Operator L1 → resources.codelivly.com/product/red-team-operator-l1
Red Team Operator L2 → resources.codelivly.com/product/red-team-operator-l2

If you read either one, I'd genuinely love to hear what you think — reach out on X @rocky_rowdy_ or drop a review on the store. This series is going to keep growing, and feedback from people actually doing the labs shapes what comes next.

How I Cut My Claude Code Token Usage by 70% (and Got Better Output)

Rocky — Sun, 19 Jul 2026 10:20:07 +0000

A few months ago I was burning through my Claude Code usage before lunch. Every session felt the same: I'd describe a bug or a feature conversationally, Claude would go read half the codebase to figure out what I meant, guess at the fix, get it half right, and then I'd spend three more messages correcting course. More tokens, more time, worse code.

I fixed it — and the fix had almost nothing to do with "prompting tricks." It came down to changing when I write the prompt and how much thinking I front-load into it, instead of leaving that thinking for Claude to do live, in the loop, on my token budget.

Here's exactly what changed.

The real problem wasn't Claude — it was conversational implementation

When you talk to an agent conversationally ("hey can you fix the auth bug"), the agent has to do three expensive things before it writes a single line:

Figure out what you actually mean
Explore the codebase to find the relevant files
Guess at your constraints — what NOT to touch, what "done" looks like

All three of those cost tokens, and all three happen inside the paid session, often more than once, because the first guess is rarely right. Every round of "no, not that file" or "don't refactor the other function" is a full context reload.

The fix is to stop letting the agent discover your intent live. Do that work once, up front, outside the session, and hand it over as a single structured spec.

What I changed: master prompts instead of conversation

Now, before I open Claude Code, I write what I've started calling a master prompt. It's a plain-text spec I write myself (sometimes with Claude's help in a separate, cheap planning pass), and it always has the same shape:

1. Role / Context
A tight paragraph telling the agent what kind of engineer it's acting as and what the codebase actually is — not a generic "you are a helpful assistant," but the specific stack, the specific constraints.

2. Do-Not-Touch list
This one alone probably accounts for a big chunk of the savings. Explicitly listing files, patterns, or areas that are off-limits stops the agent from "helpfully" wandering into adjacent code, re-reading it, and re-reasoning about whether to change it.

3. Phase 0: Discovery
Instead of letting the agent explore ad hoc, I give it exact grep/bash commands to run first, targeted at exactly the files that matter. Discovery still happens — it just happens efficiently, against a map I already know is correct, instead of a blind crawl.

4. Numbered issues with before/after expectations
Each task is a numbered item with a concrete before-state and after-state. No ambiguity to resolve mid-session, no "wait, what did you mean by fix this."

5. Acceptance criteria
A checklist the agent verifies itself against before declaring done — including real browser verification where relevant, not just "the code compiles so it must be right."

I paste this whole thing in as one message, as plain text (never as a markdown file the agent has to open and re-read) — Claude Code, or Cursor, executes in agent mode against it in one continuous run.

The rules I enforce on every single prompt

Three habits, repeated on every task, are doing most of the heavy lifting:

Discovery before code. The agent maps the actual codebase against my Phase 0 commands before writing anything, so it isn't hallucinating structure.
Real verification, not assumed verification. If it's a UI change, it checks in an actual browser. If it's an API, it hits the actual endpoint. Assumed success is where silent rework and follow-up sessions come from.
One commit per concern. Bundling five fixes into one giant diff means the agent has to hold five contexts in its head simultaneously, and so do I when reviewing. Splitting it forces smaller, self-contained context windows per unit of work.

Why this actually cuts tokens (not just "feels tidier")

The token savings aren't from writing less — the master prompt is often longer than my old one-line asks. They're from writing it once:

No exploratory back-and-forth burning turns on "what did you mean"
No wandering into files outside scope, reading them, then discarding that context
No re-explaining constraints three messages in because the agent drifted
No redoing work because "done" was never actually defined

Every one of those failure modes multiplies your context size every single time it happens, because the whole conversation history rides along with each new turn. A tight, unambiguous prompt is a shorter total conversation, even though the first message is bigger. That's where the 70% came from in my own usage — it wasn't one trick, it was removing the entire class of clarification loops that conversational prompting invites.

What this looks like in practice

If you want the actual templates — the exact Do-Not-Touch structure, the Phase 0 discovery commands I reuse across projects, the acceptance criteria checklist format, and the broader system I use for running Claude Code like a real engineering workflow instead of a chat window — I wrote all of it up in The Claude Blueprint: Master AI Workflows Like a Pro. It's the workflow this whole post is describing, just with the actual prompt templates included so you don't have to reverse-engineer them.

The short version

If your Claude Code sessions feel expensive and unpredictable, the problem usually isn't the model — it's that you're asking it to think and discover live, on the clock, instead of handing it a spec you already thought through. Move the thinking earlier. Give it boundaries before it starts, not corrections after. The tokens you save aren't from saying less — they're from never having to say it twice.

I Got Tired of Cybersecurity Being Taught Like a Second Language. So I Built a Translator.

Rocky — Wed, 15 Jul 2026 18:25:41 +0000

Every cybersecurity beginner hits the same wall.

You open YouTube. There are 400 videos on "how to become a SOC Analyst." None of them agree on where to start. One says learn Python first. Another says skip straight to Splunk. A third assumes you already know what a SIEM is.

You open a bootcamp page. $2,000. Fixed schedule. A syllabus that reads like it was written for someone who already has the job.

You open a certification roadmap. It's a wall of acronyms — CompTIA, OSCP, CEH, SOC+ — with zero explanation of which ones actually get you hired versus which ones just get you broke.

Nobody tells you the order things unlock in. Cybersecurity isn't taught like a skill tree. It's taught like a pile.

I know this because I lived it. I'm a final-year cybersecurity student, and for two years I was the person drowning in that pile — bouncing between free tutorials, half-finished courses, and forum threads trying to reverse-engineer what a "learning path" was even supposed to look like.

So I built the thing I wish existed.

—

Codelivly isn't a course library. It's closer to a skill tree for cybersecurity careers.

Instead of "here are 200 videos, good luck," it's structured like this: pick a role — SOC Analyst, Junior Penetration Tester, more being added — and every module unlocks in the order you'd actually need it on the job. Networking before log analysis. Log analysis before SIEM tools. Linux before Burp Suite. No guessing which video to watch next at 2am.

But sequencing alone doesn't stick. So there's a second layer: you don't just watch, you do. Real CTF-style labs running in Docker containers. Actual flags to capture, actual environments to break into, not screenshots of someone else doing it.

And because motivation dies fast when progress feels invisible, I built in XP, streaks, ranks, and certificates that are tied to labs you've actually completed — not just a "100% watched" badge that means nothing to a hiring manager.

—

Here's the part that might actually interest you more than the product: I built all of it alone.

No co-founder. No dev team. No designer. While attending college full-time.

The UI, the auth system with 2FA, the Stripe and PayPal billing, the CTF lab infrastructure, the certificate pipeline — every line, every lesson, every module. Not because solo-building is some badge of honor, but because I couldn't afford to wait for a team to exist before I started fixing the problem I was stuck in myself.

The hardest part wasn't the code. It was saying no. No to feature creep. No to "wouldn't it be cool if." Every yes went to one question: does this actually help someone get hired? If not, it didn't ship.

—

If you're a student, a career-switcher, or just someone stuck in tutorial hell right now — the first lesson of every path is free. No card, no catch. Try it and see if the structure clicks the way it should've clicked for me two years ago.

👉 Https://codelivly.com

If you're building something solo right now too — I'd genuinely love to hear what you're stuck on. Reply below.

🚀 I Built CODELIVLY — A Platform to Learn Cybersecurity Through Hands-On Practice

Rocky — Sun, 12 Jul 2026 21:27:50 +0000

Over the past year, I've been building CODELIVLY, a cybersecurity learning platform focused on helping beginners and aspiring professionals learn by doing instead of just watching videos.

🔗 Website: https://codelivly.com

Why I Started

When I began learning cybersecurity, I found myself jumping between YouTube tutorials, blogs, PDFs, labs, and documentation.

Everything was scattered.

I wanted one place where someone could:

Learn the fundamentals
Practice real concepts
Track their progress
Earn certificates
Engage with a learning community

That idea eventually became CODELIVLY.

What the Platform Includes

The goal wasn't to build another course website.

Instead, I wanted to create an ecosystem for continuous learning.

Current features include:

📚 Structured learning paths
🎯 Career-focused roadmaps
🧪 Hands-on labs
📝 Interactive quizzes
🏆 Certificates
👥 Community discussions
🎮 Competitions
📖 Cybersecurity glossary
🛠️ Free cybersecurity resources and tools

Everything is designed to help learners progress from beginner concepts toward practical cybersecurity skills.

Tech Stack

The platform is built using a modern web stack, including:

Next.js
React
TypeScript
Node.js
PostgreSQL
Prisma
Tailwind CSS

A lot of effort also went into the admin dashboard for managing content, users, certificates, learning paths, analytics, and community features.

What I Learned

Building the platform taught me that software isn't just about writing code.

It's also about:

Designing intuitive user experiences
Structuring content effectively
Handling authentication and permissions
Building scalable admin tools
Listening to user feedback and iterating

The product has evolved significantly since the first version thanks to community feedback.

What's Next

I'm continuing to expand the platform with:

More practical labs
Additional career paths
More community features
Better learning analytics
Improved mobile experience
New free cybersecurity tools
I'd Love Your Feedback

If you have a few minutes, I'd really appreciate any feedback on:

Overall UI/UX
Learning experience
Navigation
Performance
Features you'd like to see
Anything that feels confusing or could be improved

Website:
👉 https://codelivly.com

Thanks for taking the time to check it out. Feedback from the developer community is incredibly valuable as I continue improving the platform.