Share your best AI workflow. We could show it to 2M+ people.

An AI “executive brain” needs two things: intelligence that, combined with your context, forms the system’s “brain,” and a harness that gives it “hands”—the agentic capabilities to act on your behalf. Claude Code and Codex are two popular options. Their apps provide both the model and the harness in an easy-to-use interface. My workspace is GitHub because popular AI models already understand it and can handle its setup and administration for me. GitHub also syncs automatically with the local file system on my MacBook, so I retain complete ownership and control. If I ever wanted to leave GitHub, I could do so without lock-in. The same setup can work in any file system, from your local file system or Google Drive to a more sophisticated option like Obsidian. A good manager has a structured process for onboarding and staying aligned with a team. You need the same structure to work effectively with AI. My “executive brain” has four layers: the company layer, project folders, operations folders, and the process layer. The company layer contains the mission, vision, values, brand guidelines, and decision-making principles. Project folders contain one folder per project, including its specification, plan, open questions, and decision log. Operations folders cover ongoing areas of the business, such as marketing, finance, and support. They have the same shape as project folders, but they never finish: projects ship, while operations run. The process layer contains standard operating procedures for how we work together, such as processing a meeting, planning a project, publishing a post, and closing out the week. For AI to work successfully, your company has to be “legible” to it. If information is not written down and accurate, it is not legible, and the AI cannot help you with it. This is like onboarding a great new hire: explain what the company is trying to do, what each project is for, what has already been decided and why, and how you like to work. You do not need to write everything alone or all at once. The AI can interview you, draft the documents, and file them in the right place based on the structure you set up. An employee without logins cannot do much, and AI works the same way. Start with the places where you communicate. At my company, we primarily communicate through Zoom and our community forums, so my AI system is connected to both. This allows it to stay up to date as we progress and participate in discussions as an equal participant when asked. Once the AI is connected to your communications, give it access to the places where you want it to execute on your behalf. You can connect it directly through an API or MCP, or it can use a browser to interact with a tool the same way you do by clicking and typing. You decide what it can access, and you can start small. Each connection turns a category of “things I have to do myself” into “things I can delegate.” The final step is incorporating what the AI learns. After every working session and meeting, it updates the record: decisions are logged, task lists are reconciled, and project documents are brought up to date. When we learn something, it goes into the SOP, so every future run is sharper than the last. That is how the AI becomes more useful every week: its knowledge compounds inside the business instead of starting from zero in every conversation. Step-by-step: 1. Choose the intelligence and harness that will power your AI system. Claude Code and Codex are two popular options whose apps provide both in an easy-to-use interface. 2. Create a workspace for alignment, planning, feedback, and learnings. I use GitHub because AI models understand it, it handles setup and administration, and it syncs with my local MacBook file system without locking me in. 3. Organize the workspace into four layers: company information, project folders, operations folders, and process documentation. 4. Make the company legible by documenting its goals, projects, decisions, working preferences, and other relevant context. Have the AI interview you, draft the documents, and file them in the appropriate locations. 5. Connect the AI to your communication tools, such as Zoom and community forums, so it can stay informed and participate when asked. 6. Connect the AI to the systems where you want it to execute tasks. Use a direct API or MCP connection when available, or give it browser access when it is not. 7. After each working session and meeting, have the AI update decisions, task lists, and project documents. 8. Add new learnings to the relevant SOP so each future run improves on the last.

AI is good at generating polished answers, but polished answers are not always your answers. When people ask AI for help with writing, strategy, or difficult decisions, it can jump too quickly to a conclusion and fill in beliefs the user has not fully examined. I created a thought-partner agent that interviews me before producing recommendations or drafts. Its job is to ask probing questions, challenge weak assumptions, surface contradictions, and separate my actual views from ideas suggested by the AI. Instead of writing for me immediately, it helps me clarify my position first. Step-by-step: 1. I give the agent the topic, decision, or idea I want to explore. 2. I tell it not to draft the final output yet. Its first job is to interview me. 3. I have it ask one focused question at a time about my reasoning, evidence, assumptions, audience, and uncertainty. 4. I require it to challenge vague claims and point out contradictions or overlap with my previous thinking. 5. I ask it to clearly separate: - conclusions I stated - ideas the AI proposed - issues that remain unresolved 6. I continue until the central belief, argument, or decision becomes clear. 7. I have the agent create a structured synthesis containing the core thesis, supporting reasoning, counterarguments, open questions, and useful language from the discussion. 8. I pass that synthesis to a writing, planning, or execution agent. I end up with a position that reflects my actual thinking rather than a plausible answer generated by AI. The final writing or strategy is more original, more consistent, and easier for downstream agents to execute.

I turned an open-source XML lookup fix into a debugging walkthrough that other developers can run. I used Codex, Python, and GitHub to document a bug where a document style containing quotation marks could be saved but then fail during retrieval because its name was interpolated into an XPath expression. Step-by-step: 1. I gave Codex the original patch and inspected the affected code, tracing the stored value through the public API, the wrapper, and the XML library. 2. I extracted the smallest standalone reproduction with `lxml`. It included a name containing both single and double quotes and kept the failing lookup visible. 3. I replaced interpolation with a bound variable: `styles.xpath("style[@name=$name]", name=name)`. I checked that the wrapper forwarded variables while preserving its namespace mapping. 4. I ran both versions. The interpolated version raised `XPathEvalError` in my reproduction. Binding the value matched five exact names, while an absent name returned no match. 5. I published the explanation, executable example, and upstream patch together. I inspected the rendered article and links and disclosed AI assistance. A prompt to reuse: "Reduce this lookup failure to a runnable example. Keep the failing case, show the fix, and check ordinary text, both quote types, custom namespaces and a missing value. Report which checks actually ran." The original fix had already been merged, so this workflow documents it. Broader service behavior needs separate tests. I used my existing Codex and local Python setup and did not measure time savings. I am Hồ Khắc Huy, a freelance software engineer. This is my independent open-source work. The linked article includes the runnable example, upstream contribution, and my contact details: https://github.com/builtbyhuy/builtbyhuy/blob/main/notes/2026-09-06-xpath-variables.md

Most AI agents are built around general best practices. That’s useful, but it doesn’t mean they work the way I want them to. I’ve started using a simple calibration process to tailor my agents to my preferences. Instead of telling an agent what to do on each task, I have it interview me about how I like work done in its specific domain. A writing agent asks different questions than a research agent, and a strategy agent asks different questions than a coding agent. The goal is to make my working preferences part of how the agent operates. Step-by-step: 1. I pick an agent I use regularly, such as one for writing, research, strategy, coding, analysis, or career advice—especially where my personal preferences matter. 2. I ask the agent to interview me about how I prefer work to be done in its domain. A writing agent might ask about tone, structure, editing style, and how much pushback I want. A research agent might ask about source quality, depth, recency, citations, and how much synthesis I prefer. 3. I have the agent summarize what it learned and separate durable preferences from temporary or situation-specific ones. 4. I review the proposed changes and ask the agent to show me exactly how it wants to update its instructions or skills. I correct anything it misunderstood and explicitly approve the changes before anything is modified. 5. Once I approve the changes, I have the agent apply them to its instructions or skills so those preferences become part of how it works going forward. 6. I use the agent normally and pay attention to where it feels more aligned and where it still misses the mark. 7. When I notice recurring friction, I add or adjust the relevant preference instead of repeatedly correcting the same behavior task by task. 8. I repeat the interview periodically. My preferences, tools, and workflows change, so the agent should be able to ask which preferences are still valid, which ones I keep overriding, what has been annoying me, and what should be added or removed. The result is an agent that doesn’t just know how to do the job; it knows how I want the job done. Because every change is proposed and approved before it becomes permanent, the personalization stays intentional rather than turning into a collection of guesses about me.

Like many people, I had tasks scattered across emails, meeting notes, reminders, recurring responsibilities, and things I was simply trying to remember. Standard task managers helped me store tasks, but they did not solve the harder problem: turning unstructured information into a reliable daily and weekly execution system. I used ChatGPT Work and Codex to build a private, responsive task management application around the way I actually work. The system combines AI-assisted task capture with a Command Center, daily planning, weekly reviews, task lists, a Kanban board, recurring tasks, deadline reminders, search, filters, subtasks, comments, attachments, and a complete activity history. The most useful part is the connection between AI and execution. Emails and free-text descriptions can be interpreted with the OpenAI API and converted into structured tasks, reducing the amount of manual copying and organizing required. Step-by-step: 1. I mapped my real workflow by identifying where my tasks came from and what information I needed to manage them properly: title, description, status, priority, category, deadline, responsible person, subtasks, comments, attachments, recurrence, and activity history. I deliberately designed the system around my existing working habits rather than adapting my work to a generic task management template. 2. I used iterative conversations with ChatGPT Work and Codex to define the requirements, review the interface, build the application, test it, and refine individual functions. Instead of creating one enormous prompt, I worked in short cycles: describe a problem, implement the change, test it with real data, and improve it. 3. I built the application as a responsive web app that works across computers, tablets, and phones. Access is restricted through authentication, an approved-user allowlist, and server-side authorization because the system contains real personal and professional tasks. 4. I migrated my actual task history rather than starting with an empty demonstration: 238 tasks, 37 categories, 25 subtasks, 5 comments, and 671 activity records. I preserved invalid or disconnected historical records in a separate archive instead of silently deleting them. 5. I connected the application to the OpenAI API. The AI can interpret emails and free-text task descriptions and help turn them into structured, actionable tasks. The application also supports an email-to-task workflow, so actionable emails do not have to remain buried in the inbox. 6. I built a daily Command Center that gives me an overview of what requires attention, including deadlines, priorities, task status, and upcoming work. I use the daily planning view to decide what to focus on rather than simply working through the newest emails. 7. I added two complementary execution views. The task list is useful for searching, sorting, and filtering a larger number of tasks. The Kanban board gives me a visual overview of progress; tasks can be dragged between five status columns, and the new status is saved automatically. The default task list shows the newest tasks first, making newly captured work easy to find. 8. I kept the context inside each task by allowing every task to contain subtasks, comments, attachments, and a complete activity history. This keeps the reasoning, follow-up, and progress connected to a task instead of spreading them across several applications. 9. I automated recurring work and reminders. Recurring tasks are recreated according to their schedule, while deadline reminders help surface tasks before they become overdue. This is particularly useful for responsibilities that are important but easy to forget because they do not arrive as new emails. 10. I run a weekly review to check overdue work, upcoming deadlines, open commitments, and tasks that have stopped moving. I can then reprioritize, update statuses, and prepare the following week from the same system. 11. I preserved portability and control through Excel import and export and a full JSON backup. This gives me control over my information and reduces the risk of becoming dependent on one interface or platform. The result is not an autonomous agent making decisions on my behalf. It is a private execution system where AI handles part of the interpretation and structuring, while I remain responsible for priorities and decisions. It has given me one trusted place for capturing, reviewing, prioritizing, and completing work. The tools I used were: - ChatGPT Work - Codex - OpenAI API

Design taste is hard to put into words. I may know immediately that one website, presentation, report, or graphic feels right and another doesn't, but still struggle to explain whether the difference comes from the typography, spacing, colors, density, layout, or overall aesthetic. That makes working with AI frustrating. If I can't describe what I want, the AI has to guess. Instead of trying to explain my design taste upfront, I turned the process into an iterative visual feedback loop. I first asked the AI to suggest existing websites with different design styles so I could identify examples I liked. Once it had those references, I asked it to create three substantially different HTML mockups for the same content. I picked the direction I liked best, explained what I liked and disliked, and had the AI generate another set of alternatives based on that feedback. After about three rounds, the AI had a much better understanding of my design preferences than I could have given it in a written prompt. The basic loop is: show me examples → I choose → generate alternatives → I react → refine → repeat. This is essentially preference elicitation through examples. Research on human-AI interaction has similarly found that people can refine difficult-to-articulate preferences by reacting to concrete alternatives rather than specifying everything upfront. Step-by-step: 1. I asked the AI for several visual references, including websites or designs that represented distinctly different styles. 2. I reviewed the examples and identified the ones I liked. I didn't need sophisticated design terminology; I simply described what I preferred and anything obvious that I liked or disliked. 3. I gave the AI something real to design. I used an actual report I was working on so I could evaluate the styles in context. 4. I asked the AI to create three substantially different visual directions rather than minor variations of the same design. 5. I chose the direction closest to my taste and explained what I liked, what I didn't, and which elements from the other versions I wanted to incorporate. 6. I asked the AI to generate three new alternatives using everything it had learned so far. 7. I repeated the process until the designs began to converge. I did roughly three rounds, with each round narrowing the design space and giving the AI more information about my preferences. 8. I asked the AI to summarize what it had learned into reusable design guidelines so future projects could start with those preferences. Instead of trying to translate an aesthetic preference into design terminology, I let the AI learn my taste from my choices. The important shift is simple: don't describe what you like—show, choose, react, and refine. This can work for websites, presentations, reports, branding, graphics, interior design, clothing, invitations, or almost anything else where I know what I like when I see it.

I’m building GradePath because schoolwork gets scattered quickly. A lecture, my notes, and the files for a class can all end up in different places. Then, when it’s time to study, I have to dig around to find what I need. The idea is simple: record a class, keep the recording and course materials together, and return to them later. If I ask Tutor about something, it should show me the relevant part of my notes, files, or class recording. If it can’t find an answer, it should say so. I also want students to be able to share useful study sheets with people who are actually in their class. I’m not trying to turn school into another content feed. I want to make it easier to keep up with a class and find the right material when I need it. Step-by-step: 1. I record a class. 2. I keep the recording, notes, and course materials together in GradePath. 3. I return to those materials when I need to study. 4. I ask Tutor about a topic and have it show the relevant part of my notes, files, or class recording. 5. If Tutor can’t find supporting material, it says so instead of presenting an unsupported answer. 6. I share useful study sheets with students who are in the same class.

Commercial vehicle maintenance information is often fragmented across driver reports, warning lights, fault codes, inspections, repair records, and vehicle history. This makes it difficult for smaller fleets to decide whether a vehicle can continue operating, requires scheduled repair, or should be stopped immediately. We built TruckFixr Fleet AI to turn an unstructured driver report into a clear, reviewable maintenance action. The workflow begins when a driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. The report is then evaluated alongside available vehicle history and previous repairs. The workflow provides decision support through three practical actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. Final safety decisions remain with authorized fleet or maintenance personnel. After an inspection or repair, the confirmed cause, work performed, and outcome are recorded, creating a more complete vehicle history for future cases. The general workflow can be recreated using a mobile form, OCR, a vehicle-history database, an AI model, automation software, and a human-review dashboard. Step-by-step: 1. A driver submits symptoms, photos, fault codes, and vehicle information through a mobile-friendly form. 2. AI and optical character recognition extract the relevant details and organize them into a structured maintenance case. 3. The workflow compares the report with available vehicle history and previous repairs. 4. The system provides one of three decision-support actions: continue operating while monitoring, schedule an inspection or repair, or stop and escalate for immediate professional assessment. 5. Authorized fleet or maintenance personnel make the final safety decision. 6. After inspection or repair, the confirmed cause, work performed, and outcome are recorded in the vehicle history. TruckFixr has used this approach to support more than 100 vehicle-issue resolutions in early fleet pilots, helping fleets identify problems earlier, prevent avoidable breakdowns, and keep vehicles moving safely.

I wanted to reduce the time and mental effort it takes each morning to figure out what needs my attention across my inbox and calendar. I used Codex Automations to build Briefly, a daily AI-powered email and calendar brief that is automatically delivered to my inbox every day. Instead of manually searching through emails and checking separate calendar events, I can open one message from Briefly and immediately see what is happening, what needs action, and what is coming up. It has become a simple way for me to use AI proactively—not only when I ask a question, but as an automated system that helps me stay ahead of my emails, tasks, and schedule each day. Step-by-step: 1. I connected the email and calendar sources I wanted the automation to review. 2. I created a Codex Automation that runs each morning. 3. I instructed it to review recent and important emails, identify messages that need attention or follow-up, and check my calendar for upcoming meetings and commitments. 4. I had it turn that information into a concise daily brief. 5. I configured the brief to be delivered to my email automatically.

I give the system a topic, such as Private Credit, inference workloads, or agentic harnesses. It then runs an intake survey to understand my goals—for example, learning more about inference workloads so I can differentiate between providers and routers for different models. Next, an agent builds a multi-phase curriculum with learning outcomes, external resources, generated primers, and checkpoints for each phase. I work through the curriculum in an Obsidian space, asking questions and reviewing my notes and answers throughout each stage. By the end, my current understanding is documented in a `state.md` skills file that I can build on when exploring related topics in the future. I call this “Burst learning.” Step-by-step: 1. I provide the system with a topic, such as Private Credit, inference workloads, or agentic harnesses. 2. I complete an intake survey that identifies my goals for learning about the topic. 3. An agent creates a multi-phase curriculum with learning outcomes, external resources, generated primers, and checkpoints. 4. I work through each phase in an Obsidian space, asking questions and reviewing my notes and answers. 5. I document my current understanding in a `state.md` skills file to support future learning about related topics.

Most AI agents are effectively static. You write their instructions, use them repeatedly, notice where they struggle, and manually tweak the prompt when something goes wrong. Valuable feedback from real work is often lost, so the same mistakes can keep happening. I created a self-improvement flywheel that uses actual agent performance data to improve agents over time. The system collects two kinds of evidence: - Task scores showing how well each agent performs across different quality dimensions - Run telemetry and review outcomes revealing recurring failures, coordination problems, and cases where actual behavior differs from expectations A scheduled weekly cycle analyzes that evidence, identifies patterns, creates improvement proposals, evaluates whether those proposals are safe and broadly applicable, updates agent instructions when appropriate, and measures whether those changes actually improve performance. The goal is not to let agents rewrite themselves freely. It is to create a controlled learning loop. Step-by-step: 1. Collect performance data while agents work. Score important outputs across consistent quality dimensions, and record useful execution telemetry such as failures, decisions, reviewer outcomes, and unexpected behavior. 2. Analyze performance trends on a recurring schedule. Calculate per-agent averages, identify weak dimensions, compare agents, and look for improvement or decline over time. 3. Mine run history for recurring patterns across multiple sessions, including agents that repeatedly struggle, low-quality runs, and cases where expected behavior differs from what actually happened. 4. Turn repeated problems into improvement proposals. Before proposing a change, inspect the agent’s current instructions so you do not add a rule that already exists. 5. Evaluate each proposal before applying it. Check whether the lesson is broadly useful, redundant with existing instructions, or in conflict with established behavior. 6. Separate low-risk and high-risk changes. Automatically apply additive or clarifying improvements. Escalate conflicting changes for human review instead of allowing the system to fundamentally change an agent’s behavior on its own. 7. Look for system-level problems. Analyze patterns across agents to identify quality gaps, missing capabilities, or coordination failures that cannot be fixed by changing one agent alone. 8. Apply approved improvements and preserve the history. Update the relevant agent instructions, archive the processed proposals, and version the changes so they remain inspectable and reversible. 9. Measure whether each change actually helped by comparing agent performance before and after the refinement. If quality does not improve, do not automatically assume the change was useful. 10. Repeat the cycle. As agents complete more real work, the system gathers more evidence and gets another opportunity to improve. Instead of treating agent instructions as static prompts, I turned them into a continuously improving system: Work → Evaluate → Find Patterns → Propose Changes → Refine → Measure → Repeat The important part is that the loop is evidence-driven and controlled. Agents improve from real usage, but low-confidence or behavior-changing updates still require judgment rather than being applied automatically.

Several months ago, my dad was in and out of the hospital. My two brothers and I were trying to coordinate his doctor appointments, manage his medications and potential interactions, and keep track of all the other details involved in his care. At one point, up to seven different doctors were seeing him in the hospital on any given day. It became important to track every medication he was taking, what each one was for, and information such as his weight and other vital statistics. When he returned home, we also had to make sure someone checked on him and his wife every day, helped him stay on schedule with his medications, and recorded his diet, mood, and weight. We initially used Apple Notes, a shared iCalendar, multiple text threads, and a weekly call between the three of us. The mental load was huge. If we needed to find information from the previous week, we had to scroll through pages of Apple Notes to locate it. We also struggled to keep the rest of the family updated. Before my dad passed away, I started using Claude Code and Codex to build a simple tool that would keep everything organized and searchable. It also displayed trends in areas such as his mood, appetite, and vital signs, and included a calendar showing who was covering which days and times. The tool was still fairly basic when he passed away. Afterward, we encountered the administrative headaches involved in closing out his estate. It was far more complicated than we expected. We thought having a will, power of attorney, and other documents meant we were prepared, but we were wrong. I began integrating those lessons—and the things we learned not to do—into the final product, Eldercare Log: eldercarelog.com. I built the final tool with Claude helping draft a PRD, which I then handed to Codex for the coding work. It took a few weeks of refining the product with Codex. The tool is hosted on Vercel, with Supabase and Stripe on the backend, and includes the security features I built into it. It is the tool I wish had existed when my brothers and I were going through this journey before my dad’s passing. Step-by-step: 1. I coordinated my dad’s doctor appointments, medications, vital statistics, and other care details with my two brothers while he was in and out of the hospital. 2. We tracked his medications, their purposes, his weight, diet, mood, appetite, and other vital signs while he was at home. 3. We coordinated daily visits and coverage using Apple Notes, a shared iCalendar, text threads, and a weekly call. 4. I used Claude Code and Codex to start building a searchable tool that organized his care information and showed simple trends. 5. I added a calendar to track which family member was covering each day and time. 6. After my dad passed away, I incorporated what we learned from handling his estate, including the things we wished we had known earlier. 7. I used Claude to draft a PRD, then gave it to Codex to handle the coding work and refined the product with Codex over several weeks. 8. I built the final tool with Vercel, Supabase, and Stripe on the backend.

It's finally gardening season in the Midwest, and I wanted to do a big overhaul of my space with a new large in-ground bed and a more organized layout of crops. I first took some images of the space and had ChatGPT / Codex generate some visualizations of what it could look like based on my rambling list of requirements and measurements. After deciding on the vision, I asked for help creating a materials list, a step-by-step guide to building the bed (with instructions on sawing, drilling, etc.). I also provided a list of what we wanted to grow, and was able to get a well-planned map of where to place each plant, optimizing for aspects like shade vs. sun, companion plants, vining, etc. Several trips to Home Depot and a couple of days of work later, we have an awesome, refreshed space and a thoughtful, organized garden for the season! Step-by-step: 1. I photographed the existing garden space and wrote down the measurements, requirements, and rough ideas I had in mind. 2. I gave the images and requirements to ChatGPT and Codex and asked for several visualizations of the finished space. 3. Once I chose a direction, I asked for a materials list and step-by-step instructions for building the in-ground bed. 4. I supplied the full list of plants and asked for a placement map based on sun, shade, companion planting, and vining behavior. 5. I used the plan to buy materials, build the bed, and install a more organized garden layout.

I use reusable AI skills rather than relying on one long prompt or previous chat history. I start by describing the project in plain English and invoking a project-kickoff skill. It creates a live project specification containing the objective, scope, constraints, acceptance criteria, concerns, and next actions. For larger or more ambiguous work, I can opt into a scope-discovery skill. AI guides me through one important decision at a time, explains the trade-offs, recommends a sensible default, and records each accepted decision until the project is ready to implement. When delivery involves several dependent or risky steps, I can use a runbook-design skill. AI converts the agreed scope into a checkpointed implementation plan with validation, rollback, and clear points where my approval or testing is required. AI then executes the runbook, builds the solution, performs automated checks, and records what actually happened. I mainly provide direction, answer business or product questions, and complete the human acceptance checks that AI cannot genuinely perform itself. The skills live inside the project repository alongside the code, decisions, runbooks, and documentation. Codex only links to them at runtime, so the repository remains self-contained and does not depend on my local setup or previous conversations. This also makes the workflow portable. Another capable AI agent or a human engineer can read the repository, understand how the project should be managed, and continue the work without reconstructing everything from chat history. Step-by-step: 1. I describe the project in plain English and invoke the project-kickoff skill. 2. I use the scope-discovery skill for larger or more ambiguous work, working through one decision at a time until the project is ready to implement. 3. I use the runbook-design skill when delivery involves dependent or risky steps, creating a checkpointed plan with validation, rollback, and approval or testing points. 4. AI executes the runbook, builds the solution, performs automated checks, and records what actually happened. 5. I provide direction, answer business or product questions, and complete the human acceptance checks AI cannot genuinely perform. 6. I keep the skills, code, decisions, runbooks, and documentation together in the project repository so the workflow remains self-contained and portable.

I built an agent from scratch that monitors my Claude and Codex usage by adding a runner node directly inside the root of each project repository. It includes agent templates for specific jobs, such as commit, research, janitor, and manager tasks. The agents run automatically at night, when I’m not actively using my five-hour usage period. They monitor their own usage and cap themselves so they leave usage available for me. Later, I built a hive dashboard where I can monitor all of these payloads in one place and execute them from the dashboard as the agents’ jobs become more complex. Step-by-step: 1. I added a runner node to the root of each project repository. 2. I created templates for specific agent jobs, including commit, research, janitor, and manager tasks. 3. I configured the agents to run at night when I’m not actively using Claude or Codex. 4. I had the agents monitor and cap their own usage so they preserve usage for me. 5. I built a hive dashboard to monitor and execute the payloads from a single place as the agents’ jobs became more complex.

I used /goal in OpenAI's Codex to build a Magic: The Gathering app so my brother and I can play asynchronously without needing to coordinate a call or awkwardly play over FaceTime. The idea is to let each of us take turns when we have time, track the board state cleanly, and keep a game going over days instead of trying to line up schedules. The command allowed Codex to continue running until everything was done, basically one-shotting exactly what I was looking for without any intervention. Step-by-step: 1. I defined the core problem: two people needed to play asynchronously without coordinating a call. 2. I described the app’s essential behavior, including turn-taking, persistent board state, and games that continue over multiple days. 3. I used /goal in Codex so the build could continue autonomously toward the finished result. 4. I let Codex implement the app and resolve the work without requiring step-by-step intervention. 5. I tested the finished flow to make sure each player could return later and continue from the correct state.

Sometimes a story needs a simple locator map to show where something happened or where something can be found—such as a business facility, a car accident, or the best place to see a sunset. I've worked in media for a long time and understand the power of maps to tell stories. But media cost-cutting and consolidation have reduced the number of available graphic departments, so creating a map is often the last task a reporter or editor wants to take on. I used Perplexity for initial research, Claude Code and Codex to build a web app, and Perplexity and ChatGPT for post-work such as SEO best practices. Step-by-step: 1. I used Perplexity's Deep Research mode to conduct a competitive market analysis. I asked it to analyze the field I was considering entering, identify competitors and growth rates, and explicitly break out feature sets. 2. I revised the research with my own idea and asked Perplexity to run the competitive landscape against it. I also provided desired outcomes, including intended audiences and where competitors were reaching them. I added the constraint, "Do it without syncophancy," so it would stop telling me how good my potential product was. 3. I hand-drew the initial screens and functions I wanted, then used the `/office-hours` skill in the Gstack bundle, available on GitHub, to play devil's advocate, sharpen the ideas, and challenge my assumptions. 4. I wrote a long prompt describing the product, starting broadly with the concept and audience and then narrowing to specific features and benefits. For example, I specified that it should export in 16:9 and 9:16 formats so maps would be ready for mobile vertical presentation. 5. I specified the hosting environment and that the product should be a web app. I also required a planning phase followed by construction phases. I pasted the prompt into Claude Code with this final line: "Use /grill-me to ask me questions to clarify intent." After 147 questions, it started the build. 6. This was in the pre-Fable days, so I specified that Opus 4.8 should act as an orchestrator while less expensive agents, particularly in Codex, handled the actual coding. 7. I used separate phases for technical work such as wiring in mapping providers and getting the UX to work correctly. Other phases included wiring in payment and subscriptions and making sure a subscription triggered an email campaign with instructions. 8. I dedicated an entire phase to building admin tools so I could manage the marketing language on the landing page and publish blog entries. 9. After each phase, I had the Opus/Codex combination perform an adversarial code-review-and-fix cycle. I then ran the `/ai-regression-testing` skill from the ECC repository on GitHub to catch issues the code review missed. 10. After every third phase, I prompted Claude Code: "Act as a senior QA engineer and go through the entire codebase looking for inconsistencies, functions that are in the wrong place, code that is overkill and security vulnerabilities." 11. When I had a product I thought was ready for testing, I prompted Claude Code, again using the Opus/Codex combination: "Act as a senior security engineer. Run this against OWASP standards. Find problems and suggest fixes. Harden this product overall." 12. As I neared the end, I asked Perplexity Deep Research and ChatGPT (Sol/High) to find SEO solutions for the product.

I’m retired and in my early 70s. I never got into RPGs growing up, but I decided to try a tabletop RPG with my wife. The game I purchased included a rulebook and a PDF of the book. I wanted my wife and me to play as the player characters without either of us having to be the game master, so I tested whether AI could take on that role. I used ChatGPT to parse the PDF and walk us through the process. It helped us create our characters, Heisenberg and Felicity, and then started the game as the game master. We’ve only just started, but it seems like this is going to work well. The AI can keep secrets to itself, roll the dice when needed, and guide us through the adventure. Step-by-step: 1. I purchased a tabletop RPG that included a rulebook and a PDF of the book. 2. I used ChatGPT to parse the PDF and walk us through the process. 3. ChatGPT helped my wife and me create our player characters, Heisenberg and Felicity. 4. We had ChatGPT start the game as the game master so neither of us had to fill that role. 5. We began playing while ChatGPT kept secrets to itself, rolled the dice when needed, and guided us through the adventure.

I was tired of opening Spotlight every time I wanted to switch apps. The search results would move around, I would occasionally open the wrong app, and those few wasted seconds kept adding up throughout the day. Instead of memorizing a collection of unrelated hotkeys, I used ChatGPT Work to design and build a personalized shortcut system in Apple Shortcuts. The shortcuts can open individual apps, jump directly into specific Safari or Chrome profiles, or launch an entire work mode with one keystroke. For example, a recording shortcut could open your microphone, camera, recording software, and notes. An analytics shortcut could open all the dashboards you check each week. Step-by-step: 1. I opened the ChatGPT desktop app, started a new chat, and switched to Work mode. 2. I asked ChatGPT to plan shortcuts around my real workflow: Based on what you know about me and my workflow, suggest 10 time-saving hotkeys we can set up in Apple Shortcuts. I’m interested in opening specific apps and profiles based on what I need them for or what mode of work I’m going into. 3. I told it which apps, browser profiles, URLs, and work modes I use most. 4. I narrowed the list before making any changes by keeping the highest-frequency shortcuts and avoiding macOS or app conflicts. 5. In ChatGPT, I went to Settings → Computer Use and turned on Any App. 6. I gave ChatGPT the approved list and clearly limited its scope: Set these up in Apple Shortcuts. Do not change anything outside this list. Test each shortcut. 7. I opened All Shortcuts in Apple Shortcuts and ran each one manually. I used Quick Actions to add or change its keyboard shortcut. I like Control + Option because it is less likely to conflict with existing Mac commands. 8. I tested every shortcut while working in another app, checking that it opened the correct app, account, browser profile, or collection of tools before building more. 9. Once everything worked, I asked ChatGPT to create my reference: Write me a one-page cheat sheet of all the shortcuts you set up, where they live, and what’s left to do. The result is a personal shortcut system built around how I actually work, plus a one-page cheat sheet so I don’t have to memorize everything immediately. For the complete walkthrough, exact prompts, screenshots, and setup instructions, follow my full Rundown University guide: Use ChatGPT to Build a Custom Mac Shortcut System. Tools used: ChatGPT Work, Apple Shortcuts Industry: Cross-industry Tags: #chatgptwork #appleshortcuts #macautomation #productivity #workflowautomation

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.