AI Engineer World's Fair 2026
Using Spec-Driven Development for Production Workflows
Read the talk
Spec-Driven Development: From a Request to a Testable Implementation
Write and review requirements, design, and implementation tasks before asking a coding agent to build, then turn the agreed behavior into tests.
From a talk by Erik Hanchett
Before you start: Familiarity with coding assistants and Markdown is enough to follow the workflow; the final testing example uses TypeScript.
Specifications before code
How do you get a coding assistant to produce better software, rather than simply produce code faster? Spec-driven development puts reviewable specifications before implementation. Requirements and design documents, written in Markdown, give the assistant an explicit description of what to build before it starts changing code. The intended benefit is both speed and quality; the workflow itself is the subject here, rather than a measured comparison of those outcomes.
The difficulty is familiar to anyone who has managed an eager intern. Early in Erik Hanchett’s career, a VP would walk around suggesting ideas, and Hanchett would drop his assigned work to pursue them. His manager taught him a different sequence: record the request, put it into the schedule, and discuss it before acting. Coding assistants can show the same eagerness. A plausible new request becomes an implementation unless someone supplies the priorities and checkpoints that should come first.
Hanchett introduces himself as a senior developer advocate at AWS with more than 15 years of software development experience. His recommendation is to make that intervening process explicit for the agent: capture what is wanted, inspect the proposed approach, and only then authorize implementation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the agent enough context—and review what it does with it
Better frontier models do not remove the need to describe a changing project. Requirements, software conventions, and architectural choices keep moving; the model needs the current version of that context. Thinking and planning modes in agent harnesses can delay the jump into code, but Hanchett favors an additional checkpoint: actual documents that a developer can inspect and revise before implementation begins. He presents these recommendations as working judgments, not settled rules for every project.
More context is not automatically better. Files such as AGENTS.md and CLAUDE.md, or steering documents in Kiro, should contain enough rules to orient the assistant without burying the task in instructions. Keep persistent project guidance focused, and bring specialized instructions into the workflow when they become relevant.
Skills provide that on-demand guidance. Hanchett describes them as instruction files activated by task cues or a slash command. More precisely, current Kiro Agent Skills documentation describes automatic activation through matching the request to a skill’s description, rather than a guaranteed literal keyword trigger. Skills can help while the assistant writes the design document and again while it implements individual tasks.
The developer remains responsible for both the plan and the code. Review requirements and design documents interactively, then review the generated implementation. That does not mean reviewing alone: other developers, coding assistants, and pull-request review tools can all help. Their assistance does not transfer responsibility for the result to the agent.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The workflow does not depend on the editor
Kiro grew out of a pattern AWS teams saw among customers who were dissatisfied with their coding assistants’ output. Those customers were already asking agents to produce full requirements and design documents. Kiro turned that practice into a product workflow, with an IDE and a CLI. Its general-availability announcement is dated November 17, 2025, anchoring Hanchett’s reference to a release late in the preceding year.
The IDE exposes Vibe and Spec modes. Spec mode addresses the need to plan larger features and complex projects with a clearer understanding of the existing application. Hanchett describes increasing interest in the CLI as well. Hanchett reports tens of thousands of launch downloads. He also recalls a preview access gate introduced under heavy demand, users finding ways around it, and the later public availability of the IDE and CLI.
The same process can be performed manually with a coding assistant:
- Create requirements. Ask the assistant to derive user requirements from the feature request, or supply an existing requirements document as its starting point.
- Review the requirements. Work through omissions and misunderstandings before moving on.
- Create and review the design. Ask how the accepted requirements will be implemented, then inspect that proposal.
- Generate implementation tasks. Derive the task list from both the requirements and the design, so the work has a traceable basis.
GitHub Spec Kit is another way to organize this staged process across coding assistants. The essential mechanism is the sequence of artifacts and reviews, not a particular editor.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Start with a feature, then refine the documents
In the recorded Kiro IDE, select Spec and enter a request—for example, a movie MCP server that tracks films you have watched, or a movie website. Hanchett calls the CLI entry point Plan mode and later refers to a quick plan mode. Those are the recording’s labels; current Kiro Specs documentation describes CLI specs and Quick Spec.
A new movie application is an easy example, but specs also fit existing codebases. Hanchett has seen years-old applications containing dozens of spec files. He recommends the approach especially for in-depth features and complex projects that need upfront planning. Kiro also offers a bug-fix spec workflow, although he suggests a more direct vibe-coding interaction may be sufficient for small changes.
The requirements phase produces an introduction, user stories, and requirements in EARS—Easy Approach to Requirements Syntax. Structured requirements make the triggering situation and expected behavior easier to inspect than a broad feature request. Clarifying questions can come before document generation; the quick plan option described in the recording uses those answers to generate the documents together.
The next artifact is a higher-level design, potentially including Mermaid diagrams or ASCII diagrams. The order can vary: start with requirements, start with design, or combine the two documents where that makes sense. Pause here to add project knowledge and implementation preferences. A generated design becomes useful when someone who understands the application edits its assumptions and choices, rather than merely accepting a polished Markdown file.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make the first tasks deliver something working
Before generating implementation tasks, inspect the Markdown for inconsistencies, hallucinations, and errors. The resulting task list can include property-based tests derived from requirements and design: checks of behavior that should hold across different inputs. Hanchett recommends generating and running those tests as part of implementation.
He also asks the assistant to reorganize the beginning of the task list around a working MVP. His usual request is to put the top four tasks first and make them deliver that initial version. The purpose is to see the application working before proceeding through the rest of the plan. The useful constraint is a working slice of the product, not four arbitrary items checked off a list.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Bring existing requirements into the spec
Model Context Protocol connects AI applications to external data sources. Hanchett sketches a model-backed tool such as Kiro, an illustrative provider such as OpenAI or Anthropic, and MCP between the application and its sources. The workflow benefit is access to information the team has already written elsewhere.
Command-line tools can cover some of the same ground. Hanchett acknowledges that alternative while describing MCP, including its security work, as still maturing. For specification work, his concrete use case is pulling tickets and larger requirements documents from systems such as Jira or Asana. A product manager’s requirements can then inform the generated spec instead of being manually reconstructed in a new prompt.
The assistant still needs to know where to look. Put a rule in steering documents or AGENTS.md directing the specification workflow to the relevant MCP server, or explicitly request that source in the initial requirements prompt. This makes retrieval part of requirements creation, before the assistant turns incomplete context into a design and task list.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Inside the movie-site specification
The IDE demonstration opens a prepared movie-database project rather than building a new application during the recording. Its starting request was “Please create me a movie website.” Hanchett deliberately chose the design-first path, then opened the rendered Markdown preview. The design includes architecture and sequence diagrams, and he describes iterating with the assistant to edit that design.
Further down the design document are property tests using fast-check in TypeScript and Node. Hanchett describes property tests running dozens or hundreds of times with different values. That repeated variation is how the tests probe whether a stated property survives more than a few handpicked examples; the recording does not establish the project’s configured run count or a passing test result.
The requirements document follows, again using EARS and user stories. The visible walkthrough reaches movie-data loading and a requirement triggered by application initialization, involving the filter engine. This gives the design and implementation a more specific target than simply making a movie website: startup behavior is expressed as something the application is required to do.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From the MVP task list to a genre invariant
Hanchett then asks the assistant to reorganize the movie-site tasks around an MVP. The revised task list assigns tasks one through four to a browsable movie grid with search, genre filtering, sorting, and an ’80s synthwave theme. He says the requirements were revised around that goal and that he subsequently implemented all the tasks. The displayed list explains the intended first working version; his account supplies the implementation outcome.
The IDE also exposes property-test execution information and hover descriptions. The final example states a precise invariant: for any movie dataset, the extracted genres must be exactly the sorted set of unique genres. This combines three obligations: preserve every genre present in the input, remove duplicates, and return the result in sorted order.
For a concrete illustration, take two movie records with genres ['Drama', 'Comedy'] and ['Drama', 'Action']. Extraction should produce ['Action', 'Comedy', 'Drama'] without changing either record. The following TypeScript expresses the operation and tests the same invariant across generated datasets:
typescript
import assert from 'node:assert/strict';
import fc from 'fast-check';
type Movie = { genres: string[] };
function extractGenres(movies: Movie[]): string[] {
return [...new Set(movies.flatMap(movie => movie.genres))].sort();
}
const movies: Movie[] = [
{ genres: ['Drama', 'Comedy'] },
{ genres: ['Drama', 'Action'] },
];
assert.deepEqual(extractGenres(movies), ['Action', 'Comedy', 'Drama']);
const movieArbitrary = fc.record({
genres: fc.array(fc.string()),
});
fc.assert(
fc.property(fc.array(movieArbitrary), dataset => {
const before = structuredClone(dataset);
const result = extractGenres(dataset);
const inputGenres = dataset.flatMap(movie => movie.genres);
assert.deepEqual(new Set(result), new Set(inputGenres));
assert.equal(result.length, new Set(result).size);
assert.deepEqual(result, [...result].sort());
assert.deepEqual(dataset, before);
}),
);
The set comparison checks membership, the length check rules out duplicates, and the sorted-copy comparison checks ordering. Input preservation is an additional check in this illustration. The movie example ends with a specification that can be challenged by tests: an exact relationship between input records and output genres, rather than an impression that filtering looks right.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Official product site with downloads and documentation for Kiro.
Open-source toolkit for turning specifications into implementation plans and tasks across coding assistants.
Reference for property-test run counts, random seeds, counterexample replay and execution limits.
Further reading
Alistair Mavin explains structured requirement patterns for events, states, optional features and unwanted behavior.
The original announcement explains MCP's purpose and client-server approach to connecting assistants with external systems.
The November 2025 announcement introducing general availability, Kiro CLI and property-based testing.
Updates since the talk
Current guide to specification artifacts, feature and bugfix workflows, and task execution.
How to package reusable instructions and invoke them automatically or through slash commands.
Read the complete timestamped transcript
- 0:00
Hey everyone, my name is [REDACTED:username], and today I want to tell you guys all about spec-driven development and how you might use it in your workflows today. So there's a couple of things we want to talk about.
- 0:11
First, what is spec-driven development? And then how can it make you a better and faster coder? So we just don't want you to code faster, but we want you to actually create higher quality code from it.
- 0:25
And I think really spec-driven development helps you with this, and I'm going to explain why and how. It's a structured-- specifications are created before any code is written. That's the definition of really the specs or the requirements of this spec-driven development, and it goes to the heart of what it is.
- 0:43
So what we're doing is we are writing these markdown files. We're writing the specifications and the design document before any of the code is written. And this actually works really, really well with large language models and our coding assistants that we use.
- 0:59
And I'm going to show you exactly how that works.
- 1:03
Now, a question I sometimes get is why? Like, why should we use this spec-driven development workflow? And then how can we do it? So to answer that why question, I kind of like to think about our coding assistants, our large language models that we're using every day as sort of like AI interns.
- 1:23
You need to really prompt them. You really need to push them the right way, no pun intended with the prompting. So you really need to guide them because if you give them just a little bit of, of leeway, they will go off the rails.
- 1:37
And really, the spec-driven development helps guide them in the right direction. I remember when I was an intern in one of my first jobs, we had a VP that would walk around, and he would just come up with random ideas off the top of his head.
- 1:50
And when he told me it, I would drop everything and work on it. And then later my boss would be like, "Hey, Erik, why did you drop everything?" "Well, the, the VP said something."
- 2:00
And then I learned about, well, you got to take his information that he gives you, write it down, put it in your schedule, talk to me-- talk to my manager about it.
- 2:09
So I was a little too eager. And this is what AI, uh, interns or basically these large language models do nowadays, and we got to be careful about it.
- 2:18
I didn't really give you too much of introduction, so I'll give it to you now. My name is [REDACTED:username]. I'm a senior developer advocate at AWS. I have over fifteen plus years of software development experience.
- 2:31
Uh, and if you want to connect with me, you can check out LinkedIn. That's probably the best place to go. Uh, just look for [REDACTED:username] and, uh, yeah, talk to me, follow me.
- 2:41
I'd love to talk to you more about it.
- 2:44
Another question when I-- that people often ask me a-about spec-driven development is: Can't the latest frontier models just do everything for us already? Why do we need this? And while I do say that the models are getting better and better every year and, and every release, sometimes incrementally, sometimes by leaps and bounds, it's still not perfect.
- 3:05
And giving the large language model, these models more context is actually really important because it does help guide it in the right direction. And with our software com-- always changing and with the requirements always changing, uh, and with new paradigms and shifts, you always need to kind of guide it where it needs to go.
- 3:23
Some large language models, some harnesses are starting to think more about this and adding in a little bit more of a thinking or planning mode before it jumps into when it writes code.
- 3:34
But there's nothing better than actually having those documents created and having you be in the middle before it jumps into the n- that next part with it creating code.
- 3:46
So let's keep a few things in mind before we get too far. There is quite a lot of information out there. I have some opinions. These are my opinions.
- 3:56
Uh, let me know. Connect with me on LinkedIn if you agree or disagree, but I think you need to keep these in mind before using spec-driven development or vibe coding or anything in between.
- 4:06
We have to-- You have to be careful with context. Now, I told you before that spec-driven development gives you a lot of context that gets fed into that large language model, but sometimes you have too much of a good thing.
- 4:17
Uh, what you need to do is when you are working with these large language models, usually you create like an AGENTS.md or CLAUDE.md at the beginning with some information in it.
- 4:28
I would be very careful not to put too much information or too little information in that. Kind of like that Goldilocks zone of information is what you need. So you just need to give it enough rules and guidelines that it knows what to do.
- 4:41
Uh, we call it steering docs in Kiro, which I'll mention about in a minute, but you just got to be very careful what you put in those documents. I also highly recommend when you're using spec-driven development to use skills.
- 4:54
Skills are like instruction files that you can give to your coding agents that are ran on demand. So usually they have keywords in them, and when the coding assistant sees those keywords, they'll activate the skill, or you can do slash and the skill name and then run it.
- 5:10
But this actually really helps when you're doing the spec-driven development process. You can actually add skills, um, when it creates your design documents or whatever else. You can use those in parallel or with the spec-driven development or when you actually implement the tasks.
- 5:26
And just be careful about giving too much trust. Uh, remember everything in the spec-driven development flow is you, meaning that you are the human in the loop, so to speak.
- 5:38
You need to be the code reviewer of all the code that's generated through this process. You need to be interactively looking at the design documents and the requirements documents that are created because at the end of the day, if something goes wrong, you are the person that are going to be blamed for it, not the agent.
- 5:59
And, uh, that's not to say that we don't use tools to help do code reviews. Someone once told me like, "Are you saying you're the human in the loop?
- 6:06
You do the code review and no one else?" Of course, we might have multiple be doing-- people doing code reviews and definitely use your normal AI coding
- 6:14
Assistance and, and review tools to help you review any pull requests that you create
- 6:20
or CRs. So let me give you a little bit of a history lesson of where we have been, especially at AWS. We, uh, saw this need, especially from our teams and our customers, that they were vibe coding, they were using these coding assistants, but they weren't getting the outputs that they wanted.
- 6:42
And what we saw is this, these customers were using this bespoke pattern of having the agents, the coding assistants create, uh, these full-down requirements documents and these di- design documents.
- 6:55
And we decided to create a application to kind of do this all for them. So we released Kiro, uh, l- earl- late last year in a general availability. It's our new AI IDE coding assistant.
- 7:11
We also have a command line interface or CLI version, which is just as popular. I think right now it's switching. Most people are starting to use CLIs more often than IDEs, so if you like to do that, you can use the CLI.
- 7:25
But what we really focused in on with Kiro is, you can see in these screenshots, is this Vibe and Spec mode. So s- we're gonna jump into Spec mode in a little bit, but we really thought this really encompassed what we were hearing from our customers.
- 7:38
That people wanted more ways to work with larger features and more complex projects, and they really needed the coding assistant to know exactly what their project was doing.
- 7:52
We also released the website at kiro.dev. Feel free to, after this presentation, to go check it out. You can download our CLI, our IDE, and give it a whirl 'cause, uh, you know, we're really proud of it.
- 8:04
It's fun. When we released this, it actually went a little bit viral. We got tens of thousands of downloads. A lot of people were asking us, asking us about Kiro, so we were really happy to, to release this.
- 8:14
And we actually, uh, we... When we set it up in preview, we had so many downloads we had to put a gate in front of it. And then people found ar- around the gate, but now it is publicly available for everyone to try and, and, and give it a shot.
- 8:28
But I don't want this to be, uh, a half-hour pitch for Kiro. You can do this process, spec-driven development, without Kiro, and there's a few, few ways. One is that you, um, basically you have to just...
- 8:41
You could do this manually with anything. You could tell the, your assistant, your large language model to include the following. First is the user requirements. You would tell them, "Please, based on XYZ, create a whole set of user requirements."
- 8:55
Now, you can feed it your own user requirements beforehand and say, "Okay, use this as a basis," or you can have the editor or the AI IDE, uh, go ahead and create it for you.
- 9:07
Then you look back and forth with it, make sure it's okay. Then you tell the assistant to create the design document. Then you look back at that, and then you have it create the implementation details.
- 9:18
These are the, the tasks list, the tasks one by one to actually implement it based on the requirements and the design document you created. So you could do this kind of a manual way if you like.
- 9:30
I'll give a shout-out to Spec Kit. This is GitHub's open source way of doing this process. You can install in a, in a variety of different coding assistants.
- 9:41
Now in Kiro, you have this la... This is the IDE version. We have Plan mode inside the CLI if you prefer the CLI. But in the IDE, you would choose Spec, and then you would go ahead and give it a prompt.
- 9:54
So in this case, I could say like, "Build a movie MCP server to keep track of movies I've watched," or, "Build an, a movie website," whatever you want. Now, you're probably thinking, "Is this spec only good for greenfield brand-new projects?"
- 10:07
And I would say absolutely not. I've seen existing apps that are years old have dozens and dozens of these different spec files in them. In this example, it's kind of more of a greenfield, but you can definitely use it for existing legacy projects as well.
- 10:22
It thinks... It, it works very well. And I would just say that these are really good for when you're doing in-depth features, when you n- your project needs a little more upfront planning, uh, and you just wanna build things in a structured way for-- definitely works really well with complex projects.
- 10:38
We actually added a spec mode for bug fixes too, so you can use it for smaller things, though you may wanna just kinda vibe code those things instead.
- 10:49
Here's what our requirements document looks like. So in the first part, it creates this, uh, requirements phase, where it's in this EARS format, and it gives you the introduction, like the requirements, the user stories.
- 11:01
Uh, we also have a process where it asks you questions beforehand. So we added in some extra question and answer. So as you put your prompt in, it'll ask you some clarifying questions before it creates this requirements phase.
- 11:14
You can also do this quick plan mode we just added which, uh, will go ahead and just generate all these documents quickly for you based on the questions and answers you give.
- 11:23
So there's a lot of different ways you can do this.
- 11:26
Then it'll create a design document, which is a higher level design document. You can also start with the design document first. Some people kind of take this design and requirements, combine them.
- 11:35
But typically with, with our spec-driven deve- development flow, you could either start one or the other. And then you might have Mermaid diagrams here, ASCII art, uh, with all the information.
- 11:45
Now, this is at the point I would highly recommend if you're trying this at home to stop and go in and update it with your knowledge and expertise and taste to exactly what you're looking for.
- 11:56
Because it's only as good as what you put in. But you'll find out that it, even with a smaller prompt it, and with the clarifying questions, it does a pretty good job.
- 12:07
And of course, you always wanna review it for Markdown, the Markdown files for inconsistencies, hallucinations, and errors. And then finally you get to the implementation phase. This will be a list of tasks Uh, it also has something called property-based tests in them, which are tests that are against the requirements document and design document.
- 12:26
You can a- additionally have those created and ran. I would highly recommend it, so that way it makes sure that the, the tasks actually are implemented correctly. Uh, I usually also-- a quick tip here, once it creates this task list, I tell it, "Please take the top four tasks, put them at the top, and create an MVP
- 12:45
for me first." So that way I can actually see it working, and then I'll implement them. I'll implement the MVP version first.
- 12:55
Now, I love Model Context Protocol. I'm not gonna go into exactly all the details of it, but it's a way essentially for your model providers to connect to different data sources.
- 13:05
So in this case, I'm using Kiro, and maybe I'm using, like, OpenAI or Anthropic, and we wanna connect to different data sources. So we have this MCP protocol in the middle, and it connects everything together for us, which is awesome.
- 13:23
Now, I get this question, uh, "Isn't MCP six months old a- and it's dead now?" Now, a lot of people on the internet have opinions that change every other day, and some people were saying that, "Well, you can do a lot of stuff with MCP just with command line tools."
- 13:38
I really think MCP is still maturing. There's a lot, uh, a, a long road ahead for it, especially with some of the security stuff it's doing. I would keep an eye out for MCP, but one of the main reasons I like it, especially for the spec-driven development flow, is you can have something like in Jira or Asana,
- 13:56
all your tickets, all your, uh, large requirements docs, and then you can have it being pulled into your spec-driven development flow when it creates your specs, which makes it much easier to work with.
- 14:08
So if you have a product manager that has actually written a requirements document, you can pull that in.
- 14:16
And, uh, it just makes it a little bit easier, and I'm, I'm talking about any, any kind of project management service and grab technical details for it.
- 14:25
You can also put additional rules in your steering or your AGENTS.md files that tells it, "So if you're using spec-driven development flow, make sure you grab the information out of this MCP server," and that way it knows where to look.
- 14:37
Or you can just specify it in the first step, like, "Hey, look at this MCP server when you create the requirements."
- 14:45
So let me show you a quick demo. This is the latest version of Kiro, the IDE version, and let me give you a, a quick show of it. Now, just for the sake of time, I don't have time to actually go in and create a brand-new project from scratch, but I used this one.
- 15:03
It's a movie database, so this is more of a greenfield brand-new project, but I think you'll still get the idea. I was in the spec mode here. I said, "Please create me a movie website."
- 15:14
So what it did is it started with this design document, and in this case, in this case, I actually told it to start with design instead of requirements. And then this shows the actual preview of the Markdown file.
- 15:27
So you can see it created a bunch of different Mermaid diagrams that show the architecture of it, gives you sequence diagrams. And so I went back and forth with this and updated and edited it, and it created this all for me.
- 15:39
If I scroll down to the bottom of this document it created, you can see here it created a bunch of property testes, tests, and these are really special tests.
- 15:48
It uses FastCheck in this TypeScript in the Node world to do these tests, which actually run dozens, if not hundreds of times with different values to make sure that it's, uh, these requirements are satisfied correctly, which is really nice.
- 16:04
And then it created this requirements document in, once again, this EARS format, so it's really, uh, very simple with these user stories, requirements. Uh, let me see if I can open it up again.
- 16:14
Here's it in preview. Uh, so here's the requirements document. Requirements one, movie data loading. When the application initialize, the filter engine shall load. So it kinda gives you step-by-step exactly what's, uh, what it's doing here.
- 16:29
And then when I went back and forth with this, I got to the task list and I asked it, "Hey, in the task list, can we create like an MVP?"
- 16:35
So it went ahead and updated the task list and even says right here, "Tasks one through four deliver a working MVP, browsable movie grid with search, genre filtering, sorting, and the full '80s synth wave theme."
- 16:47
So it actually redid all the requirements and to get this, uh, basically MVP up and running out of the door, which I really enjoyed. I went ahead and just implemented all of them after that, but you could see how it works.
- 17:01
You can also see it created this property pace, based tests, which are nice, which I can go back in and take a look at the execution. You can also-- let me see if I scroll to the bottom here.
- 17:11
Here it is. So if I just kinda hover, it shows like a little bit of information about the property-based test. Like with property test, test for genre filtering. For any movie dataset, the extracted genres list must contain exactly the sorted set of unique genres.
- 17:26
So it tells me exactly what it did at this point. So if you wanna learn more, you can go to kiro.dev, or you can join our Discord at discord.gg/kiro.dev.
- 17:34
I highly recommend everyone watching check it out and make sure you connect with me on LinkedIn at [REDACTED:username]. Love to just connect with as many people as I can, and also on Bluesky [REDACTED:username] or X.
- 17:45
Thanks.