00:00:00 You already know the two things that Scope sets up for our project.
00:00:04 The build approach, which decides how the work gets sliced and the workflow tier, Which decides, how much verification does each feature need before it
00:00:16 can be called finished.
00:00:17 So now let me show you both on a real demo project, once again, you can run this in your CLI, if you'd like to, just by running Claude and then starting
00:00:27 to type right here.
00:00:28 Or you can do it through a VS Code extension by heading right here and searching for Claude.
00:00:36 Or once again, you could use absolutely any agentic system to continue developing using this workflow.
00:00:44 So in this case, I'll press command shift P, which is how I typically open up a new cloud code window, Which brings it into focus and gives me the full
00:00:53 screen to focus on it.
00:00:54 In the future, there might be all sorts of different ways to continue developing apps with agents.
00:01:00 I know that the file tree is getting replaced and moved aside.
00:01:05 Cursor does it differently.
00:01:07 Windsurf does a differently, but the part that matters the most is that workflow stays the same.
00:01:12 I'm sure that you can adapt to the UI.
00:01:14 So right here, let's scope our project.
00:01:18 We're beginning on something completely new.
00:01:20 Just created a new folder called agenticengineering and we're ready to begin with using the scope skill.
00:01:28 I'll say something like scope, build a client feedback app where I share a link.
00:01:37 The client pins comments to a live preview and I manage them from a dashboard.
00:01:46 It's a pretty neat little application that allows you to collect feedback from your clients through directly pinned comments to a live preview.
00:01:54 And then you can see them in a single place.
00:01:57 So that single sentence is all that scope gets to begin with.
00:02:01 But it doesn't necessarily have to be a single sentence.
00:02:05 If you know more about what you want to build, you can immediately just brain dump it all there.
00:02:11 Or if a client has given you a brief about the app, You can pass that full brief right here.
00:02:16 The more the scope skill has to work with, the better the output will be.
00:02:20 But even if you just pass a simple sentence, it'll guide you to turn this into an enterprise product if that's what want it to.
00:02:27 So let's run it.
00:02:28 And now notice what it'll do next.
00:02:30 It'll read a couple of files, such as first it figured out that this is a greenfield project, meaning that we are starting from scratch.
00:02:38 Then it will read the scope template.
00:02:41 Again, remember, from the skill module, it only loads in what is needs.
00:02:45 and now it knows.
00:02:47 It'll plan from scratch and then it'll proceed to give us a few rounds of questions first and only then will it write the plan.
00:02:54 The questions will arrive in small batches, each one giving you real choices and the recommended answer.
00:03:02 it doesn't leave you staring at an empty box trying to design the whole product yourself.
00:03:06 t has already inferred what your original sentence made clear, that there are users, projects, previews, comments.
00:03:14 So it doesn't waste time asking whether those things exist.
00:03:18 It asks only about what the idea could not possibly tell.
00:03:22 The first question is about the MVP.
00:03:25 What is the smallest version that still delivers the core value?
00:03:29 This is an incredibly important question because if we don't set some constraints or if say what is out of scope, we'll just continue adding new features endlessly.
00:03:39 And that's not the goal.
00:03:40 The goal is to have something deliverable and testable first to verify the idea and then move on.
00:03:45 So we can either have one project pin and resolve.
00:03:49 We can have pin thread and notify, or we have the full review round open in progress, fixed, won't fixed with screenshots,
00:03:57 browsers, and screen size captured and client approval of round.
00:04:02 Or you can select the other option and type whatever you want.
00:04:05 Each answer changes the product, which is exactly why none of them should be left to the agent to decide halfway through the code.
00:04:12 In this case, the first thing actually matches our MVP.
00:04:16 We create a project with the preview target, share the link, decline drop spin comments, we see them in the dashboard and mark them as resolved.
00:04:24 The second question is, what exactly is the client pinning comments onto?
00:04:29 Is it a live site in a frame?
00:04:31 Like if we paste the URL, the app loads that page inside a framework with a comment layer on top.
00:04:37 Works for any URL I can already load with no code added to the clients site.
00:04:42 Yep, that works.
00:04:43 And then it reaches the question that most developers don't even think about until the launch.
00:04:49 How does a client open a shared project without an account?
00:04:54 And if access comes from the URL, what stops the wrong person from opening it too?
00:04:59 It's not a small implementation detail, but an access decision.
00:05:04 And the scope skill surfaced it right away, while changing the answer is still cheap, rather than three weeks later when the assumption is already spread
00:05:13 across routes, databases, tables, and UI.
00:05:16 So in this case, we can proceed with a secret link without login for now, so that anyone with the link in comment, they just type a name once.
00:05:24 This poses a lowest friction for clients, which is the whole point of the product.
00:05:29 And then the Link can be revoked.
00:05:32 As for the money, is that part of the build?
00:05:34 And a very important question, are we planning on monetizing it yet?
00:05:38 If you're building something that you'd want to turn into a SaaS, you can definitely start with billing, but I rather prefer to provide value immediately
00:05:47 without charging for it first.
00:05:48 And then only when people actually use it for free, then we can maybe start thinking about charging.
00:05:54 But for now, it doesn't include billing yet.
00:05:57 Then you submit the first round of answers.
00:06:00 The second round of questions is in, which capabilities are in this first build pass?
00:06:05 Pick all that are, leave the rest deferred.
00:06:08 So you can see you don't only have radio buttons, but check boxes as well.
00:06:13 My own sign-in is here because we need an account so projects and comments can belong to a specific person.
00:06:19 Email notifications, maybe not yet.
00:06:23 Live updates.
00:06:25 Don't have to be live.
00:06:26 Once the client leaves the messages, they can just send us an email and we can go ahead and check them out.
00:06:31 And then image attachments on comments.
00:06:34 I think this is going to useful in case they want to provide an alternative design for a specific section.
00:06:39 When it comes to the notify, how do I found out a client left a comment?
00:06:43 Dashboard badge only.
00:06:45 Which cross-cutting concerns should be in the plan from day one?
00:06:48 Ear monitoring.
00:06:50 Well, maybe we could add that later.
00:06:52 Public marketing page with SEO.
00:06:54 Sure, we can go ahead and do that.
00:06:57 Product analytics, accessibility, not yet.
00:07:00 And then it asks us how much rigor do we want by default?
00:07:07 And this decision matters because it can slow down the build process as you're exchanging that extra time for the extra level of testing,
00:07:15 verification, and review.
00:07:17 So you can choose from a real product with normal rigor where we first prove each feature works in the app and then add tests on the load bearing parts,
00:07:25 or we can skip the tests.
00:07:27 We can build it as a quick prototype with no verification stages and heavy team grade where it does everything.
00:07:35 In this case, I'll say that this is a real product.
00:07:38 And next comes the choice that changes the shape of the entire plan.
00:07:43 How should this product be sliced?
00:07:45 There are four different approaches, and Scope will recommend one based on the kind of risk hidden inside of idea.
00:07:54 For this application, it recommends the tracer bullet, one thin path through the complete system.
00:08:01 A client opens a link, they see the live preview, the pin one comment, and that comment appears on your dashboard.
00:08:09 It doesn't try to finish every screen or every comment state and every dashboard tool first, but rather, it proves the central promise of the product from
00:08:20 end to end before anything around it becomes wider.
00:08:24 And it provides an honest reason.
00:08:26 It's recommended because the risky part here is a pin surviving the round trip from a frame page to your dashboard.
00:08:34 If that interaction doesn't work, the rest of the product barely matters.
00:08:39 So Scope builds through that uncertainty first and then retires that risk early.
00:08:45 That's Tracer Bullet.
00:08:46 And it's a real engineering principle, so you can Google it.
00:08:50 But not just Tracer Bullet, as that's the type of an actual bullet, but rather just add software to it.
00:08:57 And you'll see that Trace Your Bullet development is a software engineering method that builds a thin functional end-to-end slice of a system to test the architecture,
00:09:06 get early feedback, and reduce risk.
00:09:09 Popularized by the book, The Pragmatic Programmer.
00:09:13 The other approaches are built for different bets.
00:09:16 Skidboard creates the smallest usable version of the whole product.
00:09:20 It fits when the main question is whether anybody wants the idea at all.
00:09:25 Journey completes the entire user path, including every state, before starting another.
00:09:31 And Facade builds the screens against fake data first.
00:09:36 And this fits when the experience needs to be seen, tested and approved before you invest in the backend underneath it.
00:09:44 All four can be right.
00:09:45 But for this product, the core interaction is the risk.
00:09:49 So Tracer Bullet is right shape.
00:09:52 And check this out, as we learned in the skills module, only now, once we selected the approach, it actually read the tracer bullet MD file.
00:10:02 So if you want to get a bit more behind the scenes of this specific skill, the skill is here.
00:10:07 It went into the approaches and then went to this tracer bullet files in which we then explained in more detail how the tracers bullet works and what the
00:10:18 goal is.
00:10:18 Now, another question that it will ask you is about the references.
00:10:22 This will be useful later on once we start architecting the tech stack where it'll be able to pull the new references from the internet on the latest versions
00:10:31 of specific technologies and more.
00:10:33 But for now, we can say no references, keep it clean.
00:10:36 The scope itself doesn't depend on anything else.
00:10:39 It is the idea that we are building.
00:10:42 Also, I want to point out the fact that for you, most likely, some of these questions will be different.
00:10:48 Agentic development is non-deterministic, meaning that you will never get the same questions.
00:10:53 So for example, when it asked me about whether this is a real project or a demo, it might have used the term beta for your.
00:11:01 like we're building a beta project first, and that includes the testing and verification.
00:11:05 And it likely didn't recommend GA approach, general availability, because there are no payments, regulatory requirements,
00:11:13 or some other big systems.
00:11:14 But an important thing to keep in mind is that whichever verification tier you chose, doesn't mean that you need to use it for every feature equally.
00:11:23 A specific feature is simple, so it might just follow a prototype or alpha rules on the rigor tier.
00:11:29 Or maybe some features are super detailed so you want to immediately pretend that your shipping the project or that it's already out.
00:11:35 What this essentially is, is just a choice on what it'll recommend you to run after each feature.
00:11:41 Like after develop, if you just chose prototype, it will say that's good, its already developed, you have the prototype.
00:11:47 But if you're running it in alpha, it'll also recommend to check, verify the code that you wrote.
00:11:52 Or if it's in beta, It'll will also recommended to test it on top of it.
00:11:56 And GA actually adds a fresh model to review what the initial model wrote and it documents the features.
00:12:04 So it is just different levels of attention to detail that do you want to have with your project.
00:12:08 Each one adds that additional layer of testing, review, and more, but it also slows down the development.
00:12:15 So it's up to you to choose, do you want to be closer to speed or closer, to full enterprise testing for example.
00:12:21 But yeah, the scope plan is now done.
00:12:24 A client feedback app where a shared link lets a client pin comments onto a live page.
00:12:29 We just entered a single sentence into the Scope skill.
00:12:33 answered a couple of questions and we got back 10 features planned, 14 deferred build tracer approach, and the workflow is chosen as beta.
00:12:43 The next step is to clear it and then to architect the stack and architecture of the application.
00:12:49 But this piece of text isn't the only thing that it generated.
00:12:52 Scope wrote its entire plan into a single file.
00:12:56 Docs scope scope.md.
00:12:59 You can open it by clicking right here, or you can check it right under your folder, docs scope.
00:13:06 And I installed this marked on pre-order extension on VS code so that when I press command shift V, it just opens it up in a preview.
00:13:13 So it's a bit easier on the eye.
00:13:15 Now, at the top, you can see the whole project at a glance.
00:13:19 Foundations, thin threads, features that follow, and the current state of each one.
00:13:25 Now check it out for a second, like on the part where it says data model or the core review loop.
00:13:31 No where, it mentions library names because these are architectural decisions and architectural decision belong to the architect skill and not the project plan.
00:13:43 The scope just records what the product needs without pretending that the technical answer has already been chosen.
00:13:51 And this is what keeps the plan from becoming stale the first time a library is replaced.
00:13:56 Because tools can change, but the products still needs accounts, comments, access controls, previews, and a dashboard.
00:14:05 From this point onward, the next action is never hidden.
00:14:09 It is always just the first unchecked.
00:14:12 And from this point onward, the next action is never hidden.
00:14:16 It's always the 1st uncheck box.
00:14:19 it is up to us to decide the stack and scaffold a runnable project so every later slice builds on real structure instead of a guess.
00:14:27 The frame preview and the secret link both push on this choice so it's made once, deliberately, and written down.
00:14:34 And by the way, what you've just seen was a green field run inside of an empty repository.
00:14:40 But as you might already know, Scope adapts to the kind of project that it enters.
00:14:45 You simply enter through a different door.
00:14:47 If you run the scope with an idea, like what we just did, Then this is a green field project where it decomposes the whole MVP from scratch with foundations first.
00:14:58 It tells you that we need to make all the choices from stack and architecture to coding standards and tool to the data model,
00:15:04 design system, and then the slices.
00:15:08 But for an existing code base, you would run the audit skill first that'll give the workflow, the real stack commands, structure and conventions of the
00:15:18 repository before planning anything new.
00:15:21 then you would go back and run the scope skill.
00:15:24 But this time, it will figure out that this is an already existing brownfield project, so it'll record what already exists as existing work and then plan
00:15:35 the new slices on top of the reality instead of just pretending that the project begins today.
00:15:41 That is the workflow that we'll explore properly in the next module.
00:15:45 Oh, and it even works in a monorepo.
00:15:48 You run Scope from the workspace you're changing and the plan and specifications remain local to that workspace.
00:15:54 It doesn't assume that one feature should reshape unrelated applications elsewhere in their repository.
00:16:00 And if a project already has a plan, new features appear halfway through the build, you can run scope with just one single feature idea.
00:16:09 and it'll add the new work in the correct place without tearing apart and recreating the whole plan.
00:16:15 Or if you return to the project after shipping something, clearing the session, or simply forgetting where you stopped, you can run Scope without any arguments.
00:16:25 It'll just read the repository and compare the plan with what actually shipped.
00:16:30 It'll update the current state and tells you what comes next.
00:16:34 So in simple terms, Scope decides what should be built and when.
00:16:40 And that plan is shaped around the project's biggest uncertainty.
00:16:44 It survives a cleared session, remains available to every developer working within a team alongside you and every agent working on the code base too.
00:16:53 and it also reconciles itself with the reality when you run it again.
00:16:58 Later on, you'll see how this scope file keeps updating itself as we actually develop the features.
00:17:04 So, quickly put, scope has turned a single sentence into an ordered project plan.
00:17:11 It asked about the things that the idea could not answer.
00:17:14 it chose how the work should be sliced, it set how much verification the project needs, and it raised the riskier feature above the default.
00:17:24 It also recorded that first decision that must exist before development can begin.
00:17:29 But before any feature can be built, the project still needs a stack, a framework, and a database.
00:17:36 Those are the largest technical decisions on the board.
00:17:40 So next, you're an architect.
