Align prose with STYLE.md across modules 01-07 and top-level README
Replace residual em-dashes, arrow-notation shorthand, and a handful of filler intensifiers; fix two small typos. Add .gitignore to keep the working CHANGES.md audit out of the repo. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
parent
d2ca02bd90
commit
4194680475
9 changed files with 102 additions and 82 deletions
|
|
@ -4,9 +4,9 @@
|
|||
|
||||
A chat is at its best when you treat it as a *conversation*, not a search bar. Multi-turn discussions that include design tradeoffs, exploring an unfamiliar library, or talking through a problem that you can't quite articulate are where conversational interactions are a better approach than single-shot edits or fire-and-forget agents.
|
||||
|
||||
The patterns in this section apply in two areas: the **in-project chat** panel inside your editor or CLI (Claude Code's panel, Cursor's chat, Continue.dev's panel) and a **web chat** in a browser tab (ChatGPT, Claude.ai, Gemini). While web chat is where most of us get our start with AI tools, you should probably default to the in-project chat, since it can see your files and edit them, while stepping out to a web chat only when the discussion does not belong in the project (it includes sensitive content, non-code context, or a record you want to share with collaborators). The skill is steering the conversation so it stays useful.
|
||||
The patterns in this section apply in two areas: the **in-project chat** panel inside your editor or CLI (Claude Code's panel, Cursor's chat, Continue.dev's panel) and a **web chat** in a browser tab (ChatGPT, Claude.ai, Gemini). While web chat is where most of us get our start with AI tools, you should probably default to the in-project chat, since it can see your files and edit them, while stepping out to a web chat only when the discussion does not belong in the project (it includes sensitive content, non-code context, or a record you want to share with collaborators). The main skill to develop is steering the conversation so it stays useful.
|
||||
|
||||
Another way to think about a chat with a capable model is as a kind of programming in natural language. In the chat, you specify what you want, the model executes, you observe the output, and you refine the specification. Effective programming skills, including clarity, decomposition, anticipating ambiguity, and iterating, are the same ones that make a chat user effective. Until LLMs, natural language was almost never an executable specification, and this is one of the more remarkable shifts the technology has produced. This very shift explains why "prompt engineering" became a buzzword. It's not magic words or incantations, it's specification quality.
|
||||
Another way to think about a chat with a capable model is as a kind of programming in *natural language*. In the chat, you specify what you want, the model executes, you observe the output, and you refine the specification. Effective programming skills, including clarity, decomposition, anticipating ambiguity, and iterating, are the same ones that make a chat user effective. Until LLMs, natural language was almost never an executable specification, and this is one of the more remarkable shifts the technology has produced. This very shift explains why "prompt engineering" became a buzzword. It's not magic words or incantations that matter, it's the specification quality.
|
||||
|
||||
## Key goals
|
||||
|
||||
|
|
@ -27,7 +27,7 @@ The heuristic in [section 01](../01-two-worlds/) tells you to reach for chat whe
|
|||
- **Talking through a problem you can't quite name.** *"Something feels wrong about this architecture but I can't put my finger on it. Here's the structure..."* The act of describing it often clarifies your own thinking, and the model's questions back can probe weak spots.
|
||||
- **Learning a new domain or library.** Conversations let you ask the dumb questions you'd be embarrassed to ask a colleague.
|
||||
|
||||
If you find yourself wanting the model to *produce a specific edit*, you have drifted out of pure conversation territory. In an in-project chat, though, that drift is basically harmless. The same panel can just go make the edit, and you are now in an agentic interaction mode ([section 05](../05-agentic-workflow/)). In a web chat, though, the same drift is relatively expensive because you have to copy-paste the result back. If the conversation looks like it's heading toward edits, select the in-project chat from the start!
|
||||
If you find yourself wanting the model to *produce a specific edit*, you have drifted out of pure conversation territory. In an in-project chat, though, that drift is harmless. The same panel can just go make the edit, and you are now in an agentic interaction mode ([section 05](../05-agentic-workflow/)). In a web chat, though, the same drift is relatively expensive because you have to copy-paste the result back. If the conversation looks like it's heading toward edits, select the in-project chat from the start!
|
||||
|
||||
|
||||
## In-project chat versus web chat: when to step out
|
||||
|
|
@ -86,7 +86,7 @@ Conversations accumulate context that can both help and hurt. Start a new chat w
|
|||
- **The conversation went sideways early.** If the model misunderstood your first message and the next several turns were spent correcting course, the corrected understanding is buried under that wrong understanding. A fresh start with a better first message is often faster.
|
||||
- **The chat has become long enough that important details from early turns are out of recent attention.** Most chat interfaces handle this gracefully, but very long chats can have the model "forget" something you said ten turns ago. Restating it in a fresh chat is sometimes easier than fighting it in the existing one.
|
||||
|
||||
There is no virtue in keeping a chat going longer than it needs to. Open a new one freely. Conversations are cheap. When you're deciding "should I keep this conversation going or start fresh?" you should be biased toward starting fresh.
|
||||
There is no virtue in keeping a chat going longer than it needs to. Open a new one freely (in Claude Code, the `/clear` command; in ChatGPT or Claude.ai, the *New chat* button in the sidebar; in Cursor, the *+* at the top of the chat panel). Conversations are cheap. When you're deciding "should I keep this conversation going or start fresh?" you should be biased toward starting fresh.
|
||||
|
||||
|
||||
## Carrying context across sessions
|
||||
|
|
@ -102,14 +102,14 @@ The web-chat equivalent is your account history, where the *conversation itself*
|
|||
|
||||
## Patterns that work
|
||||
|
||||
- **Compare and contrast.** *"What are the practical differences between pandas `merge` and `join`? When would I one or the other?"* Models are good at structured comparisons.
|
||||
- **Compare and contrast.** *"What are the practical differences between pandas `merge` and `join`? When would I use one or the other?"* Models are good at structured comparisons.
|
||||
- **Devil's advocate.** *"I'm planning to use approach X. What would make that a bad choice? What's the strongest argument against it?"* Inverts the default "let me help you do what you said" tendency.
|
||||
- **Explain to a target audience.** *"Explain finite-volume methods to me as if I have a strong finite-difference background but no CFD experience."* The audience framing tightens the level of abstraction: the model can skip discretization basics and focus on what's actually new (flux conservation across control volumes, dealing with unstructured meshes).
|
||||
- **Critique my draft.** *"Here is my approach / commit message / README. What's confusing or weak?"* Models are surprisingly useful as a first-pass reviewer.
|
||||
- **Walk me through.** *"Walk me through what happens when I call `requests.get(...)`. Don't skip the boring parts."* Good for building mental models of libraries you use but don't fully understand.
|
||||
- **Iterate on the prompt itself.** *"What would I have to add to my question to get a better answer?"* or *"Help me rewrite this prompt to be more specific."* The model is often perceptive about its own failure modes, and the resulting prompt is sharper than what you started with. Especially valuable when you are crafting a prompt you will reuse, such as a template, a system prompt, or an agent's instruction.
|
||||
|
||||
## Patterns that don't
|
||||
## Patterns that don't work well
|
||||
|
||||
- **Asking for "the best" with no criteria.** *"What's the best Python plotting library?"* gets you a generic matplotlib-vs-seaborn-vs-plotly survey. Add criteria like *"for publication-quality figures with mathematical annotations, where I need fine control over axes and tick formatting"* and the answer becomes more useful.
|
||||
- **Long preamble before the question.** Models read top-down, but the actual question is what they answer. If you bury it in paragraph three, the model may answer paragraph one.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue