depth/ii (draft): propose intent from the data instead of asking for it - #16
depth/ii (draft): propose intent from the data instead of asking for it#16sergiobuilds wants to merge 2 commits into
Conversation
Inverts the interview shape. Instead of asking the user what they want, ii reads the data they just handed over — files, a repo, a paste, a chat scrollback — and returns what the user must be trying to do with it, as a proposal the user only has to confirm, revise, or reject. The failure mode this skill targets is the well-known one — a user hands over material with a thin ask, and a follow-up question forces them to compose a sentence they did not have ready. Asking is expensive for the user; confirming is cheap. ii picks the cheap side. Rules keep it restrained: - Read before proposing. A proposal without reading is a guess. - Ground the proposal in the data — point at what you read, not what you assumed. - One intent per turn. If two are plausible, propose the more likely and note the other. - Confirm or correct, do not compose. If the turn ends with the user needing to assemble a sentence, redo the proposal. - If the data is too thin to propose from, say so and stop — do not fall back to asking. Registered in plugin.json and README's depth index; passes validate-skills.sh (18 skills).
New skill under the depth/ perspective (minor bump per CLAUDE.md's version-bump rule for a new skill).
0c01e1d to
db96c34
Compare
|
Draft → Ready. Rebased onto latest `main` (past the `re0-*` rename and the new skills) and re-verified. What the branch carries now:
Verified locally: `bash scripts/validate-skills.sh` → `✓ skill catalog valid (23 skills)`, `node -e "JSON.parse(...)"` on `plugin.json` OK. One deferred item, same as #15: `docs/readme/README.*.md` still don't list `ii` in ten languages. Held out of this PR to keep it single-purpose; happy to add a follow-up commit with the localized rows on request. |
|
@sergiobuilds 🏹 this filled a gap nothing else in the suite reached, thank you! Your ii skill ships in The rename: "ii" kept its secret too well, nobody half-guesses "propose the intent behind handed-over data" from two letters. "aim" says what it does, and it lands as the mirror of What I tuned on top of your design:
The idea, read the data and offer the intent to confirm instead of asking for it, is yours. Thank you 💚 |
Inverts the interview shape. Instead of asking the user what they want,
iireads the data they just handed over — files, a repo, a paste, a chat scrollback — and returns what the user must be trying to do with it, as a proposal the user only has to confirm, revise, or reject.Posted as a draft — the shape is deliberately thin, so the review can settle on where this fits before it grows.
What it does
The failure mode
iitargets is the well-known one: a user hands over material with a thin ask, and a follow-up question forces them to compose a sentence they did not have ready. Asking is expensive for the user; confirming is cheap.iipicks the cheap side.Design commitments
Where it sits
Placed in
depth/because each invocation acts on one data drop, right now — the user's current handover. Contrast with the neighboring skills:shower— read one artifact cold, does it stand on its ownhate— kill one plan with the load-bearing objectionii— read one data drop, propose the intent behind itVerification
The user's next reply is short — a yes, a correction, or a small adjustment. If they had to explain what they wanted from scratch, the proposal was wrong or was really a question.
Registered in
plugin.jsonand README'sdepth/index; passesvalidate-skills.sh(18 skills).Open questions for review
depth/vs a new home. Placed indepth/because it acts on one data drop right now. A case could be made forbreadth/(reconciling many scattered pieces into one truth — the intent).