diff --git a/.clinerules/karpathy-skills.md b/.clinerules/karpathy-skills.md index e5346ac..1afaec4 100644 --- a/.clinerules/karpathy-skills.md +++ b/.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 diff --git a/.cursor/rules/karpathy-skills.mdc b/.cursor/rules/karpathy-skills.mdc index 8970d0b..76a1998 100644 --- a/.cursor/rules/karpathy-skills.mdc +++ b/.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 diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index e5346ac..1afaec4 100644 --- a/.github/copilot-instructions.md +++ b/.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 diff --git a/.windsurf/rules/karpathy-skills.md b/.windsurf/rules/karpathy-skills.md index e5346ac..1afaec4 100644 --- a/.windsurf/rules/karpathy-skills.md +++ b/.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 diff --git a/AGENTS.md b/AGENTS.md index e5346ac..1afaec4 100644 --- a/AGENTS.md +++ b/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 diff --git a/CLAUDE.md b/CLAUDE.md index 8daa24c..78ae2aa 100644 --- a/CLAUDE.md +++ b/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 diff --git a/GEMINI.md b/GEMINI.md index e5346ac..1afaec4 100644 --- a/GEMINI.md +++ b/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 diff --git a/hooks/greybeard-activate.js b/hooks/greybeard-activate.js index 64adb1b..3b01329 100644 --- a/hooks/greybeard-activate.js +++ b/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.