docs(guidelines): close with asks the reader can act on alone

.clinerules/karpathy-skills.md

@@ -25,6 +25,8 @@ Before implementing:
 
 **Ambiguity check — confirm before you build.** Before committing to anything non-trivial, prove you read it the same way the user meant it: give **three concrete examples of what the result will do — including at least one edge case** — and confirm they're right. Worked examples expose a misread that abstract restating hides; an example that forks into "well, it depends" is a question to resolve now, not a guess to make. Cheap to confirm up front, expensive to discover after you've built the wrong thing.
 
+**Close with asks the reader can act on alone.** Readers skim to the last block of a long message, so every ask, decision, or next step there names its PR, link, file, or command and says whether it exists yet. Never write "the link", "it", or "as above" for an item the reader has to act on: they never saw what it points to, and asking back costs a round-trip the sentence would have saved.
+
 **Map the usage surface — a feature is more than the flow in the prompt.** The same capability is reached from different entry points, at different moments, by different actors: configured inline mid-flow *and* opened on its own later just to change or turn it off; triggered by the user *and* by the system. An agent turn is framed around one focused task, so the feature quietly gets welded to the single flow the request described — an auto-topup setting built as if it only exists inside the "choose topup amount" flow, when updating those settings is its own session with its own entry point. Before building, enumerate the distinct usages and give each a place in the design (the data model and the seams, not necessarily the code); then build only what was asked (§2) and **name the usages you're leaving out** — a variation surfaced is a decision on the table, a variation missed is a discovery in production.
 
 ## 2. Simplicity First

.cursor/rules/karpathy-skills.mdc

@@ -31,6 +31,8 @@ Before implementing:
 
 **Ambiguity check — confirm before you build.** Before committing to anything non-trivial, prove you read it the same way the user meant it: give **three concrete examples of what the result will do — including at least one edge case** — and confirm they're right. Worked examples expose a misread that abstract restating hides; an example that forks into "well, it depends" is a question to resolve now, not a guess to make. Cheap to confirm up front, expensive to discover after you've built the wrong thing.
 
+**Close with asks the reader can act on alone.** Readers skim to the last block of a long message, so every ask, decision, or next step there names its PR, link, file, or command and says whether it exists yet. Never write "the link", "it", or "as above" for an item the reader has to act on: they never saw what it points to, and asking back costs a round-trip the sentence would have saved.
+
 **Map the usage surface — a feature is more than the flow in the prompt.** The same capability is reached from different entry points, at different moments, by different actors: configured inline mid-flow *and* opened on its own later just to change or turn it off; triggered by the user *and* by the system. An agent turn is framed around one focused task, so the feature quietly gets welded to the single flow the request described — an auto-topup setting built as if it only exists inside the "choose topup amount" flow, when updating those settings is its own session with its own entry point. Before building, enumerate the distinct usages and give each a place in the design (the data model and the seams, not necessarily the code); then build only what was asked (§2) and **name the usages you're leaving out** — a variation surfaced is a decision on the table, a variation missed is a discovery in production.
 
 ## 2. Simplicity First

.github/copilot-instructions.md

@@ -25,6 +25,8 @@ Before implementing:
 
 **Ambiguity check — confirm before you build.** Before committing to anything non-trivial, prove you read it the same way the user meant it: give **three concrete examples of what the result will do — including at least one edge case** — and confirm they're right. Worked examples expose a misread that abstract restating hides; an example that forks into "well, it depends" is a question to resolve now, not a guess to make. Cheap to confirm up front, expensive to discover after you've built the wrong thing.
 
+**Close with asks the reader can act on alone.** Readers skim to the last block of a long message, so every ask, decision, or next step there names its PR, link, file, or command and says whether it exists yet. Never write "the link", "it", or "as above" for an item the reader has to act on: they never saw what it points to, and asking back costs a round-trip the sentence would have saved.
+
 **Map the usage surface — a feature is more than the flow in the prompt.** The same capability is reached from different entry points, at different moments, by different actors: configured inline mid-flow *and* opened on its own later just to change or turn it off; triggered by the user *and* by the system. An agent turn is framed around one focused task, so the feature quietly gets welded to the single flow the request described — an auto-topup setting built as if it only exists inside the "choose topup amount" flow, when updating those settings is its own session with its own entry point. Before building, enumerate the distinct usages and give each a place in the design (the data model and the seams, not necessarily the code); then build only what was asked (§2) and **name the usages you're leaving out** — a variation surfaced is a decision on the table, a variation missed is a discovery in production.
 
 ## 2. Simplicity First

.windsurf/rules/karpathy-skills.md

@@ -25,6 +25,8 @@ Before implementing:
 
 **Ambiguity check — confirm before you build.** Before committing to anything non-trivial, prove you read it the same way the user meant it: give **three concrete examples of what the result will do — including at least one edge case** — and confirm they're right. Worked examples expose a misread that abstract restating hides; an example that forks into "well, it depends" is a question to resolve now, not a guess to make. Cheap to confirm up front, expensive to discover after you've built the wrong thing.
 
+**Close with asks the reader can act on alone.** Readers skim to the last block of a long message, so every ask, decision, or next step there names its PR, link, file, or command and says whether it exists yet. Never write "the link", "it", or "as above" for an item the reader has to act on: they never saw what it points to, and asking back costs a round-trip the sentence would have saved.
+
 **Map the usage surface — a feature is more than the flow in the prompt.** The same capability is reached from different entry points, at different moments, by different actors: configured inline mid-flow *and* opened on its own later just to change or turn it off; triggered by the user *and* by the system. An agent turn is framed around one focused task, so the feature quietly gets welded to the single flow the request described — an auto-topup setting built as if it only exists inside the "choose topup amount" flow, when updating those settings is its own session with its own entry point. Before building, enumerate the distinct usages and give each a place in the design (the data model and the seams, not necessarily the code); then build only what was asked (§2) and **name the usages you're leaving out** — a variation surfaced is a decision on the table, a variation missed is a discovery in production.
 
 ## 2. Simplicity First

AGENTS.md

@@ -25,6 +25,8 @@ Before implementing:
 
 **Ambiguity check — confirm before you build.** Before committing to anything non-trivial, prove you read it the same way the user meant it: give **three concrete examples of what the result will do — including at least one edge case** — and confirm they're right. Worked examples expose a misread that abstract restating hides; an example that forks into "well, it depends" is a question to resolve now, not a guess to make. Cheap to confirm up front, expensive to discover after you've built the wrong thing.
 
+**Close with asks the reader can act on alone.** Readers skim to the last block of a long message, so every ask, decision, or next step there names its PR, link, file, or command and says whether it exists yet. Never write "the link", "it", or "as above" for an item the reader has to act on: they never saw what it points to, and asking back costs a round-trip the sentence would have saved.
+
 **Map the usage surface — a feature is more than the flow in the prompt.** The same capability is reached from different entry points, at different moments, by different actors: configured inline mid-flow *and* opened on its own later just to change or turn it off; triggered by the user *and* by the system. An agent turn is framed around one focused task, so the feature quietly gets welded to the single flow the request described — an auto-topup setting built as if it only exists inside the "choose topup amount" flow, when updating those settings is its own session with its own entry point. Before building, enumerate the distinct usages and give each a place in the design (the data model and the seams, not necessarily the code); then build only what was asked (§2) and **name the usages you're leaving out** — a variation surfaced is a decision on the table, a variation missed is a discovery in production.
 
 ## 2. Simplicity First

CLAUDE.md

@@ -23,6 +23,8 @@ Before implementing:
 
 **Ambiguity check — confirm before you build.** Before committing to anything non-trivial, prove you read it the same way the user meant it: give **three concrete examples of what the result will do — including at least one edge case** — and confirm they're right. Worked examples expose a misread that abstract restating hides; an example that forks into "well, it depends" is a question to resolve now, not a guess to make. Cheap to confirm up front, expensive to discover after you've built the wrong thing.
 
+**Close with asks the reader can act on alone.** Readers skim to the last block of a long message, so every ask, decision, or next step there names its PR, link, file, or command and says whether it exists yet. Never write "the link", "it", or "as above" for an item the reader has to act on: they never saw what it points to, and asking back costs a round-trip the sentence would have saved.
+
 **Map the usage surface — a feature is more than the flow in the prompt.** The same capability is reached from different entry points, at different moments, by different actors: configured inline mid-flow *and* opened on its own later just to change or turn it off; triggered by the user *and* by the system. An agent turn is framed around one focused task, so the feature quietly gets welded to the single flow the request described — an auto-topup setting built as if it only exists inside the "choose topup amount" flow, when updating those settings is its own session with its own entry point. Before building, enumerate the distinct usages and give each a place in the design (the data model and the seams, not necessarily the code); then build only what was asked (§2) and **name the usages you're leaving out** — a variation surfaced is a decision on the table, a variation missed is a discovery in production.
 
 ## 2. Simplicity First

GEMINI.md

@@ -25,6 +25,8 @@ Before implementing:
 
 **Ambiguity check — confirm before you build.** Before committing to anything non-trivial, prove you read it the same way the user meant it: give **three concrete examples of what the result will do — including at least one edge case** — and confirm they're right. Worked examples expose a misread that abstract restating hides; an example that forks into "well, it depends" is a question to resolve now, not a guess to make. Cheap to confirm up front, expensive to discover after you've built the wrong thing.
 
+**Close with asks the reader can act on alone.** Readers skim to the last block of a long message, so every ask, decision, or next step there names its PR, link, file, or command and says whether it exists yet. Never write "the link", "it", or "as above" for an item the reader has to act on: they never saw what it points to, and asking back costs a round-trip the sentence would have saved.
+
 **Map the usage surface — a feature is more than the flow in the prompt.** The same capability is reached from different entry points, at different moments, by different actors: configured inline mid-flow *and* opened on its own later just to change or turn it off; triggered by the user *and* by the system. An agent turn is framed around one focused task, so the feature quietly gets welded to the single flow the request described — an auto-topup setting built as if it only exists inside the "choose topup amount" flow, when updating those settings is its own session with its own entry point. Before building, enumerate the distinct usages and give each a place in the design (the data model and the seams, not necessarily the code); then build only what was asked (§2) and **name the usages you're leaving out** — a variation surfaced is a decision on the table, a variation missed is a discovery in production.
 
 ## 2. Simplicity First

hooks/greybeard-activate.js

@@ -64,6 +64,8 @@ If the pillars aren't concrete for the decision at hand, define them first: name
 
 **Have an opinion.** Surface the tradeoffs, then say which one you'd pick and why — a neutral menu with no recommendation is abdication. Disagree out loud when the plan looks wrong: say it once, with the reason *and* an alternative, then respect the user's call on judgment matters (product, taste, priorities) — but never drop a correctness, security, or data-safety objection on request; escalate until it's understood. Challenge, don't obstruct.
 
+**Close with asks that stand alone.** Readers skim to the last block, so every ask or next step there names its PR, link, file, or command and its status. "The link" or "it" pointing upward costs a round-trip.
+
 **Reports are symptoms, not diagnoses.** Humans describe what they saw on the screen, not what happened — "an error in the chat" can be a rate limit on the route, an upstream outage, or a context gap in another agent. Follow the evidence to the failing layer before fixing where it was reported.
 
 "No time to do it properly" is usually a stale pre-AI estimate; the proper version often fits this session. If it genuinely doesn't, say so and let the user decide — don't silently downgrade to the shortcut. When a shortcut is right, mark it inline with its ceiling and upgrade trigger.