Claude Code One-Sentence Feature Delivery: A No-Follow-Up Workflow in Practice

Title

Claude Code One-Sentence Feature Delivery: A No-Follow-Up Workflow in Practice

Meta Description

How does Claude Code deliver a feature with a single sentence? This article breaks down a Bilibili creator's no-follow-up workflow: a five-part prompt (context/planning/done criteria/limits), independent Agents for code review and QA, Skills that codify the process, and key details for avoiding AI slop.

Article Content

The speed at which AI writes code has long ceased to be the bottleneck; what's really holding teams back is "how do you prove it wrote it correctly." A practical Claude Code method shared by a Bilibili creator centers on breaking "deliver a feature in one sentence" into verifiable steps, so that the Agent locks down context, acceptance criteria, and boundary conditions before it starts working.

Why throwing a screenshot at the AI produces "AI slop"

A lot of people's daily routine is: take a screenshot, add "clicking the buy button throws an error, fix it."

This looks efficient, but in reality it's making the model fill in the missing information for you. The model doesn't know which element, which file, or which line you mean—it can only guess. If it guesses right, that's luck; if it guesses wrong, you get a pile of code that looks plausible but can't survive review. According to what this creator said in their Bilibili video, this kind of prompt that only gives half the information means "just wait to receive AI slop."

The root of the problem isn't that the model isn't smart enough—it's that it's too smart. So smart that it proactively fills in the blanks you didn't mention, deciding on its own that "the user probably wants this." You never explicitly said "ask me first," so it defaults to "just do it."

AI slop is the community's collective term for AI-generated content that "looks plausible but is actually hollow or wrong." Unlike a direct error or crash, it's often grammatically fluent and structurally complete, yet its logic doesn't hold up to scrutiny and it's disconnected from the real requirement, forcing the reviewer to spend a lot of time distinguishing line by line. In code scenarios, typical manifestations of AI slop include: rewriting an entire component just to "fix" a button, adding dependencies that weren't requested, and swallowing exceptions to make tests go green. Its mechanism is related to the model's autoregressive completion nature—the model tends to generate "the most likely next token" rather than "the code that best matches your intent." When input information is insufficient, it fills the blanks with common patterns from its training data, producing highly templated code that may not fit the current codebase.

Five upfront habits to compress context to minimum noise

Before throwing out that ultimate prompt, the creator first gave five practical suggestions, each of which reduces the Agent's room for guessing.

Speak, don't type. Voice input naturally provides more context than typing—when people speak, they tend to unconsciously add constraints and guardrails, which are exactly the parts they omit when typing out of laziness.

One task per session. When the context window reaches 30% to 40%, model performance starts to decline, and this range happens to be near its capability ceiling. Running multiple tasks together makes tokens balloon quickly and output quality visibly degrades. Once you exceed it, you should compact or just start a new session.

Move coding standards out of CLAUDE.md. This is a pit many people fall into: stuffing lint rules, component conventions, and null checks all into CLAUDE.md, resulting in too many instructions and the Agent starting to skip them. The creator recommends keeping CLAUDE.md to 200–300 lines, leaving lint to ESLint, and putting coding standards elsewhere—Anthropic officially leans in this direction too.

Give the Agent a browser. When working on the frontend, let it actually open the page, perform clicks, and verify results itself, rather than judging "should be fine" by imagination.

If two or three corrections don't fix it, cut your losses and start over. Continuing to pile "try this, try that" into the same session only makes the context dirtier and dirtier. In Claude you can press skip twice to return to an earlier conversation node and restart from the point before the error, starting fresh with the experience of "knowing what not to say."

Context window refers to the total number of tokens a model can hold in a single inference, including the system prompt, conversation history, file contents, and tool return results. It's not "the bigger the better": as used tokens approach the limit, the model's attention to early information gets diluted, producing the "lost in the middle" phenomenon—instructions at the beginning and end are remembered clearly, while mid-section content tends to be ignored. The 30%–40% performance inflection point observed in practice is related to attention resource allocation and the distribution of long-context training. Compact is a context-compression operation provided by tools like Claude Code, which summarizes the conversation history into a shorter summary before continuing, to free up window space; but it is lossy, and key details may be lost in compression, so the safer approach remains "one task per session," proactively starting a new session before exceeding the limit.

The five components of the ultimate prompt

The creator breaks that "one-sentence delivery" prompt into five parts: context, planning, done criteria, check and limits.

Context: pinpoint, not full-screen screenshots

When fixing a bug, give the file name or approximate location; when building a feature, give a similar existing feature or target file for reference; if there's a real error, paste the error; if you have a screenshot, paste the screenshot. The key is that screenshots should be partial rather than full-screen—a full-screen screenshot makes the Agent repeatedly guess among ten possible locations.

His own solution is a Chrome extension: click the target element and directly get the selector, text content, React component name, and the component's path and line number in the codebase, feeding all of it to the Agent along with the screenshot. This completely eliminates the guess of "which file is this text actually in."

Selector is a CSS selector, used to uniquely identify an element in the DOM, such as button#buy-now or [data-testid="purchase"]. Providing the Agent with a selector rather than "that buy button" turns "element locating"—the most error-prone step—from model guessing into deterministic input. In React projects, a selector alone isn't enough—the same button may come from a shared component, and the real modification point is in the component source rather than its usage site. Therefore providing the React component name along with the file path and line number lets the Agent jump directly to the definition, avoiding repeated probing among multiple call sites. Chrome DevTools' Elements panel and React DevTools' Components panel can both help obtain this information, which is exactly the step the creator's self-built Chrome extension automates.

Explore first, then act

When fixing a bug, don't tell the Agent to just "go fix it"—instead require it to: reproduce first, then trace back, and write everything it learns into a file. Specifically, have it add console logs to trace where the bug comes from, forming a complete stack trace, without writing any fix code during this period. For features, similarly, have it first read the target file and related routes, figure out how components mount, how API calls are managed, and how state flows, building a "knowledge graph" of this screen.

Also explicitly require "planning for every click"—every handler, every state change, every API call recorded in a file. Up to this point there isn't a single line of code, but if the plan is wrong you only need to change one file; if the code is wrong you have to go back and forth.

Done Criteria: define acceptance before starting

The first prompt should clearly state "what the behavior should be after the fix" or "what operations I'll be able to perform once the feature ships." The Agent will self-check against these criteria and only mark the task complete after passing. Accompanying hard requirements include: add console logs at every step to confirm behavior matches expectations; don't work based on theory or assumptions—the creator says they learned the phrases "I assumed" and "worked on theory" from the Agent, and now explicitly forbids both every time; finally, deliver evidence: screenshots, screen recordings, test results.

Limits: explicitly state what cannot be done

No introducing new libraries, no changing public APIs, no modifying tests to make them pass, don't suppress errors but solve the root cause. And an instruction the creator calls "a must-add": ensure there are no regressions. Hand the staging or production URL to the Agent as the source of truth, and after the task is complete, compare whether local and online results match.

Code review and QA must use a different Agent

The main Agent should never review its own code. The creator's explanation is preference bias—the Agent tends to believe its own work is correct, and even when it's wrong, it will tell you it's fine.

The correct approach is three stages: after the main Agent finishes implementation, spin up an independent reviewer Agent to review item by item against the coding standards; after review passes, spin up an independent QA Agent to run through various test cases and give a go / no go conclusion. Lessons discovered during review and QA should be distilled into a learning file and fed to the main Agent in advance next time, to avoid repeating the same pitfalls.

Preference bias in LLM review scenarios manifests as: when the model scores output it just generated, it tends to give higher evaluations, even when the output has obvious flaws. This is similar to human self-serving bias, but the cause is different—during review the model can see its own previous reasoning traces, and these traces become additional grounds for "rationalizing" the current answer, forming a self-reinforcing loop. Mitigation measures include: using an independent session or independent Agent for review, cutting off the visibility of reasoning traces; providing the reviewer with a different system prompt from the implementer, explicitly defining its "find faults" role; and requiring review conclusions to carry specific evidence (files, line numbers, reproduction steps) rather than a vague "looks fine." The three-stage division (implementation—review—QA) is exactly the result of institutionalizing these measures.

Codify the process into Skills and Agents

Writing that long string of prompts repeatedly isn't realistic, so the creator turned the whole process into skills and agents in an open-source repository. Taking the fix bug skill as an example, the steps are fixed as: check input (if files or routes are missing, ask the user to supply them) → build the graph and reproduce (add console logs, produce learning) → surgical fix (surgically, only change what should be changed, no casually optimizing that button next to it) → verify on a clean worktree → review, QA, and output a fixed-format report. The build skill also has an interesting step 0.5, "compare against the oracle," i.e., comparing against the original source of truth—the online URL or the original branch—to verify the result.

To invoke it, you only need one sentence:

fix this bug, located at xxx, here's the context, use the bug fixer agent to handle it.

Planning, checks, and limits are all handled by the skill; the user only needs to provide done criteria—because each project's acceptance criteria differ, this part cannot be built in.

This method isn't universal. The creator also notes that if you're just exploring casually, fixing a small bug, and you yourself can't articulate what the done criteria are, then this structured prompt won't help and just diving in is faster. It's really suited for scenarios with real users, where changes go into production and you need to deliver confidence to a reviewer.

Key points recap

The underlying logic of the whole workflow is a role shift: you're no longer "the person making requests," but "the person defining acceptance criteria and quality boundaries." The Agent is responsible for exploring, planning, implementing, and self-verifying; you're responsible for clearly stating what counts as done, what must not be touched, and ultimately what evidence speaks for the result.

One-line Summary

Break "deliver a feature in one sentence" into verifiable steps, using structured prompts and independent review to make AI-written code provably correct.

Paragraph Summary

The article introduces a practical Claude Code method shared by a Bilibili creator, pointing out that AI coding speed is no longer the bottleneck—the real challenge is proving the code is correct. Throwing a screenshot plus "fix it" makes the model fill in missing information itself, producing AI slop that can't survive review. The author proposes five upfront habits to reduce context noise: use voice input more, one task per session, move coding standards out of CLAUDE.md, give the Agent a browser, and cut losses and restart if two or three corrections don't work. The core is an ultimate prompt composed of five parts—context, planning, done criteria, limits, check—requiring the Agent to explore and reproduce first, write a plan file, lock down acceptance criteria before starting, explicitly state prohibitions, and deliver evidence. Review and QA must be done by independent Agents to avoid preference bias, and the whole process can be codified into skills and agents for reuse.