Video Companion

[Part 4] How to Build an Astro Blog Post Layout – Hero, Components, Image Optimization (AI Prompts Included)

YouTube Description

+

🔥 Steal the exact AI prompts + workflow from this video: https://thomasfellows.com/videos/astro-blog-post-layout-ai-prompts/ In this video, I build a complete Astro blog post system using AI — including the post layout, reusable components, responsive design, and Astro image optimization. No WordPress. No page builders. No coding experience required. ⏱️ TIMESTAMPS 00:00 The “perfect prompt” myth https://www.youtube.com/watch?v=EojC3UF3UFQ&t=0s 00:15 What we're actually building https://www.youtube.com/watch?v=EojC3UF3UFQ&t=15s 00:51 Why Astro image optimization matters https://www.youtube.com/watch?v=EojC3UF3UFQ&t=51s 01:01 Building websites without coding or page builders https://www.youtube.com/watch?v=EojC3UF3UFQ&t=61s 01:13 Overview of the full AI-first website series https://www.youtube.com/watch?v=EojC3UF3UFQ&t=73s 01:39 Building a real-world website system https://www.youtube.com/watch?v=EojC3UF3UFQ&t=99s 01:53 Where to get the prompts from this video https://www.youtube.com/watch?v=EojC3UF3UFQ&t=113s 02:05 Project walkthrough and final result preview https://www.youtube.com/watch?v=EojC3UF3UFQ&t=125s 03:11 Planning the post layout structure https://www.youtube.com/watch?v=EojC3UF3UFQ&t=191s 04:45 Building the hero section https://www.youtube.com/watch?v=EojC3UF3UFQ&t=285s 14:37 Structuring the blog post content area https://www.youtube.com/watch?v=EojC3UF3UFQ&t=877s 19:50 Creating the sidebar layout https://www.youtube.com/watch?v=EojC3UF3UFQ&t=1190s 24:15 Related posts section https://www.youtube.com/watch?v=EojC3UF3UFQ&t=1455s 29:54 Building reusable video components https://www.youtube.com/watch?v=EojC3UF3UFQ&t=1794s 35:34 Creating inline call-to-actions https://www.youtube.com/watch?v=EojC3UF3UFQ&t=2134s 42:58 Styling reusable content components https://www.youtube.com/watch?v=EojC3UF3UFQ&t=2578s 47:18 Building the author box https://www.youtube.com/watch?v=EojC3UF3UFQ&t=2838s 51:48 Related posts improvements https://www.youtube.com/watch?v=EojC3UF3UFQ&t=3108s 58:27 Responsive sidebar fixes https://www.youtube.com/watch?v=EojC3UF3UFQ&t=3507s 01:05:37 Final reusable component refinements https://www.youtube.com/watch?v=EojC3UF3UFQ&t=3937s 01:08:24 Mobile responsiveness testing https://www.youtube.com/watch?v=EojC3UF3UFQ&t=4104s 01:12:55 Converting the entire site to Astro image optimization https://www.youtube.com/watch?v=EojC3UF3UFQ&t=4375s 01:18:24 Responsive image optimization improvements https://www.youtube.com/watch?v=EojC3UF3UFQ&t=4704s 01:21:11 Final sidebar cleanup and testing https://www.youtube.com/watch?v=EojC3UF3UFQ&t=4871s 01:26:40 Final walkthrough and results https://www.youtube.com/watch?v=EojC3UF3UFQ&t=5200s This video is part 4 of my AI-first Astro website series where I'm documenting the full process of building a real SEO-driven website system using AI tools and modern web development workflows. You'll see how I structure reusable components, create scalable layouts, improve mobile responsiveness, and implement Astro's built-in image optimization system for better performance and cleaner code. 🔗 Resources * https://astro.build * https://docs.astro.build/en/guides/images/ * https://code.visualstudio.com * https://tailwindcss.com * https://docs.astro.build/en/guides/content-collections/ * https://docs.astro.build/en/guides/integrations-guide/mdx/ This video is for: • Web designers transitioning away from WordPress • Beginners learning Astro with AI • Freelancers building scalable website systems • Anyone interested in AI-assisted web development workflows Key outcomes from this video: • Build a reusable Astro blog post layout • Create scalable content components • Improve mobile responsiveness • Implement Astro image optimization correctly • Build a cleaner AI-first workflow for real projects 🔥 Get the prompts, workflows, and resources used in this video: https://thomasfellows.com/videos/astro-blog-post-layout-ai-prompts/

Published

May 7, 2026

Tags

Transcript

+

Here it is, the perfect prompt. Watch this. Enter and done. Look at this. Full post layout, styling. components, reusable components. I could never do this by myself. This is incredible. Yeah, I know that's obviously not how it actually went down. This video is over an hour long, and there's a reason for that. No, it didn't just take 3 seconds, but this is what I actually built. In this video. I built the entire post layout system for an Astro website using AI. We build the full layout for the post collection, the hero section, a complete sidebar, and multiple reusable components, including a video component, inline call to actions, a next step section, an author box, related posts, and a full end of post-call to action. Then we make the entire thing fully responsive and make sure it works perfectly on mobile. We also convert every image on the site to use Astro's built-in image optimization, and that part is a game changer. Do not skip it. And finally, we codify the entire design system, headings, lists, block quotes, spacing and typography. So everything is consistent across the entire site. And I'm doing all this without coding, without page builders and without plug-ins, or jumping through admin panels, and you're seeing the exact workflow I use so you can adapt it to your own projects. This video is part 4 of a series I'm making that will likely include over 10 videos. I already covered scaffolding the project, finding design inspiration, and built a homepage hero, and created an SEO driven content system with front matter and schema. And this series is different because I'm not just posting videos where I run 5 prompts to get something that looks good, but isn't a full workflow and doesn't have an actual business use case. You get to see the whole workflow without fluff or making you search through 15 different tutorials on YouTube to connect everything together. This is about building a real website system you can confidently use for yourself or for your clients. That's the bigger idea behind this series. This is a long video, so you can use the timestamps in the description or the chapter overlay with a progress bar at the bottom of the video to skip around without getting lost. If you want any of the prompts from this video, They're available on Thomasfellows.com in an easy to click and copy component. So let's get to building it. But oh, one quick thing. At the very end of this video, I add one extra UX detail that isn't listed in the chapter overlay. It's small, but I think it makes the post layout feel way more polished. So here's prompt one that you can get on Thomasfellows.com, and this prompt creates the structural foundation for individual post pages. This isn't the final design, but it's the skeleton. The hero, the article content, sidebar, and end of post components that we're going to plug into later. So let's go ahead and take a look at the prompt itself. I'm not going to read it verbatim. You can do that if you want, but I'll just give you a pretty good overall overview of the post. excuse me, of the prompt. That way you can see how it's structured, and then you'll notice that most of these prompts follow the same structure and pattern. So, I made it in a way that you could, if you wanted to, instead of just clicking the implement plan button inside of Codex, that you can go ahead and copy the prompt and paste it into a fresh chat for 0 context, 0 token usage. So that's the 1st part right here, right? And here's what it's going to implement, which is a layout file. The hero placeholder, because later we're going to get into creating the hero, and the sidebar placeholder, the content placeholder, and end of a post placeholder. So this is basically just a, a repeat of that exact same thing and it's telling us, it's telling the, uh, Codex what not to build, okay? And it's telling it basically to inspect the files that we have. And then, uh, it's output. It's dessert output. So what we do is that we're gonna copy this and we're gonna paste this into VS code and Codex. So once you're inside VS code, make sure you have your project open. Okay? And we'll go ahead and go over to the chat window with Codex. So in order to get to plan mode, you do the backslash plan and go ahead and click that, and then we'll go ahead and paste in our prompt prompt one. And let it work. So, it went ahead and produced deep prompt, so let's go ahead and take a quick look at it. It's pretty much customized to my repo to this project, right? So depending on how Codex decides to read your prompt. It may ask you if you want to implement the plan, or it might just end up as a prompt like this. So for me, it just ended up as a prompt, and I'm going to highlight it. And I'm going to copy in and paste it into a new chat and just go ahead and implement it right now. So, I'm gonna copy it. Click new chant. And then see what it produces. Okay, it ran for a minute and 36 seconds. It implemented the hero placeholder, the sidebar placeholder, the end regions and the post layout. But I'm gonna go ahead and just move on to going, gonna just go on to phase two, the prompt number two. We'll finish from where we left off in the previous video. So, yep, we have kind of the same, um, content that we had in the previous prompt. And then here's our more specific prompt details where basically what we wanted to do is create a clean readable article, styling for MDX content, right? And I want it to include everything that you might see inside of a regular blog post. So all the different headings, the paragraph link dialing, ordered lists, nested lists, black quotes, inline code, code blocks, images, tables, horizontal rules, all that kind of stuff. So, as you write your blog posts, uh, every once in a while you're going to use those elements, right? Um, so what I wanted it to do is also, not only create those is create a sample post so that we can see all of those things in context because I'm not creative, and it's not really easy to see if things look good by themselves, uh, on an island. You want to see them in context of what it would look like in a real post. So I told her to do that as well. Yeah. So we'll go ahead and copy this. You can go ahead and read it, verbatim word for word if you want, and alter it to your project's likings. So let's create a new chat and then we'll do a plan again. Do plan mode. We'll paste our prompt number 2 in here and let it get to work. And the, one of the reasons I'm doing plan mode between each prompt is because there has been changes to the code base. So you can see that it says it's going to inspect the repo first. So, it, let's see how, let's see how long it worked for. It worked for one minute and 5 seconds to create the plan. And critic clean, readable styling for a raw MDX content rendered inside the main post article column. So, uh, the beginning is more or less, uh, what I had in the original prompt, and it's getting more specific as to which files exist, and here's my content silos here. Here is the glossary term references on the schema, right? And we have the author that we created before mentioned, Thomas Pelos. And here, this might get interesting. So we're going to have a class created there. Okay, so use the site's existing visual language. So we have that. And I'm not going to go through it verbatim, but it's looking pretty good so far. So what I'm gonna do is copy this and start a new chat and we'll implement it. You could change a texture high too, if you'd like. Okay, it's 3 minutes and 30 seconds. It has the sample post running here. So let's go ahead and take a look. So we have our title, and we have some kind of initial excerpt and then the author and published date and then a featured image. So we have all that. We have our list, we have underline links. We have the code block, cord blocks looking nice. There's an inline image. There's table looks fine. It doesn't look like it is shown everything. So I don't really like the way the top of the post looks. We're gonna have to change that, right? And yeah, I don't want there to be an excerpt up here either. I don't know if that's a piece of front matter that they added. So we'll have to go ahead and make some adjustments here. So, but on a 1st run it's looking pretty good. All right, so I'm going to go ahead and give uh, some feedback to VS code and Codex to change this a little bit uh, on what I want changed as far as the uh, content styling elements. As far as the layout itself for the post, it seems that there's a lot of headings that look very similar. And we want the headings to be distinguishable from each other, especially headings one through four. So, I'm not sure how you want to do that, but try to make them a little bit more stylized so we can tell the difference between them. Along with that, since right now I'm reviewing the style of the post elements, like the headings, inside of each heading. I want you to literally type the text H1H2 inside there so we can see what it is and give feedback on each one individually. I want you to make the link stand out a little bit more, maybe make the text italic, italics, and because right now it just kind of looks like a bold underline word, you don't, yeah, so make it italic. A little bit more recognizable as a link. The code block looks pretty good, but the 2 blues are too similar. I want you to make them different colors. And then along with that, you have these. It looks like code outside of the code block, like button underscore click. It is highlighted in this light blue, and instead of matching the website's theme, haven't match a code theme with a code block. So it's distinguishable as code, instead of just some highlighted text, because that's what it looks like right now. For the black quote, make the text bigger and then also add a quotation mark inside of there too. So make it really stand out as a big black quote. Um, the table's looking good, and yeah, if there's any elements for the, like the content elements styling that you didn't show me, then go ahead and put those into this post too. And we'll go ahead and take a look at that and review it. It ran for a minute and 39 seconds. Let's see our results. We have H1, it's big, H2, H3, H4. Okay, I think the code block, and that is good. But all the rest of it, I think, is not good at all. So let's go ahead and try to make some more adjustments. Imagine that you are the best web designer ever. You have amazing skill and taste. The headings should all look like headings and be recognizable as headings. H1 and H2 should have different funds. Again, we want them to be differentiated, but not like random elements that aren't even headings. And for the black quote as well, don't use the same font as the H one, make it a little bit bigger and make the quotation mark look much, much bigger and cooler. All right, we'll send that through and see what happens. Again, I'm not, I'm not creative, so I just had basically to make it look better. So hopefully it does. So it says that each 3 were being pushed into decorative treatments. So they're gonna stop treating them like components. So I guess that's computer talk for what I said. All right, let's check it out. Okay, there's H2, H3. Okay, we're back to, more or less, just size differentiators. Okay? The black quote is looking much better, but it's kind of cut off. Let's go ahead and give it one more pass. The underline for H2 shouldn't go beyond the text itself. Also, for the headings, we should follow the same rules for title and as far as capitalization that each word should be capitalized. And have H3 and H5 be slightly lighter in color. And then for the black quote, the quotation mark itself is cut off. So maybe give some more padding around the black quote so that the quotation mark isn't cut off by the border. And then since you're the best web design ever, you can take one more quality assurance, check on the other elements, design elements. And says it's good to go. So see what we got. Okay, H3 is a little bit lighter, giving it some differentiations. H 5 as 2. H 6 is following that same pattern. That looks good. Uh, the black quote. So, I think there's one problem there, and that the quotation mark is too close to the text. I think other than that, everything else is looking good. So let's fix that and then call it a day. Everything's looking pretty good now, except for the black quote, the quote, the quotation mark itself is up against the text too much. So put some space between the quotation mark and the text itself, then we should be good to go. So after that's done, what we're gonna do is we're gonna make all these design decisions as part of the permanent, um, design system. Of course, it's changeable. All right. Okay, that's looking pretty good. And what else? Is there anything else to change? Maybe a little bit more breathing room between the text and the headings. and then it's good. I'll just leave it as it is. Can change it later, if I feel like it doesn't look good. So, All the design decisions that we just made. What we want to do is codify them and make them permanent inside of our website's design system so that our website has consistency and design across the entire website. So go ahead and make those into a permanent fixture of our design system. I said the same thing, like 3 times in 3 different ways. So, should should hold. All right, it worked for 2 minutes and 2 seconds. So, if you are a CSS guru, if you want, you can go into the project files and verify manually, but I'm just gonna do a verbal verification. That's pretty much it for that prompt, and we're going to move on to the next one. So previously, I said that I didn't like the way the hero section was done. I already had an idea for the hero section, and that's what we're going to take care of now with the 3rd prompt. So if you go down to the 3rd prompt, the hero section. What I want it to have is a featured image, a post-title, breadcrumbs, author, which is, we have a content collection for that. The published date, reading time and glossary tags. Now, I'm not exactly sure how it's going to handle breadcrumbs or reading time, and I'm just going to let the, I'm just going to let Kodex take care of how that's going to work out. You can go ahead and read through the prompt verbatim if you want, but it's essentially following the exact same structure as the previous ones. So we'll copy prompt number three. We'll go back over here. We'll get a new a new chant. Switch this back to medium, get into plan mode. So it applies to the specifics of your project. So it has created a detailed version of the prompt I gave it based on my people's structure. Okay, so it's going to replace the current hero placeholder. And let's give it a go. Well, copy this prompt. Get into a new chant. And this one, this one could be some advanced stuff again, so we'll just go to, we'll go to high, as far as reasoning, and let it get to work. All right, it worked for 2 minutes and 16 seconds. It implemented the production of the hero. So, we don't have an image here. to look at, and the layout is a little bit wonky. So let's go ahead and change that out, and give it some more details on how we want it laid out. So the hero is looking quite bland, so let's go ahead and change that up right now. In the hero section, we have a little pill above the H one that says electrician websites. I want you to completely remove that. So tell me how you got that there. But I don't like it and remove it. It should be full width, and you have no placeholder image in there. I want to see a real image in there so I can get the full context, right? It doesn't have to be, you know, matching, you know, any kind of theme or anything. Just get an image in there so I can see what it's going to look like. Then the H one will be, it will not be next to any other elements. Then the author, publish date and read time, can have a little dot in between each and give read time a little clock icon, I guess. So it looks better. And then there's the glossary content collection reference tags down there. They look very random and not styled or anything. So stylized that or let it stand out or do something, so it's more obvious what that is, right? Yeah. So the entire hero itself looks very bland and it doesn't look like the heading or the hero let of a beautiful post. So imagine yourself as the best web designer ever. and then recreate this layout to be incredible. Give yourself a little bit of creative freedom. So take that feedback and get to work. So hopefully that produces something good. If it doesn't, then I'm going to have to go out and then find some example, a blog post heroes to upload and then just tell it to copy, right? Which is a pretty good strategy, but I'm just letting it get some creative freedom at the moment because I want to see what it can produce. Okay, so yeah, the excerpt was from the front matter. And yeah, that's part of the SEO metadata, so we don't want to remove the field itself, just remove it from the visible, visible being visible on the post. Okay, I worked for 3 minutes and 19 seconds. Says we're good to go, so let's take a look. What we have. So this is the hero we have, and I looked at Brixies, and I went to their single post hero section, and I didn't really want to use one of these, although they're good, so I just did a regular Google search for single blog, post hero examples, and then I found this Crackle Black one. that I ended up liking. So that's what we're going to use as the basis for the next attempt. So I'll go ahead and get that image and I'll post it in here. Upload it in here, and then I'll give it some advice. If you look at the image, it has nothing above the featured image. But what I want you to do is I want you to put the breadcrumbs above the featured image so that the person's face, that that image should come from the author's avatar image, from the author's content collection, right? And then under all that is the title of the post. There's also on the bottom right, some social sharing icons. I do like the social, social sharing icons, but I don't like its location, or maybe the location's good, but I'm just not sure that a good way to implement it. So an immediate good way to implement the source sharing icons. You can do it now, or you can recommend that we put them at a different location of the post at a later time, say, in the sidebar or somewhere else. So, go ahead and take that feedback and update the hero section for this. All right, it worked for 2 minutes and 6 seconds. Let's go ahead and take a look. At the result. Okay. Okay, yeah, this is looking much, much cleaner now, so I don't like that. See if that works. Okay, all right, so let's give it some feedback. The featured image, it needs some kind of border or shadow or something of that type. That way it can stick off of the page a little bit better because, for example, this image has a white, if it's very white, and so the edges looks like it blends right into the block post. Give a tiny bit more space between the author Avatar image and the text below it, like the published date, that line. Also, the referenced glossary terms, that card, it is, yeah, it's looking a little bit too light, so that blends in too much to the background as well. Yeah, stand out a little bit better. And then I know the content collection is called glossary terms, but from a UX perspective, it doesn't really mean much. So, we need to come up with something better here. I don't know if it's a title or if it's an instruction. You can come up with a different title if you want. Like, I don't know, topics or I'm not sure or just say related topics or something like that. Yeah, I'm not sure, but there should be some better UX to that. what I'm talking about. And yeah, as far as, as far as the, um, alignment too, the breadcrumbs do seem a little bit out of place, being at the top left, like right above the featured image. So I'm not sure if they need to come down to the area of the H one and the reference to glossary terms and all that type of thing or how we want to take care of that. But it looks kind of out of place right now. So, and the breadcrumbs, it's not necessarily obvious that it's clickable. So maybe we can change the styling there. It's kind of strange, it's like two-thirds of the whole thing. Maybe, yeah. So either make that full width or make no card. I'm not sure how the styling you want to change there. But anyway, remember that you're the best web designer ever. So go ahead and take that feedback and make it better. All right, it worked for one minute, said it changed all that. Okay, it's looking a little bit better because they're all used for navigation, so let's change that up. I want you to integrate the breadcrumbs into the related topics card because at the end of the day, all of that is used for navigation and user experience, I'm not sure how you should integrate those, but integrate those in an intelligent way. See what we got. You are here related topics. Okay, yeah, this is this is looking cleaner and better. The only issue is that if we start getting more than 2 related topics, how that's going to end up. I think we just make it full width. For the navigation card where the you are here on the related topics, that one, it's very likely that some posts will have more than 2 glossary terms there. So I want you to make this card full width. And also, from a user perspective aside, yeah, no one's no one's going to click on something that says glossary. They don't want to know the definition of analytics down there on the sidebar. But glossary isn't good either, with that, with a list of those posts, right? So I'm still not sure the term to use there. When you click on it, you go to a page that is a glossary term itself. So that is correct, but as far as the user experience point of view, what is a better word? I'm a user. going to click on analytics, and then I'm going to go to a page as a definition, but at the same time, I'm going to have the the posts related to that topic, right? So in WordPress, we call it categories and tags. Maybe something more explicit, tells exactly what you're getting, not that. So hopefully, it's going to get my confusion. and come up with something better than I can. But we'll see. This is not good now. I do not like how the uh, I do not like how the breadcrumbs wrap. And we'll just call this related posts. How about, okay, let's do this. Should always be full width. I never want the breadcrumbs to be wrapping. It shouldn't ramp ever. The where it says definitions and related articles, have that say, posts related to colon, that should be fine. And then, yep, you can make that better. As far as wrapping. So there's a line that separates the breadcrumbs and the related posts, archive links, right? You can have that line, be responsive. For what I mean is, if there's a short breadcrumb, that line will move to the left, if the breadcrumb is long, again, we don't want the breadcrumbs to wrap, so that means that line will move to the right. All right, we are done. Okay, do we like these side by side or do we just want to stack them? Headcrumbs and the post related to? Which means that the you are here can probably be to the left of the breadcrumbs and the post related 2 can probably be to the left of those glossary term reference tags. Right, it works for 34 seconds. See our results. Still ugly because it's to the left aligned while the title is center. That card is still ugly because the stuff in the card is left aligned and the title and all that other stuff is centered. I don't know how to make this look good, but make it look good. Remember, you're the best web designer ever. It looks kind of plain. Can you make it look more interesting? Less plain. It's still too plain. It's a little bit too much now, but we can get rid of the pills. There's a black background behind you are here and post related to. Just get rid of the pill itself and then, you know, make the text darker again. And for the breadcrumbs, you can get rid of the pill here as well, that border and just have that text sit on top of the, you know, gradient background as it is. My dictation is not hearing correctly again. It said, behind the hero and pulse related to, should be, you are here and posts related to, didn't didn't pick that up well. So we'll see if it messes it up. It read it correctly. All right. Those are a little bit better. And that's nice. I guess we want to just want to change the style of these. Tags on the you are here card. There's a Tia line at the top, border. Can you make that thinner, like a lot thinner? Lately, it's been messing up. We're not being accurate. Okay, that's looking a little cleaner. That line is good, but the something a little bit awkward about it. It just stops at the corner. I don't know if it should extend like another little bit or make it look better. Am I being too picky? That looks cool. There we go. See, that's why I'm not a designer. Anything else? Oh. There's something I didn't notice is that this Avatar, the author Avatar image isn't isn't quite like the one here. Where is it? There's space between it and the image. I liked that. The author Avatar image circle, if you look at the screenshot I uploaded, there's actually space between that and the featured image, I want you to make sure that that space is there, and just, yeah, just like the image I uploaded. Uh, let's undo that. So I think we have to actually upload the picture again. So let's go ahead and take the picture. cut off the author's image. I uploaded the image of the I uploaded a screenshot of the featured image and the author avatar image. And as you can see, there's a space between the featured image and the author Avatar, like a round gap there. This is looking strange. It seems there's a border on the feature image itself now. If you look at the screenshot, it looks like the featured image is cut out around the Avatar, and it looks like what you did is just added a border around the Avatar image and a border around the featured image, just does not look like the uploaded screenshot at all, right? I'll switch us to extra high reasoning. You know, I'll upload the screenshot one more time. It looks like it didn't work. This might be a hard one for it. Or testing it. Its ability. 2 separate shadows so that way, each of those images comes off of the background at the moment. Okay, it looks like it's looks like we finally got what we were looking for. So that took a while, but I guess I was too picky and the style I want because I'm not creative. This says that we have an existing dirty work tree. I am assuming it's because I didn't submit the last changes to get. All right, I worked for 55 seconds and it's going to give us some props, the video ID, title, caption, class name. So, that's what I came up with, and let's go ahead and give it a go. Excuse me, the prompt. Okay, so I said it left the sample MDX file untouched because it's already part of the dirty untraked work tree. So what I'm going to do is ask it to go ahead and add the video component there. And then after this this component is done, then I'm going to go ahead and submit it to get. So the next thing we're gonna build out is a video component. This is prompt number 4 and it starts out the same as the others, just describing what kind of project this is. And then more or less just saying we want a component for a YouTube video in bed. We'll go ahead and copy that. Then we will create a new chat. Get it to plan mode. Paste that on in there. We'll move this back to medium, and get to work. This says that we have an existing dirty work tree. I'm assuming it's because I didn't submit the last changes to get. All right, I worked for 55 seconds. And let's see what it comes up with. Uh, so you're working in an existing Astro Until one project. Okay, it's gonna create a YouTube embed component. And then edit the sample to post. And it's gonna give us some props, the video ID, title, caption, class name. Let's go ahead and give it a go. So I'll copy this. And we'll paste in the post. Excuse me, the prompt. Let it get to work. Okay, so it said it left the sample MDX file untouched because it's already part of the dirty untraked, uh, work tree. What I'm gonna do is ask it to go ahead and add the video component there. And then after this component is done that I'm going to go ahead and submit it to get. Can you add a sample video component of this to the sample MDX post? That way I can see what it looks like visually. And yeah, you can give me, make sure the local server is started and give me the URL to view it. I took a break for a second. So when you do that, the local server often shuts down. So I had to restart it. Here is the embed itself. We have a link and that, yeah, I don't, it's strictly just an in bed. So I'm not I'm not a big fan of that. I'm looking for something that actually makes it a call out. So my original agency site. So if I go to, let's see here, must have pages for electrician website, I have something just like this right here. So it has the YouTube description, the transcript. I don't think I need either of those because this is more small scale, but that's too wide and I want it to be in line. So I could have the, yeah, it should be a horizontal card. So how, basically I just have it just like this, but maybe the uh, video on the right? Let's see here. I'll go ahead and take a screenshot of this and say to replicate something like this. So I uploaded a screenshot of something closer to what I want, which includes a subscribe button, a watch on YouTube button and the video title. You don't need the channel Avatar image, the channel link or the channel name, but definitely include those buttons and the video title, but I'm not sure if it's gonna look well. I look good and fit well and inside of a regular block postover needs to be stacked. So anyway, take that feedback and then update the video component. So it's saying that it's going to need the subscribe URL. So it's going to wire that up. much more what I'm talking about. Still, this, still feel like this is too, too difficult to tell. It's not there's not enough contrast there and I think I want the thumbnail to be a little bit bigger. There's not enough contrast between the component itself and the background of the site, and I think we want to change that to make it stand out a little bit more. Also, the card feels a little bit cramped, and I want the thumbnail to be bigger too. So I'm not sure how we're going to accomplish all of that while keeping it horizontal. We might have to stack some stuff. Anyway, take that feedback and redesign it. Oh, yeah, there's a much bigger contrast, but it just looks out of place now. Watch on YouTube. Let's see what it looks like. What is this? Me at the zoo. See if we did it like this. This is how they got it going. Don't really need to follow that playout. We got all this wasted Dwight space right here. And we already have watch on YouTube up there, so we don't need it down here as well. Theme, it's too high contrast, doesn't look like it matches a theme. So I'll get rid of that. Since the thumbnail itself already has a hover watch on YouTube button. We get let's get rid of the watch on YouTube button next to the subscribe button. Get rid of the little teal video text, then make the title and the little excerpt full width of the card. Yeah, we'll go with that for the moment. All right, 49 seconds and we got it the lighter. Oh, no, again, looks like it just randomly. blends into the post again, is remove the border around the left and the right and the top of the YouTube video, but make a frame continue from the left side of the YouTube video and the right side of it, down all the way to the bottom beyond where the subscribe is. If you if you get what I'm saying. And then make background, if you don't understand, ask clarifying questions. That looks any better. I think it's looking a little bit better. I'm just not sure. where this excerpt will come from. And in fact, I'm not even sure this should be at the bottom, but I think there doesn't need to be an excerpt to maybe put this subscribe button just right below the title or just to the right of the title. For the text and button below the video embed. We'll just go ahead and get rid of the excerpt there that says a compact video card can give readers, blah, blah, blah, get rid of that completely. And if the title runs long, then just have it wrap, but make sure the button stays to the right of the title. If there's any context that needs to be added, I'll just say it before the video component appears so the reader will know. I guess I didn't need to add that last part. That's just for me. get rid of it. The redesign. And, all right, it's looking a little tighter. Looking good I think I think that does it for the video component. Simple, simple is good. Does it play right here? Yeah, it plays right here too. Okay, good. Now move on to the next component. So before we move on to the next prompt, what I'm going to do is go ahead and make a commit, forget, because it seems like it, uh, Codex doesn't like it when I leave a bunch of stuff in there. So we'll come over here to the source control, and then we'll say, update post collection layout, stage all the changes, make a commit. All right. Yep, we don't have it synced yet, but that's fine. Call it a day for that. Now move on to the next prompt. Inline CTA component. So this is your basic, uh, call to action, book a call, subscribe, all that kind of stuff. So, right, here we have, flexible, flexible, headline copy, flexible, button, text, and flexible button URL. So basically the whole idea for this is I'm just going to add this component inside of a post. And when I create the post, I'll just have it have a relevant call to action based on what the post is. So, yeah, you can go ahead and take a look at it, but otherwise, we're gonna follow the same procedure that we've been following. Copy it, if it doesn't come up with something bold and interesting quickly. then we'll go ahead and move to the internet for some inspiration and take a screenshot. All right. It worked 55 seconds. And it's going to shoot out a call to action, and here's our props, headline, copy, button text, button URL. Optional label and class name. Added a real MDX sample to, so let's check it out. Where is it? Oh, it's looking pretty plain to me, but I don't have any good ideas. So I'm going to go to the internet to find some examples that I like and then copy, copy those. I will not copy them. Take after those. I'm looking for without an image. So there's only so much you can do there, right? But there's way too much text on this one. So I'll just give it a try. By myself without getting any inspiration yet. For this inline call to action. I don't want there to be the planning next steps, text above it, above the title, and we do not need any paragraph text. The only thing we want is just one big headline, a much the text, the font can be much bigger than that. And then we'll have the card itself needs to be much, um, have a, have much more contrast. So this call to action. This one should really stand out. It shouldn't look weird, but it really should say, look at me. So take that and make it a much more obvious inline call to action. All right, worked for one minute. So we got. Oh, this is much more bold, but I do not like a gradient here. It's a little bit strange or maybe it should stretch across the whole card. I want you to get rid of the left side border, that teal line, and then make the gradient on this card, go across the entire card and be a little bit subtle. Okay, then I think we're getting towards something more, look at me, but not crazy. Okay. So I'm not sure how we want to handle this gradient because the top left of the card looks a little bit strange. So, yeah, change it a little bit to make it look better. Uh, make the headline font a little bit smaller, and then also add a little bit more padding around it around the text, maybe at the top of the bottom for sure. All right, 20 seconds later, we got, at least that one goes with the button. Give a little bit more breathing room around the text. So it should be one unified card 23 seconds. The same issue exists. So, yeah, try again. I'll give you a screenshot. That way you can see. And allow the headline text to go a little bit closer to the button as well, but more breathing room on the top and bottom. Yeah, and fix that gradient. Make it a unified style, but I do like the glow ingredient, but it just doesn't seem quite like a unified card yet. This is good enough for me. So, I'll call it a day on the inline call to action. If I make post later and change this text, maybe I'll adjust a little bit, but for the for the time being, it seems pretty big and bold and good and clean. So, I'm satisfied. So the next prompt we have here is a next steps type of component is what to do next, right? And it essentially points the user towards one of 3 different options. And one is to have them read an recommended post. Want us to have them watch a recommended video. And then one is just to work with me, right? So it should be flexible enough for them to choose the next action that makes sense. So, I haven't really seen this implemented necessarily well in another location. So this is just a swing in the dark to see if this is going to be anything that's good or useful. And again, this is this is a component, so it doesn't have to go in a post necessarily, and get it going. All right. looks like it's finished. Let's see what we have here, or for a minute and 14 seconds. It's a self-contained reusable astro component with a recommended video, and the video has its own ID, title, description, link, and CTA, then the work with me next step. We'll move it up too high, at our prompt, and then let it get to work. And this is a somewhat complicated component, considering all the pieces, moving pieces associated with it. So it has the task list down here. All right. He worked for 4 minutes in 12nd, and we now have our, what, the new next component, and it said it added a sample next steps front matter to the no index, MDX sample post, but did they add the component itself? So let's take a look. All right, here it is. And where is the component? All right. What to do next? Here are our 3 options. So it's not bad, but there's a lot of text. So let's imagine you're a user and you want to use this. What to do next is good, but it should be an explicit instruction. So let's just give it some creative. Freedom to do that. It should be quite explicit to the user on what they should be doing next. So it says what to do next. We don't need another sub-paragraph that says pick the next step, right? That's kind of saying the same thing. It's just extra. So get rid of the pick the next step. that matches, get rid of that line. Then for the watch the video. And then that takes someone to, I would say, YouTube. And inside of that card, the thumbnail for the video should be visible, right? So since you already copied the styling for the inline call to action to that, that mini card, why don't you copy the video component styling to this little mini video card? And then for the post? It should, the call to action can be like read more or something like that. And yeah, I don't think we need the excerpt for the title should say enough. I guess I'll let you go, go away with that initial feedback and we'll move on from there. All right, I worked for a minute and 41 seconds. Let's see how it turned out. Somewhat consistent styling. How about you remove the excerpt for the video card and for the book an intro call card. So that you watched the related walkthrough before. Excerpt and the book an intro call and will identify the highest leverage excerpt, get rid of those excerpts. And then along with that, we'll have an image at the top of the continue learning card, taking up the same shape and space as the thumbnail of the YouTube video card up there. So, so that the continue reading. So the next recommended post, that'll be that featured image. And then for the book an intro call, I'll have to choose an image later, but you can put a filler image in there right now, a placeholder image. Again, the same shape on the top of that card as well. And then we want the buttons to all be centered. So the uh, so the YouTube Watch now button. That should be centered in the bottom center, just like the reading more and the book an intro call. Um, and then we could have the what to do next. Maybe we should put that as next steps, thinking about that, or I'm or potentially just removing that whole title and border itself. I'm not sure which is better. What do you think? So take that feedback and, And then also the, uh, the button for Reed Moore, it is not very, uh, visible. It's not easy to see. So make that a little bit, make that stand out a little bit more. And if you go to the homepage of this website in the hero section, there's a button that says start today, If you hover over it, there's a circle that pops out with an arrow. I want you to add that styling to the buttons on each of these cards. So the read more button and the watch now button and the book and intro call button. So take that feedback. make it a little bit better. All right, it works for one minute and 48 seconds, and let's see how it looks that we had before, just like the video component card. And the read more button. You can also have that go back to the same styling as the ghost button, like the homepage. And then when you hover over these buttons, they shouldn't go up or to the left. And then also it should be a circle, not a pill shape, card, and then have the video card when you move to the right side. All right, it works for a minute and 55 seconds. Let's take a look. Okay, much better. The arrow that pops out to the right. When you hover over the buttons, it should be a circle, not a pill. So if you look at the homepage, it's a circle. When you hover. Since there's no image, have the, turn this article into a practical improvement plan, and then it can be responsive to shrink as, if there's too much text. Let's take a look. Should be much bigger and fill the card, like I said, and be responsive. Now, if there's too much text, it shrinks. The max size for the text in the middle card can be a little bit smaller, and then also, for the text wrapping, you should never wrap in the middle of a in the middle of a word. And then after that, should be pretty good to go. I think it's looking pretty good now. So we have this component available if we ever need it. So I like it. Okay, make sure that this component is ready to be reused across the website when called upon. I never sent this message for my previous component, so we'll have to go ahead and do that later to make sure they're all finalized and then they don't get lost. Okay, and it's good to go. So what I'm going to do now is also make another commitment. All right, I create what to do next component. So I'll stage those changes and I'll make a commit, and now we have two. So the next thing that we're going to create is a component for an author box. Basically, it's gonna pull in the details from our author's content collection and just have a little author bio at the bottom of every post. Just make, hopefully it's going to make myself, um, more personable, make the, um, this website feel more real, not just, uh, just some agency that only lives online, right? That's kind of the idea behind it. So here's here's the author box, and it's kind of full in the name, uh, the biodescription. My avatar, which I haven't uploaded yet, and then an optional link to a page, or if I have other authors, I could link out to say a LinkedIn or something like that. So, hey, you can go ahead and take a look at this and adjust it to your use case. And all right, it worked for one minute and 29 seconds. All right, that was quite a long one for this little author box because of the related content collection and it's routing that has to do. So we'll go ahead and copy this. prompt. Get a new chant. Paste it in, move this to high and let it go. Okay, I ran for 3 minutes and 23 seconds. Can you go ahead and add the author box component to the MDX article content sample article? There it is. It's already there. We have 2 different width stylings going on, right? So we have to decide what, what, if it, any of this stuff should be full width versus the same width as the, um, post itself. So, for example, if I scroll up here and have the sidebar sticky and the sidebar scrolling down with me, which is what I'm going to do in a little bit, probably. Do I want this author box to be the same width as the blog poster at the bottom? And since it's not actually part of the blog post itself. Feels like it should be full width. Have the author's name. Appear under the author's avatar image, and then also have the about Thomas link, just have that link styling, be the same link styling that is used across the entire website. It doesn't need its special, its own individual special link styling. And then that link can say, learn more about, and then the author's name. I can't remember if the front matter has a 1st name, variable, and then a last name variable, or both combined, but if it's separate, you can just say learn more about 1st name, and if it's combined to say, learn more about, and then the full name. If you have any questions, then you can ask. Otherwise, you can get to work. We need some more breathing room between the author image Avatar and the paragraph, the about the author paragraph and the link over there. It's too cramped. So create some more space there. Just create more space all around the entire card itself too, like, I guess, more padding inside there. And then if you go up on the page, MDX, MDX dash, article dash content dash sample that, that post, and then under H3 services by intent, there's a link called analytics, that, that's analytics, that analytics, link styling. That's supposed to be the link styling that's used across the entire website. That should look like the analytics link up above, right? So I'm not sure how that got messed up, but it is messed up and it's fixed. And then the name under the author's image, Avatar image. The text is too dark, I think. Maybe you can make it the same color as the about the author text. All right, it worked for 57 seconds. All right, pretty good. Let's take a look. We still need more space between the about the author paragraph and the author's image avatar, more space between there, and you can create a little bit more space on the right and left of the card as well. Okay, it's looking pretty good. Make sure that this author box component is reusable and ready to be reused across the website, not just a single use case right here. is now more reusable. and wired for this one post playout. All right. So the author box is good to go, and then we can move on to our next prompt. So the next component that we're going to create for our posts content collection is the related posts component. So now what this is gonna do is it's gonna, uh, take a look at the this current posts, uh, referenced glossary terms, and then just recommend other posts based on that. So remember that we created the relationship between the posts, content collection and the glossary content collection, right? So the prompt that we have right here itself is mainly responsible for just making sure that that relationship is used to query the related post. doesn't really have much in terms of what the component itself should look like when it comes to styling. So, uh, this is gonna, this is probably gonna be a mixed bag when we use this one. So, You can go ahead. Yeah, it follows mainly the same structure as the other ones, as usual, but, yeah, it's gonna look at the current post glossary references, create other posts from it. Exclude the current post and then limit the number of results. I'm not sure if I wanted to limit the number of results. But maybe it could just be due the most recent ones, so it'll figure that out too, right? And output a reusable related posts section. So that is as far as that's the extent of the styling. So you can go ahead and read it verbatim, uh, go to thomasfellows.com. And take a look at it and adjust it to your liking and then go ahead and use it. So we'll copy this prompt, move over to VS code, and we'll start planning it. So one thing that I want to remind you of. While we make these is that if you're, if you're someone that is used to working inside of WordPress with, um, something like bricks builder to do these kind of query loops, then you're going to have to manually, um, click each individual or text area inside of your card that you're building to query, say, the post-title, the post-category or tag, and all that type of stuff while you're building it visually, um, with the styling and all of that. So there's a there's a lot of moving pieces inside of this type of component. But at the end of the day, you still have to wire it up to whatever you're using like ACF or Metabox. All right. So what to do next has no longer passed through the related posts. So let's take a look at it. See what we got. So it looks pretty good. I kind of figured it might look exactly like the other one. So now it comes down to, do I want it to just scroll through a random set of posts related to the glossary terms that we have here? Or do I want to separate these related posts by glossary term, right? I want the read article to say read more. That will be the link anchor text. And then, again, this read article link should follow the exact same styling as the learn more about Thomas Fellows link and the analytics link above on this page that should be being used across the website. Along with that, we want something so that we can, they can scroll through the related posts. So go ahead and add that, please. All right, it worked for a minute and 49 seconds. Let's see what we came up with. All right, read more is there, and we have the arrows. Okay, the related posts component is looking good. I want to make sure that you have it completed as a reusable component, so I can use it across the website. All right, yep, it's set up as a reusable component. So it is good to go. All right, we can move on to our next prompt. So the next thing that we're going to work on is the end of post call to action. So it's going to be very similar to the inline call to action, but it's going to be, uh, full width because the post will have already ended. And, you know, it's just one more opportunity to get the reader to go ahead and take the action, the desired action. So here's what it should do, promote the main service or offer, be reusable across posts, support a flexible headline and copy, and then optionally support different CTA variations based on the post-topics. So, you know, essentially the same thing as the inline call to action. Yeah, so we'll go ahead and copy this over and see what we end up with for this one. More than likely going to make this much more customized. Once I get my offer, more solid. And this is, this is, again, it says it's to be flexible, so, move it to plan mode, and we'll let it rip. All right, let's go ahead and cover it up. constraints do not build a full booking system or form. Yep, it's keeping it quite simple. Okay, it worked for 3 minutes and 12 seconds, and let's see what we ended up with. Oh, look at it. This is big and bold, call to action. I kind of like this. I need you to remove the part that says ready for an electrician website built around real leads. You can remove that part of this component, then you can make the main headline that turn this content plan into a website that books better jobs. Make that text, be able to reach, make it the area much wider. What I'm saying is that you can only have 3 words crossed and needs to be wider there. So fix that. And then on the book an intro call button, on hover, we do not want the button to go up. And we want the arrow to the right to appear, but it should be a circle, not this skinny oval looking thing. So go ahead and fix those and we'll take another look. Well, the text above the headline is called an eyebrow label. I gotta remember that. All right, Mark, worked for a minute, 23 seconds. Okay, there, there we go. Whoa. The button's crazy. You can go ahead and remove the paragraph below the turn this content plan into a website that books better jobs. I can remove that because we already have a supporting paragraph above the button. You can make that card a little bit wider. And then also, we don't want the button text to wrap into 2 lines. So fix that. Okay, it's looking pretty cool. I like it. So the next thing we're gonna do is create the sidebar for the blog posts, and that's gonna include a table of contents, and then the glossary context block, basically the tags, the glossary terms references, and then a newsletter call to action, basically just sign up, essentially just like this on the right side. See how it is sticking hangs out there, but it's going to be that plus a call to action. So, yeah, you can go ahead and, again, adjust a prompt to your liking and go ahead and make it. Now we're going to get to how the sidebar works on mobile later. But for right now, we're gonna work on that. So this is this is what it's looking like right now. So we're going to change that up, the styling too. So we'll get a new chat going. Move on over to medium. It has finished working after a minute and 10 seconds. So it's going to create table of contents. The lost Ray context block and the newsletter CTA just like we instructed, so. Now it is specific to our project in repo. All right. Worked for 2 minutes, 41 seconds, and we've got it added. Ooh, there it is. This is interesting. Okay, not what I was expecting at all for the glossary or the next steps. So, let's go ahead and fix it on up and this, this is ugly as well. The styling is not very good. It's hard to read the teal. It's hard to read the teal there. So, yeah, make it. Yeah, not teal, maybe less mold too. And yeah, just make it look more interesting, the table of contents. So it's easier to read. It's easier to follow. It's easier. Just make the user experience there better. And for the glossary card, have it, have the title of that card be something like topics covered or related topics, something like that. And then it should just, if you look at the card below the title of the post or it says posts related to, just have it have the exact same styling of tag buttons there. And then the card that says next step, that's completely wrong, I'll upload a screenshot of a newsletter sign up form, and don't take the styling from the screenshot, but take the elements, say it'll have a subscribe button in a checkbox underneath an email field, and it will say join newsletter. So go ahead and take that feedback. Also, the sidebar should be sticky. So when I scroll down the post, it stays yeah, it stays visible. Yeah, I should say explore topics. That's better. Let's see what that feedback produces. If the table of contents gets any longer at all, then, or if we have any more topics, then the join the newsletter thing will be not visible. So I think we need to go find some more inspiration. And try again. When it comes to the table of contents card, you have these numbers, 010203, I want you to remove those. And then to the left of each of the headings, you have this, these circles and this line, I want you to do something different. I'll upload a screenshot. of a different way to do it. Where I think, I guess, the bigger headers are more to the left and the smaller headers are indented to the right a little bit more. But there's also a line to the left of some headers. I'm not sure which ones will get a line to the left and how far that is to the left are indented or not. I'll let you figure that out, but I like that simpler styling better than what you have. So, yeah, I'll upload that screenshot. And then the 3 cards, table of contents, explore topics, and join newsletter, they all have a little bit different header styling, as you can see, join newsletter has a smaller font, and there's a line under it. So let's put a line underneath the export topics and table of contents too, and then make sure that they all have the same styling for the headers. On the joint newsletter card, you can go ahead and get rid of the paragraph that says get future video breakdowns. And then the subscribe button. Make it have the same styling as the book an intro call button on the end, the CTA component. Just applied to that join newsletter card. So you can take that feedback and we'll work from there. I do not like the borderlines on the table contents headers to the left. Yeah, they look strange. I think it's because they have a radius. So maybe remove the radius and also maybe get less padding to the left and right for those headings, that way. There's not so many orders wrapping. Also, you didn't change the subscribe button on the join newsletter card. All right, it worked for one minute and 24 seconds. Let's see what we got. I want you to take a look at the card below the title of the post. that says you are here and post-related to that card, and I want you to give the same styling to each of the table of contents, explore topics and join newsletter cards, minus the shadow. That way it looks a little bit more uniform. All right, work for it. Let's go ahead and check it out. Ooh, yeah, just a little bit lighter, not a lighter teal, just yet, make the gradient less strong. So there's more white than teal, I guess, you would say. And then make the on the join the newsletter, card, make the subscribe button left aligned. And then I think it should be pretty good to go. Okay, yeah, that's looking better. So I think the sidebar is pretty good to go. The next prompt that we have is the mobile pass. But basically making sure it's responsive and taking care of the sidebar on mobile. But before we do that, I do want to double check to make sure that all these components are set in stone. So, we're going to take care of that right now. For each of the components on the MDX dash article dash content dash sample page, I want to make sure that you have them all as reusable components and saved. So if this post goes away, these components are saved in our projects so we can reuse them over and over. So that includes all everything that, you know, the, you are here, explore topics, card above there, the table of contents, the sidebar, the in-line CTA, the video component, the author box, the, and the CTA, the related post, and the, uh, what to do next to make sure all those components. are saved and reusable beyond that. Make sure that the layout for the posts collection is how we have it right here. So obviously inside of the MDX body itself. I will have to explicitly tell you when I want to add the video components in line CTA those, but as far as after the MDX body, we should always have that author box, and we should always have the CTA, we should always have the related posts, and we should always have the what to do next. Those should always be there, and we should always have the sidebar. So make sure all that is taken care of. So yeah, this is just gonna clean up loose ends before we move over to make sure it's mobile responsive on the Join newsletter card in the sidebar. The subscribe button should not go move up on hover. Then on the video component. What I want you to do is I want you to slide the subscribe button over to the left a little bit, making groom for the little circle to appear with an arrow to the right of the subscribe button on hover. Always that hover animation should work consistently every time not getting weird and wrapping and all that kind of stuff. Then on the, uh, inline CTA, we also want to move that button, book an intro call button over to left and have the exact same circle with an arrow in it, appear on hover as the end CTA component. So if you have any questions about it before you implement and ask, make sure those changes are permanent and part of the components. Oh, look at this one. We have a deal one and this is way too far away. The arrow with a circle on the video component is TL. It should match the ed of the subscribe button. Also the YouTube video title, the width. You can make that way wider. There's a ton of white space between it and the subscribe button. So, use up that white space with the title. And again, make sure this is part of the component, not just an individual override. All right, it's good to go. All right. I like it. Okay, let's move on to the mobile pass. All right, so here on prompt 11, we have the mobile pass. Basically, we're going to make our desktop layout, mobile friendly and responsive. So, yeah, it's essentially gonna stack, stack the elements from the sidebar appropriately. So if we look down here, the desktop, sidebar should not simply appear as a cramp sidebar on mobile, obviously, it's going to become mobile friendly. So, for you appear, uh, in number three, it says the recommended mobile flow from top to bottom, the hero, mobile uh, table of contents, X out the box related post, and CTA, the newsletter, CTA. So, we may remove some of those, uh, after we see what it looks like on mobile. Well, yeah, since I didn't make a commit recently. It's getting angry about that again, saying I have a dirty work tree. It ran for just over 10 minutes. Let's go ahead and take a look. Oh. That looks strange, and it doesn't appear on however. Same as that. Our table scrolls. That's pretty common. Related post? Oh, they fix that up nice. This is not bad. It's pretty good on a 1st take. On mobile, what I want you to do is I want you to make the article title much smaller, and you can completely remove the, you are here, explore topics, card on mobile view, inline, call to action from the start. So, it should appear on hover, and then also it should be a circle, not an oval. And we have the same issue on the video component is that the arrow in a circle is visible from the beginning, not just on hover, to fix that. And then on the what to do next, the work with me card, the arrow in a circle appears even if we're not hovering. So it should only appear on hover, and it should be a circle, not an oval, and that exact same issue is happening on the watch, the explanation card of that component as well. And that same issue is happening on the join newsletter card. And that the arrow is appearing even though we're not hovering on the about the author card. You can go ahead and center the text about the author on mobile. And the CTA component, the button, the book an intro call button, again, the arrow and the circle is appearing even though I'm not hovering. So that seems to be a consistent issue across, almost everywhere. So, you can start by fixing those issues. Now, right? It worked for 5 minutes, so let's go ahead and take a, take a look, see how it's, see how it turned out. The hover behavior for the button on watch the explanation card, the book an intro button on the work with me card, and the read more button on the continue learning card should match the behavior of the button on join newsletter. And what I mean by that is that instead of having the button, shrink and have the arrow appear. The button doesn't change size and the arrow appears going to the right. All right, it works for 3 minutes, 19 seconds. Let's take a look. How we're doing. That's up closer. No, it's a little bit too close, yeah? All right. I think it's good enough for me. Mole pass. Oh, here's the tablet. How's a tablet looking? We still have a sidebar on tablet. Not too worried about tablet, but this is kind of strange. Now let that be. And to the next prompt. So the next prompt that we have is Prompt 12, which is going to be AstroImage optimization. But before we do that, I'm going to go ahead and do a commit, since we have quite a bit of changes here, that way. Codex doesn't get angry and confused. Optimization features, which helps you to do many things. And so the TDLR on that is that it makes the images smaller. It compresses them into WebPN AVIF. And then it also generates multiple sizes of the images. So depend, depending on what screen size you're on and what device, it has lazy loading. Um, prevents layout shift and also the image, uh, images are handled at build time. So basically, instead of having images being optimized on the fly at runtime, it's done at build time. And yeah, all that's all that's being done through Astro's image optimization. So we haven't actually defined that yet inside of our components and our pages. So you can, you can handle images each, each and every image differently based on your use case, right? But essentially, what we're going to do is we're going to go ahead and refactor the entire site, including all the components that we made in order to use Astros image handling. So, if you go to their docks, you can take a bigger look or a deeper look. at how it's actually done and if you are, if you have some very specific use case, you can go in there. But one of the things you might want to know, is that where to store images is the SRC versus public, right? So we recommend that local images are kept in SRC when possible so that Astro can transform, optimize, and bundle them, right? So basically if it's, if it's not in the SRC folder, if it's in the public folder, it's going to be, the images are going to be served as is an, uh, not optimized, uh, like you, you might necessarily want. So, so yeah, keep that in mind. one of the big factors. So I have a prompt, uh, Thomasfellows.com. that's gonna help you refactor it. So we're going to use this prompt inside of plan mode. That way, the plan mode can go ahead and analyze your project and then give you the best implementation plan. So it's right here. I want to refactor this Astro project, so all eligible images. Use Astro's built-in image optimization through Astro assets, right? So if you want, you can go ahead and read through the prompts. It's not long. But we're just going to go ahead and use it in planning mode. So we'll go back to VS code. We're in medium. We'll turn on plan. Plan mode, go ahead and into the prompt, and let it get to work. Now, when you build each individual, component, and page, inside of the prompts that you are giving it, you can give it the instructions to use Astro's image optimization handling at that time too. So by doing this, this is just another plug-in that you would have to mess with inside of WordPress for image optimization and conversion and compression and all that kind of thing. We now have our plan, refactor eligible content, and UI images in Astros, Astro Assets, pipeline, while keeping fixed URL assets in public. So, public assets found. Okay, so let's see what it has now. The earlier plan was too conservative. Move all rest images out of public and into Astro's asset pipeline. So yeah, make sure when they give you a plan to double check it and make sure that it's doing exactly what you want, because some of the stuff that we had already put on the website wasn't going to be optimized. So yep, just be mindful of that. And then, yeah, if you want, you can go ahead and implement the plan, which is what I'm gonna do. We'll have to make sure that it is A okay in the future. And when you do a website speed test, you'll often be able to find out if your website is so because of image handling. You can see on the left side here, the source control panel that the images have moved from the public folder to the SRC assets slash images folder. It has finished. And just under 5 minutes. And it moved the images out of public. It updated content schemas to use Astro image for Avatar and featured images and OG image. So I think we what we need to do is go ahead and check the edge case that it listed up here and then also do a quality assurance check. Before you had listed, um, edge cases that include the glossary featured image, um, to .2 non-existent public files. So I want to make sure that inside of all content collections we have, the posts, the authors and the glossary that the Astro image optimization features are being used. And even if there's not images currently being used by those content collections that it's wired up to do so in the future, so that every time that we produce a another post for one of those content collections, it's using the Astro image optimization. And I want you to do a quality assurance check to make sure that all images on the website are using Astro's image optimization features that's possible. And you should definitely double check to make sure that, um, the images are being optimized, um, at different screen sizes and, uh, the images are responsive and mobile friendly. So that'll probably take another 5 minutes just to make sure everything's working correctly and it'll probably capture or catch one or 2 things. as part of the QA pass. All right. So it made sure to wire the costary featured image as a normal, as the optional image rendered with picture when present, and then we should be good. That all the components currently built on this website are using Astro's image optimization features, and also that whenever we create a new component, or utilize a new reusable component that those will be using Astro's image optimization features. Uh, components instead of just using the original picture and image components. So it's a little bit over engineered, but at the end of the day, if we get accomplished what we want. That's what matters most. This conversation's context will end quickly. It's already compacting the context, so hopefully that doesn't affect the quality of the output. Is there a reason that you used the shared wrappers as opposed to the Astro assets import? Okay, so I still use, I asked, you know, why it's using those wrappers. So it still uses it inside of the wrappers, but it just added some defaults for the wrappers. Can you start the local server with the sample post URL given to me so I can take a look at how you did? All right, let's see how it looks. Seems to be working fine. No problems here. The images are working here, and let's see how it looks on mobile. All right, seems to be doing just fine. All right. So I think we'll call it a wrap on the image optimization, refactoring. And I'll leave the links to the Astrodox. They also have a blog post, if you want to read that as well. That's from 2023. So, let's move on to the next prompt. All right, we're on to our final prompt here. This is for the actual design system, for the entire website and the individual post collection content collection layout, okay? So if you go down here, it is going to codify the approved MDX article content sample styling into the project's overall website design system. Okay? So that means they're designed for the entire website, all the H ones, the bulleted list, the ordered list, the code block, all that styling should be, should take place across the whole website. Then it's going to verify the post layout as production ready. So, that means the posts content collection layout, okay? So that'll be, uh, since this is a post-content collection post, just the layout itself in that, uh, the sidebar and uh, all the stuff at the end, the related post, all this kind of thing. So that's its job. And you, what you might want to do is modify, um, book through here and then modify what the name of your sample article is or what your content collection is called, right? So this says there should be a sample post called the MDX article content sample. It might work for you, even without changing it, um, because, you know, the way it's titled, but that's the actual title that I have right here too. Go ahead and read through it and then change the prompt so that it does in fact work for you. So it's listed a couple different times. Go back over to VS code, get a new chat, put it to plan mode. Okay, it works for 58 seconds, and now we have our prompt, which want to double check the goal to make sure that there's kind of 2 different goals going on here. The site wide design system codification, and then also the post layout. And to shared reusable website level, design system, primitives, and verify the complete individual pulls outs, production ready across desktop, tap, and mobile. So we'll go ahead and copy this and then I get to work. Start a new chat. Give a high reasoning. Paste the prompt and let it go. Since I didn't do a commit. It's telling me my work tree is duty again, which I should have done to commit. between each prompt, right? Okay, so let's see what it did. It worked for 11 minutes and 53 seconds, and it made the content pros, the active reusable article primitive and post-playout. Astro, and post-content kept as a legacy CS as an alias. So it didn't just trash it. Consolidate the pro selectors and added shared post-primitives in global CSS. So hopefully it is working as expected. So let's go ahead and take a look at it on the front end. So a couple of the, a couple of the things changed as far as styling and and spacing. is concerned. So it didn't work. completely correctly. So that means we're going to have to do some. We gonna do some troubleshooting with this. What is being used right now on the posts content collection. And the reason I'm asking is because I told you to take the sample posts design and then make that the global design system, but some of the things changed. For example, the link styling has changed, and now it's black. The H3 used to be a lighter tint, but now it's darker, and the spacing is more cramped than it used to be. So again, don't change anything, but tell me what's going on under the hood. Do we have 2 competing design systems or one and what is taking presidents right now on the post content collection? I want you to condense that answer down into like, 3 lines. Is there a competing global versus post layout design system and what is winning? What is being used right now on the post-content collection, or is it a mix? Again, don't make any changes. And so what I'm going to do right now. So I'm going to make these commits. over here. And then what I want to do is I'm gonna tell it to remove the legacy post content class like completely, get it out of the file system. Then I'm gonna, once again, make my changes to the design here and call it a day. So let's make it commit. So we'll stay till our current changes. And the reason I'm doing this is that way I can easily press undo between each and every prompt. The 1st thing I want you to do is to delete the legacy design system, like you said, you said it's not being used right now. So just go ahead and delete it. That way, if I make a change, it's just going to take hold across the website, not be an individual override, right, right here. That way, when we do future edits, it's not scanned and taken into context and then start, they start trying to use it. I might I'm probably going to get pretty religious about doing commits during this part. Alright, so we'll commit those changes. And look, it's back. See, it was overriding it. So our styling is good again. There we go. All fixed. And all right. So as far as I can see then, the quality assurance and the codification of the design system is set and good to go. So here's our sample post and the UX. improvement or modification I want to make is to add a reading progress indicator. So it's kind of like this right here as you scroll down the page, it tells you how far you are from the end of the page. I'm not sure if it's helpful for conversions or UX or whatnot, but I kind of like it. So I'm going to try to implement that on post here. So let me go ahead and give it a little prompt to make it happen. I would like to add a reading indicator progress bar to the posts content collection, uh, layout, and I'm assuming you have to make that into a reusable component, and the way I want to do it is that if you open up the MDX dash article dash content dash sample post, there's a very thin line between the you are here and explored topics block and the actual blog post and table of contents. I'll upload a screenshot of it. And that's actually where I want the reading indicator progress bar to be. So when the post, uh, when the top of the screen gets to that and the sidebar starts scrolling, that's when I want the reading progress bar indicator to go ahead and scroll, um, be sticky and scroll together with the table of contents and it should be minimal and modern. So we'll let you get started with that. And I'm not sure if it should be, yeah, across only the width of the blog post content itself or across the post and the sidebar. But assuming it has to be mobile friendly. We might want to just keep it across the width of the vlog post content, but I'll let you make the call. So if you have any clarification questions. You can go ahead and ask me if not, I'll let you get to work on it. And yeah, I just, I updated the force picture, so that's what we have here. So we'll just go ahead and let it get to work. All right, worked for 3 minutes, 43 seconds. Implemented the reading progress bar. There's a new sticky, accessible progress component and the post layout Astro places it. Okay, so let's take a look and see how it is. Let's do a refresh and do not see it. There's the bar itself, it looks like. I think this is the bar right here itself, but it's not a sticky. So let's go ahead and fix that up. It looks like there's a new bar post, but I can't tell if it works or not because I'm not sure if that's the actual reading progress, component that you have there, and it's not sticky. It doesn't stick. But, yeah, I'll show you what I'm talking about with a screenshot upload. So you can take a look and see what the problem is. Let's check it out, see if it works now. It is working, but it's ugly because it will look better if it sticks to the top. I kind of like it, this, maybe not a stick. It seems to be working now, but I do not like the style. The background fill. We don't need, I guess, yeah, maybe we don't need a background fill to be more light and glow black. So, yeah. And yeah, make it stick to the top of the screen. All right, good to go. Let's see. Okay, it's really hard to see now. It's there and it works correctly, but it is so thin that it's hard to tell that it's even there. So maybe we need to make it a little bit thicker line, taller? Yeah, make the glow or the gradient or something like that, a little bit interesting. Still too difficult to see. This is strange. refresh it. Has some weird behavior. There's some kind of weird behavior where the progress bar starts in the middle of the post. I don't know if it's because I pressed refresh in the middle of the post, what the deal is. We need to make sure that the scroll behavior on progress works no matter where the page loads and where you are, that it should be at the correct position in progress and reverse back up. So, yeah, there's something strange about the progress and scroll behavior together itself. And then also, again, it's just way too difficult to see. Maybe we should go with a reverse the gradient, so the darker part is at the beginning and the lighter parts at the end, and again, make it thicker and more of a shadow glow. So make it at least, yeah, make it like double the thickness. Take a look now. It's much easier to see now. I'm going to take a screenshot eating indicator that I saw on the website. I want you to make a look at my theme colors and less dark. Let's see how it looks now. That's interesting. It kind of feels as it goes. Yeah, that's strange the, the fill doesn't, and I like how you have the entire press bar that you can see when it ends. So it's immediately visible. The, there's a blue in the middle that doesn't match my theme. It's like blue that's outside of this theme. So get rid of that and then just have the TL gradient that we have naturally go. Also, again, we're having problems with the parole positioning, that's when it starts and when it ends. So you need to take another quality assurance check on that. All right, it ran for 2 minutes and 26 seconds. Let's take a look. You get a hard refresh. Go back to the top. Okay, stops right there, sitting there. Let me go down. Is it still a little bit too thick? Can you make it about 25% less tall? And then after that, give it one more QA pass for both desktop and mobile? Actually, that's check mobile right now before we do that. Yeah, this working seems to work pretty good. Send on that. Get the heart refresh. looks good to go. Scroll on down. I think it's looking good. So what do you think? Do you think this was a good addition to the site or just kind of useless extra component? Anyway, that was the extra UX component that we added. So that'll be it for this this component. So now you've got a complete pulse layout system built with AI that you can actually reuse and scale. If you want the exact prompts I used in this video, go to Thomasfellows.com. In part five, we're building the glossary system and connecting it back into everything you just saw. If you want the full workflow, make sure to subscribe. I'll see you in the next one.

Beyond The Video

Companion Updates

Use this page to copy the phased AI prompts from the video and adapt them to your own Astro blog post layout build.

Key Takeaways

Build the post layout in phases instead of trying to prompt the whole system at once.
Treat the hero, MDX styling, sidebar, CTAs, related posts, and mobile states as one reusable content system.
Finish with QA and Astro image optimization before calling the layout production-ready.

Best Suited For

Web designers moving from WordPress or page builders into Astro.
Freelancers building reusable blog and content systems for client sites.
Beginners who want to use Codex prompts without losing the structure of a real production workflow.

Astro Blog Post Layout AI Prompts

Copy these prompts one phase at a time so Codex can build the layout, components, responsive behavior, and image optimization in a controlled sequence.

Core Layout Skeleton

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement the foundational post layout structure for individual post pages.

Important context:
This is not the final post design. This step is about creating the real structural foundation that later post components will plug into.

The implementation may include real layout/components such as:
- A post layout file
- A post hero placeholder component
- A content wrapper/container
- A sidebar placeholder component
- End-of-post placeholder components or slots/regions

However, these should only establish structure. They should not contain final content, final design, or advanced logic yet.

The layout should include:
- Hero region
- Main article/content column
- Sidebar region
- End-of-post regions
- Responsive desktop/mobile structure
- Semantic HTML
- Tailwind classes that match the existing project conventions
- Clean component boundaries that will make later implementation easier

Do not build the final versions of:
- Hero design
- MDX typography styling
- Table of contents logic
- Glossary context block
- Newsletter CTA
- Inline CTA
- Video component
- Related posts logic
- Author box
- Final end CTA
- Final marketing copy

Dependency rule:
Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for the layout scaffold, explain why it is needed before including it in the implementation prompt.

Please inspect:
- Existing routes/pages for posts
- Existing layouts
- Existing components
- Existing content collections
- Existing Tailwind/design conventions
- Existing naming and folder patterns

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. Constraints and what not to build yet
7. Dependency guidance
8. A final checklist for the fresh Codex chat to follow

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement the foundational post layout structure for individual post pages.

Important context: This is not the final post design. This step is about creating the real structural foundation that later post components will plug into.

The implementation may include real layout/components such as:

A post layout file
A post hero placeholder component
A content wrapper/container
A sidebar placeholder component
End-of-post placeholder components or slots/regions

However, these should only establish structure. They should not contain final content, final design, or advanced logic yet.

The layout should include:

Hero region
Main article/content column
Sidebar region
End-of-post regions
Responsive desktop/mobile structure
Semantic HTML
Tailwind classes that match the existing project conventions
Clean component boundaries that will make later implementation easier

Do not build the final versions of:

Hero design
MDX typography styling
Table of contents logic
Glossary context block
Newsletter CTA
Inline CTA
Video component
Related posts logic
Author box
Final end CTA
Final marketing copy

Dependency rule: Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for the layout scaffold, explain why it is needed before including it in the implementation prompt.

Please inspect:

Existing routes/pages for posts
Existing layouts
Existing components
Existing content collections
Existing Tailwind/design conventions
Existing naming and folder patterns

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
Constraints and what not to build yet
Dependency guidance
A final checklist for the fresh Codex chat to follow

The final answer should only be the copy-pasteable prompt for the next Codex chat.

Style the MDX Article Content

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement MDX content styling inside the post content column.

Important context:
The foundational post layout skeleton already exists or will exist. This step is about styling raw MDX/article content inside the main content area only.

Goal:
Create clean, readable article styling for MDX content elements and create one realistic sample post inside the actual `posts` collection so I can review the styling in context.

The MDX styling should cover:
- H1–H6
- Paragraphs
- Links
- Ordered and unordered lists
- Nested lists if appropriate
- Blockquotes
- Inline code
- Code blocks
- Images
- Tables
- Horizontal rules

Sample post requirement:
Create a sample post inside the actual `posts` collection that uses all of these MDX elements naturally inside a realistic article.

Do not create a fake style-guide page that just lists elements in order.

The sample post should read like a real article, where:
- H1 is used as the article title if that matches the project’s MDX/content convention
- H2s divide major sections
- H3/H4/H5/H6 are used only where contextually reasonable
- Lists appear where lists would naturally help the reader
- A blockquote appears as a real pull quote or quoted insight
- A table appears where comparison or structured information makes sense
- Code appears only if contextually useful
- Images appear with realistic placeholder usage based on the project’s existing asset conventions
- Horizontal rules are used only if they make sense in the article flow

The sample article should be polished enough to evaluate design decisions, but it is not final marketing content.

Important:
After I review and approve the MDX styling visually, this styling will later be codified into the project’s design system for repeated use across the website. For now, focus on creating and testing the article content styling in the real post context.

Please inspect:
- Existing post layout structure
- Existing `posts` collection schema and file conventions
- Existing MDX/content collection setup
- Existing global CSS, Tailwind config, typography utilities, and design tokens
- Existing article/content styling patterns, if any
- Existing image/assets conventions

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file
4. The implementation order
5. Project-specific findings from this repo
6. How to create the realistic sample `posts` post
7. How to style the MDX content elements
8. Constraints and what not to build yet
9. Dependency guidance
10. A final implementation checklist for the fresh Codex chat to follow

Constraints:
- Do not build unrelated post components
- Do not build the final hero section
- Do not build sidebar functionality
- Do not build CTAs, related posts, author box, video components, newsletter forms, or glossary blocks
- Do not over-design
- Do not add new dependencies casually
- Prefer existing project conventions
- If a dependency is genuinely required, explain why before recommending it
- Keep the styling scoped to article/MDX content where possible
- Avoid one-off styles that will be hard to codify later
- Preserve the existing layout structure

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement MDX content styling inside the post content column.

Important context: The foundational post layout skeleton already exists or will exist. This step is about styling raw MDX/article content inside the main content area only.

Goal: Create clean, readable article styling for MDX content elements and create one realistic sample post inside the actual posts collection so I can review the styling in context.

The MDX styling should cover:

H1–H6
Paragraphs
Links
Ordered and unordered lists
Nested lists if appropriate
Blockquotes
Inline code
Code blocks
Images
Tables
Horizontal rules

Sample post requirement: Create a sample post inside the actual posts collection that uses all of these MDX elements naturally inside a realistic article.

Do not create a fake style-guide page that just lists elements in order.

The sample post should read like a real article, where:

H1 is used as the article title if that matches the project’s MDX/content convention
H2s divide major sections
H3/H4/H5/H6 are used only where contextually reasonable
Lists appear where lists would naturally help the reader
A blockquote appears as a real pull quote or quoted insight
A table appears where comparison or structured information makes sense
Code appears only if contextually useful
Images appear with realistic placeholder usage based on the project’s existing asset conventions
Horizontal rules are used only if they make sense in the article flow

The sample article should be polished enough to evaluate design decisions, but it is not final marketing content.

Important: After I review and approve the MDX styling visually, this styling will later be codified into the project’s design system for repeated use across the website. For now, focus on creating and testing the article content styling in the real post context.

Please inspect:

Existing post layout structure
Existing posts collection schema and file conventions
Existing MDX/content collection setup
Existing global CSS, Tailwind config, typography utilities, and design tokens
Existing article/content styling patterns, if any
Existing image/assets conventions

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file
The implementation order
Project-specific findings from this repo
How to create the realistic sample posts post
How to style the MDX content elements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Constraints:

Do not build unrelated post components
Do not build the final hero section
Do not build sidebar functionality
Do not build CTAs, related posts, author box, video components, newsletter forms, or glossary blocks
Do not over-design
Do not add new dependencies casually
Prefer existing project conventions
If a dependency is genuinely required, explain why before recommending it
Keep the styling scoped to article/MDX content where possible
Avoid one-off styles that will be hard to codify later
Preserve the existing layout structure

The final answer should only be the copy-pasteable prompt for the next Codex chat.

Hero Section

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a production-ready post hero section for individual post pages.

Important context:
The foundational post layout skeleton and MDX content styling either already exist or are being built separately. This step is only about the post hero section.

Goal:
Build the real post hero section for individual post pages.

The hero section should include:
- Featured image
- Post title
- Breadcrumbs
- Author
- Publish date
- Reading time
- Glossary tags

The hero should be production-ready visually and structurally, but it should not trigger unrelated work outside the hero.

Please inspect:
- Existing post layout structure
- Existing `posts` collection schema and frontmatter fields
- Existing author data structure, if any
- Existing glossary/tag/reference system
- Existing image/asset conventions
- Existing breadcrumb patterns, if any
- Existing date formatting utilities, if any
- Existing reading-time logic, if any
- Existing components and design conventions
- Existing global CSS, Tailwind config, tokens, and typography styles

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. How the hero should pull data from the post/frontmatter/content collection
7. How breadcrumbs should be generated
8. How reading time should be handled
9. How glossary tags should be displayed and linked, if the project already supports that
10. Fallback behavior for missing featured image, author, date, tags, or reading time
11. Constraints and what not to build yet
12. Dependency guidance
13. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable hero component if that matches the project architecture
- Use semantic HTML
- Match existing design system and Tailwind conventions
- Keep the component easy to reuse across post pages
- Keep data handling clean and predictable
- Avoid hardcoded article-specific content except for temporary test/sample content if needed
- Preserve the existing layout and MDX styling work
- Use existing utilities before creating new ones
- Add small utilities only if they clearly reduce duplication or improve maintainability

Do not build:
- Sidebar functionality
- Table of contents logic
- Inline CTA
- End CTA
- Related posts
- Author box
- Video component
- Newsletter form
- Glossary context block
- Full post layout redesign
- New design system pass
- Unrelated refactors

Dependency rule:
Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for featured images, reading time, breadcrumbs, or metadata handling, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a production-ready post hero section for individual post pages.

Important context: The foundational post layout skeleton and MDX content styling either already exist or are being built separately. This step is only about the post hero section.

Goal: Build the real post hero section for individual post pages.

The hero section should include:

Featured image
Post title
Breadcrumbs
Author
Publish date
Reading time
Glossary tags

The hero should be production-ready visually and structurally, but it should not trigger unrelated work outside the hero.

Please inspect:

Existing post layout structure
Existing posts collection schema and frontmatter fields
Existing author data structure, if any
Existing glossary/tag/reference system
Existing image/asset conventions
Existing breadcrumb patterns, if any
Existing date formatting utilities, if any
Existing reading-time logic, if any
Existing components and design conventions
Existing global CSS, Tailwind config, tokens, and typography styles

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
How the hero should pull data from the post/frontmatter/content collection
How breadcrumbs should be generated
How reading time should be handled
How glossary tags should be displayed and linked, if the project already supports that
Fallback behavior for missing featured image, author, date, tags, or reading time
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable hero component if that matches the project architecture
Use semantic HTML
Match existing design system and Tailwind conventions
Keep the component easy to reuse across post pages
Keep data handling clean and predictable
Avoid hardcoded article-specific content except for temporary test/sample content if needed
Preserve the existing layout and MDX styling work
Use existing utilities before creating new ones
Add small utilities only if they clearly reduce duplication or improve maintainability

Do not build:

Sidebar functionality
Table of contents logic
Inline CTA
End CTA
Related posts
Author box
Video component
Newsletter form
Glossary context block
Full post layout redesign
New design system pass
Unrelated refactors

Dependency rule: Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for featured images, reading time, breadcrumbs, or metadata handling, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

Video Component

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable embedded YouTube video component for MDX content.

Goal:
Create a reusable video component that can be used inside MDX posts.

The component should support:
- YouTube video embed
- Simple MDX usage
- Responsive aspect ratio
- Optional title/caption if appropriate
- Accessible iframe title
- Clean styling that matches the existing article/content design
- Reuse across multiple posts

Please inspect:
- Existing Astro component structure
- Existing MDX setup
- Existing `posts` collection setup
- Existing post layout and MDX content styling
- Existing Tailwind/design conventions
- Any existing media/embed components

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. The recommended component API/props
7. Example MDX usage
8. How to handle YouTube IDs vs full URLs
9. Accessibility requirements
10. Responsive styling requirements
11. Constraints and what not to build yet
12. Dependency guidance
13. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable component if that matches the project architecture
- Keep usage simple inside MDX
- Prefer accepting a YouTube video ID, but allow full URL support only if it can be done cleanly without overbuilding
- Use semantic, accessible markup
- Make the embed responsive without relying on unnecessary dependencies
- Match existing Tailwind/design-system conventions
- Avoid hardcoded video-specific content
- Add the component to the sample MDX post only if that helps verify it works in real content context

Do not build:
- A full video library system
- Video CMS fields
- Playlist support
- Custom video player controls
- Analytics tracking
- Lazy-loading framework unless the existing project already has a pattern for it
- Related videos
- CTA logic
- Sidebar changes
- Hero changes
- Unrelated MDX styling changes
- New design system pass
- Unrelated refactors

Dependency rule:
Prefer the existing project stack and browser-native iframe support. Do not add new dependencies casually. If a dependency is genuinely needed for YouTube embeds or MDX component usage, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable embedded YouTube video component for MDX content.

Goal: Create a reusable video component that can be used inside MDX posts.

The component should support:

YouTube video embed
Simple MDX usage
Responsive aspect ratio
Optional title/caption if appropriate
Accessible iframe title
Clean styling that matches the existing article/content design
Reuse across multiple posts

Please inspect:

Existing Astro component structure
Existing MDX setup
Existing posts collection setup
Existing post layout and MDX content styling
Existing Tailwind/design conventions
Any existing media/embed components

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
The recommended component API/props
Example MDX usage
How to handle YouTube IDs vs full URLs
Accessibility requirements
Responsive styling requirements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable component if that matches the project architecture
Keep usage simple inside MDX
Prefer accepting a YouTube video ID, but allow full URL support only if it can be done cleanly without overbuilding
Use semantic, accessible markup
Make the embed responsive without relying on unnecessary dependencies
Match existing Tailwind/design-system conventions
Avoid hardcoded video-specific content
Add the component to the sample MDX post only if that helps verify it works in real content context

Do not build:

A full video library system
Video CMS fields
Playlist support
Custom video player controls
Analytics tracking
Lazy-loading framework unless the existing project already has a pattern for it
Related videos
CTA logic
Sidebar changes
Hero changes
Unrelated MDX styling changes
New design system pass
Unrelated refactors

Dependency rule: Prefer the existing project stack and browser-native iframe support. Do not add new dependencies casually. If a dependency is genuinely needed for YouTube embeds or MDX component usage, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

Inline CTA Component

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable inline CTA component for MDX/post content.

Goal:
Create a reusable inline CTA component that can be placed naturally inside article content.

The component should support:
- Flexible headline/copy
- Flexible button text
- Flexible button URL
- Optional small label/eyebrow if useful
- No image
- Clean layout inside the content column
- Reuse across multiple posts

Please inspect:
- Existing Astro component structure
- Existing MDX setup
- Existing `posts` collection setup
- Existing post layout and MDX content styling
- Existing button/link components, if any
- Existing Tailwind/design conventions
- Existing CTA or card patterns, if any

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. The recommended component API/props
7. Example MDX usage
8. Accessibility requirements
9. Responsive styling requirements
10. Constraints and what not to build yet
11. Dependency guidance
12. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable component if that matches the project architecture
- Keep usage simple inside MDX
- Use existing button/link styles if available
- Keep the CTA content flexible through props or slots
- Make it visually distinct from normal article content without feeling like a full end-of-post sales block
- Make it work naturally between paragraphs or sections
- Use semantic, accessible markup
- Avoid hardcoded campaign-specific copy
- Add the component to the sample MDX post only if that helps verify it in real article context

Do not build:
- End-of-post CTA
- Image-based CTA
- Newsletter form
- Lead magnet delivery logic
- Form handling
- Tracking/analytics
- Related posts
- Sidebar changes
- Hero changes
- New design system pass
- Unrelated MDX styling changes
- Unrelated refactors

Dependency rule:
Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for this inline CTA component, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable inline CTA component for MDX/post content.

Goal: Create a reusable inline CTA component that can be placed naturally inside article content.

The component should support:

Flexible headline/copy
Flexible button text
Flexible button URL
Optional small label/eyebrow if useful
No image
Clean layout inside the content column
Reuse across multiple posts

Please inspect:

Existing Astro component structure
Existing MDX setup
Existing posts collection setup
Existing post layout and MDX content styling
Existing button/link components, if any
Existing Tailwind/design conventions
Existing CTA or card patterns, if any

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
The recommended component API/props
Example MDX usage
Accessibility requirements
Responsive styling requirements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable component if that matches the project architecture
Keep usage simple inside MDX
Use existing button/link styles if available
Keep the CTA content flexible through props or slots
Make it visually distinct from normal article content without feeling like a full end-of-post sales block
Make it work naturally between paragraphs or sections
Use semantic, accessible markup
Avoid hardcoded campaign-specific copy
Add the component to the sample MDX post only if that helps verify it in real article context

Do not build:

End-of-post CTA
Image-based CTA
Newsletter form
Lead magnet delivery logic
Form handling
Tracking/analytics
Related posts
Sidebar changes
Hero changes
New design system pass
Unrelated MDX styling changes
Unrelated refactors

Dependency rule: Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for this inline CTA component, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

What To Do Next Component

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable “What To Do Next” component for individual post pages.

Goal:
Create a contextual next-step component that can appear inside or near the end of a post and guide the reader toward the best next action.

This component should include:
- Recommended post
- Recommended video
- Work-with-me option

Important context:
This is not a generic related-posts grid. This is a curated next-step component.

The recommended post, recommended video, and work-with-me CTA should be variable based on what the current post is about.

Please inspect:
- Existing post layout structure
- Existing `posts` collection schema and frontmatter fields
- Existing glossary/tag/reference system
- Existing video component from the previous step
- Existing CTA/button components
- Existing content collection relationships
- Existing design conventions and Tailwind patterns
- Existing utilities for filtering/querying posts, if any

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. The recommended component API/props
7. How the recommended post should be selected or passed in
8. How the recommended video should be selected or passed in
9. How the work-with-me CTA should be selected or passed in
10. Whether this should be manual/frontmatter-driven, automatic, or hybrid based on the existing project
11. Example usage in a post/layout/MDX file
12. Fallback behavior if one of the three options is missing
13. Accessibility requirements
14. Responsive styling requirements
15. Constraints and what not to build yet
16. Dependency guidance
17. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable component if that matches the project architecture
- Make the component flexible enough to support different recommendations per post
- Prefer a simple manual or frontmatter-driven system unless the project already has a clean relationship system for automatic recommendations
- Avoid overbuilding a recommendation engine
- Allow the current post topic, category, glossary references, or frontmatter fields to influence the recommendations if the existing content system supports it
- Make each option visually clear and distinct:
- Recommended post = continue learning
- Recommended video = watch the related explanation
- Work with me = conversion/action step
- Keep the CTA copy flexible
- Use existing button/link/card styles if available
- Match the existing article and design-system conventions
- Keep the component easy to place in multiple posts
- Add it to the sample MDX post or post layout only if that helps verify it in context

Recommended data approach:
Prefer a hybrid system if it fits the project:
- Let posts manually define recommended next steps in frontmatter when precision matters
- Allow fallback recommendations based on shared glossary tags, category, or content silo if manual recommendations are missing
- Keep the first version simple and maintainable

Do not build:
- Full recommendation engine
- Analytics/tracking
- Newsletter form
- Contact form
- Booking system
- Related posts grid
- Sidebar changes
- Hero changes
- Author box
- End-of-post CTA replacement
- New design system pass
- Unrelated MDX styling changes
- Unrelated refactors

Dependency rule:
Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for querying posts, videos, or recommendations, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable “What To Do Next” component for individual post pages.

Goal: Create a contextual next-step component that can appear inside or near the end of a post and guide the reader toward the best next action.

This component should include:

Recommended post
Recommended video
Work-with-me option

Important context: This is not a generic related-posts grid. This is a curated next-step component.

The recommended post, recommended video, and work-with-me CTA should be variable based on what the current post is about.

Please inspect:

Existing post layout structure
Existing posts collection schema and frontmatter fields
Existing glossary/tag/reference system
Existing video component from the previous step
Existing CTA/button components
Existing content collection relationships
Existing design conventions and Tailwind patterns
Existing utilities for filtering/querying posts, if any

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
The recommended component API/props
How the recommended post should be selected or passed in
How the recommended video should be selected or passed in
How the work-with-me CTA should be selected or passed in
Whether this should be manual/frontmatter-driven, automatic, or hybrid based on the existing project
Example usage in a post/layout/MDX file
Fallback behavior if one of the three options is missing
Accessibility requirements
Responsive styling requirements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable component if that matches the project architecture
Make the component flexible enough to support different recommendations per post
Prefer a simple manual or frontmatter-driven system unless the project already has a clean relationship system for automatic recommendations
Avoid overbuilding a recommendation engine
Allow the current post topic, category, glossary references, or frontmatter fields to influence the recommendations if the existing content system supports it
Make each option visually clear and distinct:
Recommended post = continue learning
Recommended video = watch the related explanation
Work with me = conversion/action step
Keep the CTA copy flexible
Use existing button/link/card styles if available
Match the existing article and design-system conventions
Keep the component easy to place in multiple posts
Add it to the sample MDX post or post layout only if that helps verify it in context

Recommended data approach: Prefer a hybrid system if it fits the project:

Let posts manually define recommended next steps in frontmatter when precision matters
Allow fallback recommendations based on shared glossary tags, category, or content silo if manual recommendations are missing
Keep the first version simple and maintainable

Do not build:

Full recommendation engine
Analytics/tracking
Newsletter form
Contact form
Booking system
Related posts grid
Sidebar changes
Hero changes
Author box
End-of-post CTA replacement
New design system pass
Unrelated MDX styling changes
Unrelated refactors

Dependency rule: Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for querying posts, videos, or recommendations, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

Author Box

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable author box component for individual post pages.

Goal:
Create a reusable author box component that displays author information for the current post.

Important context:
This project has an `authors` content collection. Individual posts should reference an author, and the author box should use that post-author relationship to pull the correct author data from the `authors` collection.

The author box should include:
- Author name
- Author bio/description
- Author image/avatar if available
- Optional link to about/contact page
- Any existing author metadata already supported by the project

Please inspect:
- Existing `authors` content collection
- Existing `posts` collection schema
- How posts currently reference authors
- Existing author frontmatter fields
- Existing image/avatar conventions
- Existing post layout structure
- Existing Astro content collection references
- Existing components and Tailwind/design conventions
- Existing author usage in the hero section, if already implemented

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. The recommended author data flow
7. How the current post’s author should connect to the `authors` collection
8. The recommended component API/props
9. Whether author lookup should happen in the post layout, page route, or inside the component
10. Fallback behavior for missing author, missing avatar, missing bio, or missing link
11. Example usage in the post layout or post page
12. Accessibility requirements
13. Responsive styling requirements
14. Constraints and what not to build yet
15. Dependency guidance
16. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable author box component
- Prefer pulling structured author data from the `authors` collection instead of duplicating author details in every post
- Keep the post frontmatter lightweight, ideally referencing the author by slug/id if the project supports that
- Preserve compatibility with the existing hero author display
- If needed, update the schema carefully so posts can reference authors cleanly
- If additional author frontmatter fields are useful for the author box, recommend them clearly before adding them
- Keep the component flexible enough to support future fields without overbuilding
- Use semantic, accessible markup
- Match existing article and design-system conventions
- Use existing image handling conventions
- Avoid hardcoded author-specific content in the component

Recommended data approach:
Prefer this structure if it fits the existing project:
- Each post references one author by slug/id
- The page route or layout resolves that author from the `authors` collection
- The resolved author object is passed into the `AuthorBox` component
- The component only renders the author data it receives

Do not build:
- Full author archive pages
- Author listing pages
- Multi-author system unless the project already supports it
- Social profile system unless author fields already exist
- Contact form
- Newsletter form
- Sidebar changes
- Related posts
- End CTA
- New design system pass
- Unrelated post schema refactors
- Unrelated MDX styling changes

Dependency rule:
Prefer Astro content collections and the existing project stack. Do not add new dependencies casually. If a dependency is genuinely needed for author lookup, image handling, or collection references, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable author box component for individual post pages.

Goal: Create a reusable author box component that displays author information for the current post.

Important context: This project has an authors content collection. Individual posts should reference an author, and the author box should use that post-author relationship to pull the correct author data from the authors collection.

The author box should include:

Author name
Author bio/description
Author image/avatar if available
Optional link to about/contact page
Any existing author metadata already supported by the project

Please inspect:

Existing authors content collection
Existing posts collection schema
How posts currently reference authors
Existing author frontmatter fields
Existing image/avatar conventions
Existing post layout structure
Existing Astro content collection references
Existing components and Tailwind/design conventions
Existing author usage in the hero section, if already implemented

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
The recommended author data flow
How the current post’s author should connect to the authors collection
The recommended component API/props
Whether author lookup should happen in the post layout, page route, or inside the component
Fallback behavior for missing author, missing avatar, missing bio, or missing link
Example usage in the post layout or post page
Accessibility requirements
Responsive styling requirements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable author box component
Prefer pulling structured author data from the authors collection instead of duplicating author details in every post
Keep the post frontmatter lightweight, ideally referencing the author by slug/id if the project supports that
Preserve compatibility with the existing hero author display
If needed, update the schema carefully so posts can reference authors cleanly
If additional author frontmatter fields are useful for the author box, recommend them clearly before adding them
Keep the component flexible enough to support future fields without overbuilding
Use semantic, accessible markup
Match existing article and design-system conventions
Use existing image handling conventions
Avoid hardcoded author-specific content in the component

Recommended data approach: Prefer this structure if it fits the existing project:

Each post references one author by slug/id
The page route or layout resolves that author from the authors collection
The resolved author object is passed into the AuthorBox component
The component only renders the author data it receives

Do not build:

Full author archive pages
Author listing pages
Multi-author system unless the project already supports it
Social profile system unless author fields already exist
Contact form
Newsletter form
Sidebar changes
Related posts
End CTA
New design system pass
Unrelated post schema refactors
Unrelated MDX styling changes

Dependency rule: Prefer Astro content collections and the existing project stack. Do not add new dependencies casually. If a dependency is genuinely needed for author lookup, image handling, or collection references, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable related posts component for individual post pages.

Goal:
Create a related posts system that recommends posts based on shared glossary references.

Important context:
This project has a `glossary` content collection. Glossary entries work like topic references/tags for posts. For example, a post about SEO might reference the `seo` glossary entry, and a post about tracking might reference the `utm-parameters` glossary entry.

The related posts component should:
- Look at the current post’s glossary references
- Query other posts that share one or more of those same glossary references
- Exclude the current post
- Limit the number of results
- Output a reusable related posts section

Please inspect:
- Existing `posts` collection schema
- Existing `glossary` collection schema
- How posts currently reference glossary entries
- Existing content collection relationship patterns
- Existing post card/list components, if any
- Existing route/slug structure for posts
- Existing post layout structure
- Existing Tailwind/design conventions
- Existing utilities for filtering/sorting posts, if any

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. The recommended data flow
7. How to read the current post’s glossary references
8. How to query posts with shared glossary references
9. How to exclude the current post
10. How to limit the results
11. How to sort/rank related posts if multiple posts match
12. The recommended component API/props
13. Example usage in the post layout or post page
14. Fallback behavior if there are no glossary references or no related posts
15. Accessibility requirements
16. Responsive styling requirements
17. Constraints and what not to build yet
18. Dependency guidance
19. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable related posts component
- Prefer using Astro content collections and existing project conventions
- Treat glossary references as topic relationships, not as a separate generic tag system
- Keep the first version simple and maintainable
- Avoid creating duplicate tag archives or a parallel tagging system
- Rank posts with more shared glossary references higher if practical
- Exclude drafts or unpublished posts if the project has that convention
- Use existing post card styles if available
- Match the existing article and design-system conventions
- Keep the component easy to reuse later
- Avoid hardcoded related post data in the component

Recommended data approach:
Prefer this structure if it fits the existing project:
- The current post includes a frontmatter field referencing glossary entries
- The page route or post layout gets all published posts from the `posts` collection
- A small utility filters posts by shared glossary references
- The current post is excluded by slug/id
- Matching posts are sorted by number of shared glossary references
- The limited result set is passed into a reusable `RelatedPosts` component
- The component only renders the posts it receives

Do not build:
- Generic tag archive system
- Glossary archive redesign
- Full recommendation engine
- Search system
- Pagination
- Sidebar changes
- Author box changes
- End CTA
- Newsletter form
- New design system pass
- Unrelated schema refactors
- Unrelated MDX styling changes

Dependency rule:
Prefer Astro content collections and existing utilities. Do not add new dependencies casually. If a dependency is genuinely needed for content querying or ranking, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable related posts component for individual post pages.

Goal: Create a related posts system that recommends posts based on shared glossary references.

Important context: This project has a glossary content collection. Glossary entries work like topic references/tags for posts. For example, a post about SEO might reference the seo glossary entry, and a post about tracking might reference the utm-parameters glossary entry.

The related posts component should:

Look at the current post’s glossary references
Query other posts that share one or more of those same glossary references
Exclude the current post
Limit the number of results
Output a reusable related posts section

Please inspect:

Existing posts collection schema
Existing glossary collection schema
How posts currently reference glossary entries
Existing content collection relationship patterns
Existing post card/list components, if any
Existing route/slug structure for posts
Existing post layout structure
Existing Tailwind/design conventions
Existing utilities for filtering/sorting posts, if any

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
The recommended data flow
How to read the current post’s glossary references
How to query posts with shared glossary references
How to exclude the current post
How to limit the results
How to sort/rank related posts if multiple posts match
The recommended component API/props
Example usage in the post layout or post page
Fallback behavior if there are no glossary references or no related posts
Accessibility requirements
Responsive styling requirements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable related posts component
Prefer using Astro content collections and existing project conventions
Treat glossary references as topic relationships, not as a separate generic tag system
Keep the first version simple and maintainable
Avoid creating duplicate tag archives or a parallel tagging system
Rank posts with more shared glossary references higher if practical
Exclude drafts or unpublished posts if the project has that convention
Use existing post card styles if available
Match the existing article and design-system conventions
Keep the component easy to reuse later
Avoid hardcoded related post data in the component

Recommended data approach: Prefer this structure if it fits the existing project:

The current post includes a frontmatter field referencing glossary entries
The page route or post layout gets all published posts from the posts collection
A small utility filters posts by shared glossary references
The current post is excluded by slug/id
Matching posts are sorted by number of shared glossary references
The limited result set is passed into a reusable RelatedPosts component
The component only renders the posts it receives

Do not build:

Generic tag archive system
Glossary archive redesign
Full recommendation engine
Search system
Pagination
Sidebar changes
Author box changes
End CTA
Newsletter form
New design system pass
Unrelated schema refactors
Unrelated MDX styling changes

Dependency rule: Prefer Astro content collections and existing utilities. Do not add new dependencies casually. If a dependency is genuinely needed for content querying or ranking, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

End CTA

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable end-of-post CTA component.

Goal:
Create a primary conversion component that appears near the end of individual post pages.

Important context:
This is the final service-focused CTA block, not the smaller inline CTA and not the “What To Do Next” component.

The end CTA should:
- Promote the main service/offer
- Be reusable across posts
- Support flexible headline/copy/button text/button URL
- Optionally support different CTA variations based on the post topic
- Work as the primary conversion block near the bottom of an article

Please inspect:
- Existing post layout structure
- Existing MDX/post components
- Existing inline CTA component
- Existing “What To Do Next” component, if already implemented
- Existing button/link/card styles
- Existing service/offer copy patterns
- Existing Tailwind/design conventions
- Existing content collection/frontmatter structure

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. The recommended component API/props
7. Whether CTA content should be passed manually, controlled by frontmatter, or use defaults
8. How to support topic-specific CTA variations without overbuilding
9. Example usage in the post layout, post page, or MDX
10. Fallback behavior if no custom CTA is provided
11. Accessibility requirements
12. Responsive styling requirements
13. Constraints and what not to build yet
14. Dependency guidance
15. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable component
- Make it visually stronger than the inline CTA
- Make it clearly service-focused and conversion-focused
- Keep the copy flexible, not hardcoded into the component unless using sensible defaults
- Prefer existing button/link/card styles if available
- Match the existing article and design-system conventions
- Keep it easy to use across all posts
- Allow future variation by post topic, category, content silo, or frontmatter if the project structure supports it
- Avoid duplicating the purpose of the inline CTA or “What To Do Next” component

Recommended data approach:
Prefer a simple hybrid system if it fits the project:
- Component has sensible default CTA content
- Individual posts can override CTA headline, copy, button text, and URL through frontmatter or props
- Optional CTA variant can be selected by content silo/topic if the project already has that structure
- Avoid building a full CTA management system in this step

Do not build:
- Contact form
- Booking system
- Newsletter form
- Lead magnet delivery system
- Analytics/tracking
- Full CTA management engine
- Sidebar changes
- Hero changes
- Related posts changes
- Author box changes
- New design system pass
- Unrelated MDX styling changes
- Unrelated refactors

Dependency rule:
Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for this CTA component, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a reusable end-of-post CTA component.

Goal: Create a primary conversion component that appears near the end of individual post pages.

Important context: This is the final service-focused CTA block, not the smaller inline CTA and not the “What To Do Next” component.

The end CTA should:

Promote the main service/offer
Be reusable across posts
Support flexible headline/copy/button text/button URL
Optionally support different CTA variations based on the post topic
Work as the primary conversion block near the bottom of an article

Please inspect:

Existing post layout structure
Existing MDX/post components
Existing inline CTA component
Existing “What To Do Next” component, if already implemented
Existing button/link/card styles
Existing service/offer copy patterns
Existing Tailwind/design conventions
Existing content collection/frontmatter structure

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
The recommended component API/props
Whether CTA content should be passed manually, controlled by frontmatter, or use defaults
How to support topic-specific CTA variations without overbuilding
Example usage in the post layout, post page, or MDX
Fallback behavior if no custom CTA is provided
Accessibility requirements
Responsive styling requirements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable component
Make it visually stronger than the inline CTA
Make it clearly service-focused and conversion-focused
Keep the copy flexible, not hardcoded into the component unless using sensible defaults
Prefer existing button/link/card styles if available
Match the existing article and design-system conventions
Keep it easy to use across all posts
Allow future variation by post topic, category, content silo, or frontmatter if the project structure supports it
Avoid duplicating the purpose of the inline CTA or “What To Do Next” component

Recommended data approach: Prefer a simple hybrid system if it fits the project:

Component has sensible default CTA content
Individual posts can override CTA headline, copy, button text, and URL through frontmatter or props
Optional CTA variant can be selected by content silo/topic if the project already has that structure
Avoid building a full CTA management system in this step

Do not build:

Contact form
Booking system
Newsletter form
Lead magnet delivery system
Analytics/tracking
Full CTA management engine
Sidebar changes
Hero changes
Related posts changes
Author box changes
New design system pass
Unrelated MDX styling changes
Unrelated refactors

Dependency rule: Prefer the existing project stack and conventions. Do not add new dependencies casually. If a dependency is genuinely needed for this CTA component, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a standalone sidebar system for individual post pages.

Goal:
Create a complete reusable post sidebar component that is independent from the main article content and can be used across post pages.

The sidebar should include:
- Table of contents
- Glossary context block
- Newsletter CTA

Important context:
This sidebar should be built as a standalone system, not mixed into the MDX content styling or individual post body components.

The sidebar should understand the current post context where needed:
- The table of contents should be based on the current post headings
- The glossary context block should be based on the current post’s glossary references
- The newsletter CTA should be reusable and optionally customizable

Please inspect:
- Existing post layout structure
- Existing sidebar placeholder from the foundational layout
- Existing MDX rendering setup
- Existing heading/slug generation behavior
- Existing `posts` collection schema
- Existing `glossary` collection schema
- How posts reference glossary entries
- Existing newsletter/CTA components or patterns
- Existing Tailwind/design conventions
- Existing responsive layout conventions

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files to create or edit
3. The role of each file/component
4. The implementation order
5. Project-specific findings from this repo
6. The recommended sidebar component structure
7. How the table of contents should be generated and rendered
8. How the glossary context block should pull glossary data for the current post
9. How the newsletter CTA should be handled
10. The recommended component API/props
11. Example usage in the post layout or post page
12. Fallback behavior if headings, glossary references, or newsletter copy are missing
13. Accessibility requirements
14. Desktop behavior
15. Mobile behavior should be considered, but do not do the full mobile optimization pass yet
16. Responsive styling requirements
17. Constraints and what not to build yet
18. Dependency guidance
19. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Create a real reusable sidebar component
- Keep the sidebar independent from the article body
- Use smaller internal components if helpful, such as:
- `PostSidebar`
- `TableOfContents`
- `GlossaryContext`
- `NewsletterSidebarCTA`
- Prefer passing prepared data into the sidebar instead of making the sidebar perform heavy querying internally
- Use existing content collection utilities and conventions
- Keep table-of-contents logic simple and maintainable
- Use existing heading metadata if Astro/MDX already provides it
- Do not duplicate glossary or tag systems
- Use glossary references as the source of truth for the glossary context block
- Keep newsletter CTA copy flexible, with sensible defaults if appropriate
- Match existing design-system and Tailwind conventions
- Preserve the existing main post layout and content styling

Recommended data approach:
Prefer this structure if it fits the project:
- The post route/layout gets the current post data
- The route/layout gets headings or table-of-contents data from rendered MDX if available
- The route/layout resolves the current post’s glossary references from the `glossary` collection
- The route/layout passes prepared data into `PostSidebar`
- `PostSidebar` renders the table of contents, glossary context block, and newsletter CTA
- The sidebar components focus on rendering, not complex data fetching

Do not build:
- Full mobile accordion behavior yet
- Sticky behavior unless the existing layout already supports it cleanly
- Advanced scrollspy/highlight logic unless already available
- Newsletter backend integration
- Form submission handling
- Email marketing integration
- New glossary archive system
- Related posts
- End CTA
- Author box
- Hero changes
- MDX typography changes
- New design system pass
- Unrelated refactors

Dependency rule:
Prefer Astro/MDX’s existing heading metadata and the current project stack. Do not add new dependencies casually. If a dependency is genuinely needed for table-of-contents generation, heading anchors, or newsletter functionality, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to implement a standalone sidebar system for individual post pages.

Goal: Create a complete reusable post sidebar component that is independent from the main article content and can be used across post pages.

The sidebar should include:

Table of contents
Glossary context block
Newsletter CTA

Important context: This sidebar should be built as a standalone system, not mixed into the MDX content styling or individual post body components.

The sidebar should understand the current post context where needed:

The table of contents should be based on the current post headings
The glossary context block should be based on the current post’s glossary references
The newsletter CTA should be reusable and optionally customizable

Please inspect:

Existing post layout structure
Existing sidebar placeholder from the foundational layout
Existing MDX rendering setup
Existing heading/slug generation behavior
Existing posts collection schema
Existing glossary collection schema
How posts reference glossary entries
Existing newsletter/CTA components or patterns
Existing Tailwind/design conventions
Existing responsive layout conventions

Then produce a self-contained implementation prompt that includes:

The exact goal
The files to create or edit
The role of each file/component
The implementation order
Project-specific findings from this repo
The recommended sidebar component structure
How the table of contents should be generated and rendered
How the glossary context block should pull glossary data for the current post
How the newsletter CTA should be handled
The recommended component API/props
Example usage in the post layout or post page
Fallback behavior if headings, glossary references, or newsletter copy are missing
Accessibility requirements
Desktop behavior
Mobile behavior should be considered, but do not do the full mobile optimization pass yet
Responsive styling requirements
Constraints and what not to build yet
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Create a real reusable sidebar component
Keep the sidebar independent from the article body
Use smaller internal components if helpful, such as:
PostSidebar
TableOfContents
GlossaryContext
NewsletterSidebarCTA
Prefer passing prepared data into the sidebar instead of making the sidebar perform heavy querying internally
Use existing content collection utilities and conventions
Keep table-of-contents logic simple and maintainable
Use existing heading metadata if Astro/MDX already provides it
Do not duplicate glossary or tag systems
Use glossary references as the source of truth for the glossary context block
Keep newsletter CTA copy flexible, with sensible defaults if appropriate
Match existing design-system and Tailwind conventions
Preserve the existing main post layout and content styling

Recommended data approach: Prefer this structure if it fits the project:

The post route/layout gets the current post data
The route/layout gets headings or table-of-contents data from rendered MDX if available
The route/layout resolves the current post’s glossary references from the glossary collection
The route/layout passes prepared data into PostSidebar
PostSidebar renders the table of contents, glossary context block, and newsletter CTA
The sidebar components focus on rendering, not complex data fetching

Do not build:

Full mobile accordion behavior yet
Sticky behavior unless the existing layout already supports it cleanly
Advanced scrollspy/highlight logic unless already available
Newsletter backend integration
Form submission handling
Email marketing integration
New glossary archive system
Related posts
End CTA
Author box
Hero changes
MDX typography changes
New design system pass
Unrelated refactors

Dependency rule: Prefer Astro/MDX’s existing heading metadata and the current project stack. Do not add new dependencies casually. If a dependency is genuinely needed for table-of-contents generation, heading anchors, or newsletter functionality, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

Mobile Pass

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to complete a mobile optimization pass for the individual post layout and all post-related components.

Goal:
Handle all mobile behavior for the post experience at once so the article page feels clean, readable, and intentionally designed on small screens.

Important context:
The desktop post system should already include:
- Post layout skeleton
- MDX content styling
- Hero section
- Video component
- Inline CTA
- What To Do Next component
- Author box
- Related posts
- End CTA
- Sidebar system with TOC, glossary context block, and newsletter CTA

This step is not about rebuilding those components. It is about making the full post experience work well on mobile.

Mobile pass should adjust:
- Layout stacking
- Sidebar behavior
- Table of contents behavior
- Glossary context placement
- Newsletter CTA placement
- Component spacing
- CTA placement
- Article readability
- Image/video responsiveness
- Touch-friendly buttons and links
- Visual hierarchy on small screens

Specific sidebar/mobile behavior:
- The desktop sidebar should not simply appear as a cramped sidebar on mobile
- The table of contents should become mobile-friendly, likely as an accordion/disclosure near the top of the article or another sensible position
- Glossary context and newsletter CTA should be repositioned where they make sense in the mobile reading flow
- Avoid duplicating sidebar content in confusing ways
- Keep the mobile flow intentional, not just stacked by default

Please inspect:
- Existing post layout
- Existing sidebar system
- Existing table of contents component
- Existing glossary context block
- Existing newsletter CTA
- Existing post hero
- Existing MDX content styling
- Existing CTA components
- Existing author box
- Existing related posts
- Existing video component
- Existing Tailwind breakpoints and responsive conventions
- Existing design tokens and spacing scale

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files/components likely to edit
3. The role of each mobile adjustment
4. The implementation order
5. Project-specific findings from this repo
6. Recommended mobile layout flow from top to bottom
7. How the sidebar should transform on mobile
8. How the TOC accordion/disclosure should work
9. Where glossary context should appear on mobile
10. Where newsletter CTA should appear on mobile
11. How CTAs should be spaced and ordered on mobile
12. How article readability should be improved
13. Accessibility requirements for mobile interactions
14. Responsive styling requirements
15. What to test visually
16. Constraints and what not to rebuild
17. Dependency guidance
18. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Preserve the existing desktop layout unless a small fix is clearly necessary
- Use existing Tailwind breakpoints and project conventions
- Prefer CSS/responsive classes over JavaScript
- If an accordion/disclosure is needed, prefer native HTML details/summary or an existing project pattern before adding JS
- Keep mobile behavior simple, accessible, and maintainable
- Make buttons and links touch-friendly
- Ensure video embeds and images scale correctly
- Ensure tables do not break the mobile layout
- Ensure long headings, code blocks, and links wrap or scroll properly
- Avoid over-compressing vertical spacing
- Avoid creating one-off styles that will be hard to codify later

Recommended mobile article flow:
Use this as a starting point, but adjust based on the actual project structure:
1. Hero
2. Optional mobile table of contents accordion
3. Main article content
4. Inline CTAs where they naturally appear in content
5. What To Do Next component
6. Author box
7. Related posts
8. End CTA
9. Newsletter CTA or glossary context only if they are not already shown in a better mobile position

Do not build:
- New desktop redesign
- New content components
- New CTA system
- New newsletter backend
- New glossary system
- New related posts logic
- New author system
- New hero system
- New design system pass
- Advanced scrollspy
- Complex JavaScript interactions
- Unrelated refactors

Dependency rule:
Prefer existing CSS, Tailwind, Astro, and native HTML behavior. Do not add new dependencies casually. If a dependency is genuinely needed for mobile accordion behavior or responsive interactions, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to complete a mobile optimization pass for the individual post layout and all post-related components.

Goal: Handle all mobile behavior for the post experience at once so the article page feels clean, readable, and intentionally designed on small screens.

Important context: The desktop post system should already include:

Post layout skeleton
MDX content styling
Hero section
Video component
Inline CTA
What To Do Next component
Author box
Related posts
End CTA
Sidebar system with TOC, glossary context block, and newsletter CTA

This step is not about rebuilding those components. It is about making the full post experience work well on mobile.

Mobile pass should adjust:

Layout stacking
Sidebar behavior
Table of contents behavior
Glossary context placement
Newsletter CTA placement
Component spacing
CTA placement
Article readability
Image/video responsiveness
Touch-friendly buttons and links
Visual hierarchy on small screens

Specific sidebar/mobile behavior:

The desktop sidebar should not simply appear as a cramped sidebar on mobile
The table of contents should become mobile-friendly, likely as an accordion/disclosure near the top of the article or another sensible position
Glossary context and newsletter CTA should be repositioned where they make sense in the mobile reading flow
Avoid duplicating sidebar content in confusing ways
Keep the mobile flow intentional, not just stacked by default

Please inspect:

Existing post layout
Existing sidebar system
Existing table of contents component
Existing glossary context block
Existing newsletter CTA
Existing post hero
Existing MDX content styling
Existing CTA components
Existing author box
Existing related posts
Existing video component
Existing Tailwind breakpoints and responsive conventions
Existing design tokens and spacing scale

Then produce a self-contained implementation prompt that includes:

The exact goal
The files/components likely to edit
The role of each mobile adjustment
The implementation order
Project-specific findings from this repo
Recommended mobile layout flow from top to bottom
How the sidebar should transform on mobile
How the TOC accordion/disclosure should work
Where glossary context should appear on mobile
Where newsletter CTA should appear on mobile
How CTAs should be spaced and ordered on mobile
How article readability should be improved
Accessibility requirements for mobile interactions
Responsive styling requirements
What to test visually
Constraints and what not to rebuild
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Preserve the existing desktop layout unless a small fix is clearly necessary
Use existing Tailwind breakpoints and project conventions
Prefer CSS/responsive classes over JavaScript
If an accordion/disclosure is needed, prefer native HTML details/summary or an existing project pattern before adding JS
Keep mobile behavior simple, accessible, and maintainable
Make buttons and links touch-friendly
Ensure video embeds and images scale correctly
Ensure tables do not break the mobile layout
Ensure long headings, code blocks, and links wrap or scroll properly
Avoid over-compressing vertical spacing
Avoid creating one-off styles that will be hard to codify later

Recommended mobile article flow: Use this as a starting point, but adjust based on the actual project structure:

Hero
Optional mobile table of contents accordion
Main article content
Inline CTAs where they naturally appear in content
What To Do Next component
Author box
Related posts
End CTA
Newsletter CTA or glossary context only if they are not already shown in a better mobile position

Do not build:

New desktop redesign
New content components
New CTA system
New newsletter backend
New glossary system
New related posts logic
New author system
New hero system
New design system pass
Advanced scrollspy
Complex JavaScript interactions
Unrelated refactors

Dependency rule: Prefer existing CSS, Tailwind, Astro, and native HTML behavior. Do not add new dependencies casually. If a dependency is genuinely needed for mobile accordion behavior or responsive interactions, explain why before recommending it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

Astro Image Optimization Plan

I want to refactor this Astro project so all eligible images use Astro’s built-in image optimization through `astro:assets`.

Please inspect the project first and create a plan only. Do not edit files yet.

Goal:
- Identify every image currently used across pages, layouts, reusable components, MDX files, and content collections.
- Determine which images should move into Astro’s optimized asset pipeline.
- Determine which images should remain in `public/` because they require fixed URLs or should not be processed.
- Identify every place currently using raw `<img>` tags, string image paths, `/public` image paths, or unoptimized image references.
- Recommend the safest refactor path for using Astro’s `Image` / `Picture` components where appropriate.
- Pay special attention to MDX images, frontmatter images, reusable components, hero images, card images, thumbnails, logos, icons, and OG/social images.
- Note any dynamic image cases that may need a special approach instead of a simple import.
- Avoid overengineering. Keep the final system simple, Astro-native, and easy for a non-coder to maintain.

In your plan, include:
1. Current image usage patterns you found
2. Which files/folders need changes
3. Which images should be moved and where
4. Which components/pages should be updated
5. Any risks or edge cases
6. A recommended step-by-step implementation order

Important:
Do not make changes yet. Only analyze the project and produce the plan.

I want to refactor this Astro project so all eligible images use Astro’s built-in image optimization through astro:assets.

Please inspect the project first and create a plan only. Do not edit files yet.

Goal:

Identify every image currently used across pages, layouts, reusable components, MDX files, and content collections.
Determine which images should move into Astro’s optimized asset pipeline.
Determine which images should remain in public/ because they require fixed URLs or should not be processed.
Identify every place currently using raw <img> tags, string image paths, /public image paths, or unoptimized image references.
Recommend the safest refactor path for using Astro’s Image / Picture components where appropriate.
Pay special attention to MDX images, frontmatter images, reusable components, hero images, card images, thumbnails, logos, icons, and OG/social images.
Note any dynamic image cases that may need a special approach instead of a simple import.
Avoid overengineering. Keep the final system simple, Astro-native, and easy for a non-coder to maintain.

In your plan, include:

Current image usage patterns you found
Which files/folders need changes
Which images should be moved and where
Which components/pages should be updated
Any risks or edge cases
A recommended step-by-step implementation order

Important: Do not make changes yet. Only analyze the project and produce the plan.

Design System and Layout QA

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to perform the final site-wide design system codification pass, using the approved MDX article content sample as the styling source of truth, plus the final layout QA pass for the complete individual post layout.

Goal:
Codify the approved MDX article content sample styling into the project’s overall website design system, then verify the post layout is production-ready.

Important context:
The post system should already include:
- Post layout skeleton
- MDX content styling
- Hero section
- YouTube video component
- Inline CTA
- What To Do Next component
- Author box
- Related posts
- End CTA
- Sidebar system
- Mobile behavior

There should also be a sample post called the MDX article content sample. Treat that sample’s approved visual styling as the reference for the site-wide content design system, including H1, H2, H3, H4, H5, H6, paragraphs, links, unordered lists, ordered lists, nested lists, blockquotes, inline code, code blocks, images, tables, horizontal rules, and related article-content spacing.

This step is not about adding new features. It is about standardizing, codifying, cleaning up, and QA-checking the full post experience while making the approved article-content styling available through the website’s shared design system, not only through one post/content-collection layout.

The QA/design system pass should:
- Standardize spacing
- Standardize typography usage across the entire website based on the approved MDX article content sample
- Normalize component styles
- Ensure visual consistency across all post components
- Ensure the article-content element styling is codified into shared/global design-system primitives so it can be reused outside the posts collection
- Remove one-off styles and conflicts
- Confirm desktop/tablet/mobile behavior
- Confirm accessibility basics
- Confirm the layout is production-ready

Please inspect:
- Existing global CSS/design tokens
- Tailwind config
- Post layout file
- All post-related components
- MDX/content styling
- Mobile responsive behavior
- The MDX article content sample post and its approved styling for headings, lists, links, code, quotes, tables, images, and spacing
- Sample `posts` post used for testing
- Any repeated one-off class patterns
- Any inconsistent spacing, typography, borders, shadows, colors, or radius usage

Then produce a self-contained implementation prompt that includes:
1. The exact goal
2. The files/components likely to review or edit
3. The role of each QA/design-system task
4. The recommended order of review
5. Project-specific findings from this repo
6. What should be standardized into reusable site-wide tokens/classes/components, using the MDX article content sample styling as the reference
7. What one-off styles should be removed or normalized
8. How to verify consistency across post components
9. How to verify desktop, tablet, and mobile layouts
10. How to verify accessibility basics
11. How to verify MDX content edge cases
12. How to verify production readiness
13. Constraints and what not to change
14. Dependency guidance
15. A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:
- Do not redesign the post layout from scratch
- Do not add new major features
- Do not change the approved component purposes
- Preserve the existing content model
- Preserve the existing post routing
- Preserve the existing collection relationships
- Prefer refining existing components over creating new ones
- Use existing design tokens and Tailwind conventions
- Codify the approved MDX article content sample styling into shared website-level design-system primitives, not just styles scoped to the posts collection
- Codify other repeated patterns only where it improves consistency and maintainability
- Remove duplicated styles where safe
- Fix obvious visual, responsive, semantic, and accessibility issues
- Make the final layout feel like one cohesive system

QA areas to check:
- Hero spacing, typography, metadata, image behavior
- Article content readability
- Headings hierarchy and spacing
- Links, lists, blockquotes, code blocks, images, tables, and horizontal rules
- Video embed responsiveness
- Inline CTA contrast and spacing
- What To Do Next component hierarchy
- Author box consistency
- Related posts layout
- End CTA visual priority
- Sidebar layout, TOC, glossary context, newsletter CTA
- Mobile TOC/sidebar behavior
- Tablet layout behavior
- Long titles
- Missing optional fields
- Posts with no glossary references
- Posts with no related posts
- Long code blocks
- Wide tables
- Images with different aspect ratios

Do not build:
- New post features
- New content collections
- New recommendation engine
- New newsletter backend
- New analytics/tracking
- New contact or booking system
- Full site redesign
- New page templates outside the post layout, though updating shared design-system styles used across the website is in scope
- Unrelated refactors

Dependency rule:
Do not add new dependencies for this pass unless there is a clear production-blocking issue that cannot be solved cleanly with the existing Astro, Tailwind, and project conventions. If a dependency is recommended, explain why before including it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.

I’m working on an existing Astro + Tailwind + TypeScript website.

I want you to inspect the project and create a self-contained implementation prompt that I can copy into a brand-new Codex chat after clearing context.

Do not implement anything yet.

Your output should be one clean, copy-pasteable prompt for the next Codex chat.

The next prompt should tell Codex how to perform the final site-wide design system codification pass, using the approved MDX article content sample as the styling source of truth, plus the final layout QA pass for the complete individual post layout.

Goal: Codify the approved MDX article content sample styling into the project’s overall website design system, then verify the post layout is production-ready.

Important context: The post system should already include:

Post layout skeleton
MDX content styling
Hero section
YouTube video component
Inline CTA
What To Do Next component
Author box
Related posts
End CTA
Sidebar system
Mobile behavior

There should also be a sample post called the MDX article content sample. Treat that sample’s approved visual styling as the reference for the site-wide content design system, including H1, H2, H3, H4, H5, H6, paragraphs, links, unordered lists, ordered lists, nested lists, blockquotes, inline code, code blocks, images, tables, horizontal rules, and related article-content spacing.

This step is not about adding new features. It is about standardizing, codifying, cleaning up, and QA-checking the full post experience while making the approved article-content styling available through the website’s shared design system, not only through one post/content-collection layout.

The QA/design system pass should:

Standardize spacing
Standardize typography usage across the entire website based on the approved MDX article content sample
Normalize component styles
Ensure visual consistency across all post components
Ensure the article-content element styling is codified into shared/global design-system primitives so it can be reused outside the posts collection
Remove one-off styles and conflicts
Confirm desktop/tablet/mobile behavior
Confirm accessibility basics
Confirm the layout is production-ready

Please inspect:

Existing global CSS/design tokens
Tailwind config
Post layout file
All post-related components
MDX/content styling
Mobile responsive behavior
The MDX article content sample post and its approved styling for headings, lists, links, code, quotes, tables, images, and spacing
Sample posts post used for testing
Any repeated one-off class patterns
Any inconsistent spacing, typography, borders, shadows, colors, or radius usage

Then produce a self-contained implementation prompt that includes:

The exact goal
The files/components likely to review or edit
The role of each QA/design-system task
The recommended order of review
Project-specific findings from this repo
What should be standardized into reusable site-wide tokens/classes/components, using the MDX article content sample styling as the reference
What one-off styles should be removed or normalized
How to verify consistency across post components
How to verify desktop, tablet, and mobile layouts
How to verify accessibility basics
How to verify MDX content edge cases
How to verify production readiness
Constraints and what not to change
Dependency guidance
A final implementation checklist for the fresh Codex chat to follow

Implementation expectations:

Do not redesign the post layout from scratch
Do not add new major features
Do not change the approved component purposes
Preserve the existing content model
Preserve the existing post routing
Preserve the existing collection relationships
Prefer refining existing components over creating new ones
Use existing design tokens and Tailwind conventions
Codify the approved MDX article content sample styling into shared website-level design-system primitives, not just styles scoped to the posts collection
Codify other repeated patterns only where it improves consistency and maintainability
Remove duplicated styles where safe
Fix obvious visual, responsive, semantic, and accessibility issues
Make the final layout feel like one cohesive system

QA areas to check:

Hero spacing, typography, metadata, image behavior
Article content readability
Headings hierarchy and spacing
Links, lists, blockquotes, code blocks, images, tables, and horizontal rules
Video embed responsiveness
Inline CTA contrast and spacing
What To Do Next component hierarchy
Author box consistency
Related posts layout
End CTA visual priority
Sidebar layout, TOC, glossary context, newsletter CTA
Mobile TOC/sidebar behavior
Tablet layout behavior
Long titles
Missing optional fields
Posts with no glossary references
Posts with no related posts
Long code blocks
Wide tables
Images with different aspect ratios

Do not build:

New post features
New content collections
New recommendation engine
New newsletter backend
New analytics/tracking
New contact or booking system
Full site redesign
New page templates outside the post layout, though updating shared design-system styles used across the website is in scope
Unrelated refactors

Dependency rule: Do not add new dependencies for this pass unless there is a clear production-blocking issue that cannot be solved cleanly with the existing Astro, Tailwind, and project conventions. If a dependency is recommended, explain why before including it.

The final answer should only be the copy-pasteable prompt for the next Codex chat.