[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6R8VH37JK9TYEXCCC3Z653T":3,"skill-same:01M6R8VH37JK9TYEXCCC3Z653T":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6R8VH37JK9TYEXCCC3Z653T","asb-carol-strengths",null,"Facilitates the second step of a proven ideal-customer (ICP) method: distilling raw company observations into the few deep-truth attributes that matter, then classifying each as a strength, a weakness, or deliberately both. Takes an observations list (O1, O2, … — file or pasted), proposes attributes one at a time with their supporting observations, kills generic ones with the Opposite Test ('we love our customers' dies), classifies each with a concrete rubric (a third of the market sees it that way, or some customers buy\u002Frefuse for it alone), and records the result in STRENGTHS-WEAKNESSES.md (S1, S2, … \u002F W1, W2, …). Load when the user has raw observations and wants to distill them, asks 'what are our real strengths and weaknesses,' or wants to classify what they learned from the honest-look exercise. Do NOT load to gather the raw observations (the previous step), to derive keystones or deal-breakers from classified attributes (later steps), or for a person's individual strengths and weaknesses.","Nairon-AI\u002Fagentic-starter-pack","Nairon-AI","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F260662138?v=4","01M6R8PZ1Y8CSQGFN61VACZGTH","Nairon AI","01M6R8PZ6184VR3BA88YZFBC3N",4,"MIT","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fbusiness\u002Fasb-carol-strengths\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"asb carol strengths","classify","when","result","company","at","attributes","learned","icp","as","customer","deep","time","do","later","rubric","list","one at a time","distill","exercise","2026-11-10 10:12:30",false,"---\nname: asb-carol-strengths\ndescription: \"Facilitates the second step of a proven ideal-customer (ICP) method: distilling raw company observations into the few deep-truth attributes that matter, then classifying each as a strength, a weakness, or deliberately both. Takes an observations list (O1, O2, … — file or pasted), proposes attributes one at a time with their supporting observations, kills generic ones with the Opposite Test ('we love our customers' dies), classifies each with a concrete rubric (a third of the market sees it that way, or some customers buy\u002Frefuse for it alone), and records the result in STRENGTHS-WEAKNESSES.md (S1, S2, … \u002F W1, W2, …). Load when the user has raw observations and wants to distill them, asks 'what are our real strengths and weaknesses,' or wants to classify what they learned from the honest-look exercise. Do NOT load to gather the raw observations (the previous step), to derive keystones or deal-breakers from classified attributes (later steps), or for a person's individual strengths and weaknesses.\"\n---\n\n# Strengths & Weaknesses: The Attributes That Matter\n\nRaw observations are evidence; strategy needs a verdict. This skill\nturns a pile of honest facts about a company into a short chart of\nclassified attributes — the strengths a future ideal customer will love\nyou for, and the weaknesses she'll either tolerate or be repelled by.\nTwo moves, in order: distill the observations into the few deep truths\nunderneath them, then classify each one with a rubric that resolves the\nparadox that almost anything can be argued either way.\n\n## The mental model\n\n### Observations → deep truths\n\nThe facts we notice are usually consequences of something deeper.\n\"Customers post screenshots on Reddit of long ticket wait times\"\nreveals the attribute \"slow tech support.\" \"Customers brag by posting\nside-by-side screenshots next to a competitor\" reveals \"delightful,\nremarkable design.\" Distilling asks of each observation (or cluster of\nobservations): *what deep truth about the product and company does\nthis reveal?* Fewer, stronger attributes beat many weak ones — a\nsmaller set is easier to hold in mind, easier to act on, easier to set\nin stone. Merge observations that point at the same truth; drop ones\nthat point nowhere.\n\n### The genericness trap and the Opposite Test\n\nThe fatal failure mode of distillation is generalizing an attribute\ninto banality. \"We love our customers\" is so generic that nearly every\ncompany says it (even when it's false) — it's not actionable and it\nwill never create the edge that separates an ideal customer from\neveryone else. If the truth is that you go above and beyond, the\nattribute cites the mechanism: \"any employee can spend up to $2,000 to\nfix a customer's problem without approval.\" If the truth is genuine\nrelationships, it's \"quarterly business reviews with every account;\nonly knowledgeable humans answer the support line.\"\n\nThe gate is the **Opposite Test**: construct the claim's opposite and\nask whether any successful company would rationally choose it. \"Easy\nto use\" fails — nobody claims \"difficult to use.\" \"Transparent, simple\npricing\" passes — enterprise software is proudly call-for-pricing, and\nthe top clouds thrive on pricing so complex that entire companies\nexist to manage it. An attribute that fails the Opposite Test is not\nrecorded, in any form, however warmly the user feels about it — there\nis always a specific version of a true attribute, and finding it is\nthe work. (One sanctioned exception, from the source: a claim whose\nopposite nobody would *say* can still pass when you dominate the\nfield on it by a wide margin — \"four times faster than the\ncompetition, measured\" is a real attribute even though nobody claims\n\"slow.\" The domination must be specific and large, not vibes.)\n\nFor a weakness-shaped attribute — an absence or a shortfall — the\ntest runs mirrored: is *having* the thing a real strategy someone\nproudly pursues? \"No scheduling module\" passes because best-of-breed\nvendors deliberately don't bundle and bundlers proudly do — the\nabsence is a genuine position, not filler. \"Our website has typos\"\nfails; nobody strategizes toward typos, so it's a defect note, not an\nattribute.\n\n### The classification rubric\n\nWhether an attribute is a strength or weakness is entirely in the eye\nof the beholder — \"inexpensive\" attracts price-conscious buyers and\nrepels serious ones. So the call is made with two concrete questions:\n\n1. **Strength** — is at least one of these true?\n   a. More than one-third of the market considers this a strength.\n   b. Some customers love or need this so much they will buy for this\n      reason alone.\n2. **Weakness** — is at least one of these true?\n   a. More than one-third of the market considers this a weakness.\n   b. For some customers this makes the product impossible to use;\n      they will refuse to buy for this reason alone.\n\nTypically only one comes up yes: a lightning-fast interface is a\nstrength (1a) and nobody calls it a weakness. Lacking security\ncertifications is a weakness (2b) even though most of the market\ndoesn't care. But two other outcomes matter just as much:\n\n- **Yes to both** → the attribute is *both*, listed in both columns\n  and flagged: different market segments disagree about it, which\n  means a clear strategic choice is waiting (\"one hundred features\"\n  is completeness to some, bloat to others — you will eventually have\n  to pick whom to please). These are the most useful attributes to\n  find, not a problem to resolve away.\n- **No to both** → nobody cares. The attribute is dropped — recorded\n  in a cuts list with one line of reasoning, so attention stops going\n  to things without an audience.\n\n### Aspirations are not attributes\n\nThe observations file often contains say-we're-great-but-aren't\nentries (claimed reliability with a record of outages, \"seamless\nintegrations\" that are nightly CSV jobs). These classify by the\n*record*, not the claim: the underlying truth is usually a weakness\ncandidate (\"integration breadth is claimed but shallow\"), never a\nstrength. The wish itself may be strategy input later; it is not an\nattribute of who you are today.\n\n### Vocabulary\n\n- **Attribute** — one distilled deep truth about the company or\n  product, worded specifically enough to pass the Opposite Test.\n- **S1, S2, … \u002F W1, W2, …** — classified attributes; a both-attribute\n  carries a number in each column, cross-referenced.\n- **Both** — yes to both rubric questions; flagged as a pending\n  strategic choice.\n- **Cut** — no to both; dropped with its reasoning on the record.\n- **[O-numbers]** — the observations an attribute distills; every\n  attribute cites its evidence.\n\n## The classifier's posture\n\n### Be clear, not clever\n\nWrite to be understood, not admired. The work here wrestles with hard\nconcepts, and clever metaphors, wordplay, or cute turns of phrase make\nthem harder to grasp, not easier. Say plainly what you mean. If a\nsentence reads more clearly without a flourish, cut the flourish. State\nthe actual point rather than gesturing wittily at it.\n\n### Restate references; never cite a bare token\n\nWhen you mention a numbered or lettered item to the user — K4, W2,\nO17, H3, and the like — add a few plain words on what it actually is\n(\"K4 — the owner whose career rides on the site\"). A bare token is\nunreadable to a human who saw it defined hours or days ago: the tag is\nfor traceability, the gloss is for comprehension. Keep the tag for\naccuracy; always add the gloss.\n\n### Propose from evidence; the user corrects\n\nUnlike gathering (where inventing content poisons the file),\ndistilling is analysis of evidence already on the record — so here you\nmay propose freely: read the observations, cluster them, and offer one\ncandidate attribute at a time with its [O-number] citations and\nproposed wording. But the user corrects and confirms each one — they\nknow which reading of the evidence is true — and batch-nodding is\ndeclined; every attribute earns its place individually. Where the\nobservations support two different distillations, show both and let\nthe user pick.\n\n### The Opposite Test is not negotiable\n\nA generic attribute never enters the file, however the user insists —\n\"it's true though\" is not the bar; *distinctive* is the bar. Run the\ntest visibly on every candidate, including your own. A predefined way\nto press harder: if a devil's-advocate interrogation skill is\ninstalled in the environment (for example *Rude Q&A* \u002F `asb-rude-qa`,\nfrom the same author as this method), invoke it against the draft\nattribute list with this brief: *attack these attributes — find every\nentry whose opposite no successful company would claim, every one too\ngeneric to separate an ideal customer from everyone else, and every\none that flatters an aspiration rather than describing the record;\ndon't accept vague or wishful defenses.* If no such skill is\navailable, run that interrogation yourself, visibly. Timing: the\nper-candidate test happens inline before anything is recorded; the\ndelegated (or self-run) batch attack is the Phase C re-pass over the\nwhole chart. The refusal is always of the generic wording, never of\nthe underlying truth — keep offering sharper rewrites until one\npasses.\n\n### Classification is the user's call, made against the rubric\n\nYou supply the rubric, the evidence, and a candidate answer; the user\nsupplies market judgment (\"would a third of our market see it that\nway? has anyone ever bought for this alone?\"). When the observations\nthemselves answer a rubric question — a cancellation email is\nbuy\u002Frefuse-for-this-alone evidence — cite it. When the user's call\ncontradicts their own evidence file, make them defend it once (\"O5\nsays two customers canceled over this; you're saying nobody would\nrefuse for it?\"), then record their call — with one carve-out: the\ncraft rules outrank the deference. An aspiration never classifies as\na strength against the record, a generic wording never enters, and a\nboth never collapses into one column, however the user insists after\nthe defense; those are the gates that make the chart mean something\ndownstream. Never leave an attribute unclassified to avoid the\nargument.\n\n### One attribute per exchange\n\nPropose it, cite it, test it, classify it, record it — then the next.\nNever a wall of candidate attributes. The opening move is small: what\nwas read, roughly how many attribute clusters you see, then the first\ncandidate. If the user asks to speed up, compress ceremony (shorter\ndisplays, token confirms for obvious ones), never structure.\n\n### Park downstream discoveries; don't solve them here\n\nDistilling surfaces things that belong to *later* steps — a weakness\nso absolute it reads as a deal-breaker, a trigger that clearly incites\na purchase, a market segment worth remembering for the keystones. Don't\nchase them: this step classifies attributes, not deal-breakers,\ninciting events, or keystones, and solving them here muddies the chart.\nBut don't lose them either. Record each in a dedicated **Notes for\ndownstream steps** section — one line, tagged with the step it's for —\nkept strictly separate from the strength\u002Fweakness attributes so the\nchart stays clean *and* the finding still travels forward. When the\nuser surfaces one, acknowledge it, park it there, and return to the\nattribute at hand. (This is distinct from the strategic-notes idea:\nthose are true-but-not-customer-facing facts about *today*; these are\nfindings addressed to a *future* step of the method.)\n\n## How to use this skill\n\n### Phase A — Ingest\n\nRead the observations (default: `OBSERVATIONS.md` in the current\ndirectory; or pasted). Note the context preamble — it carries the\ncompany background — and the side-list, which stays untouched. If no\nobservations exist at all, don't distill from nothing: offer the\nhonest on-ramp — either run the gathering step first (if an\nobservation-gathering skill from this method's author is installed,\nfor example *Observations* \u002F `asb-carol-observations`, name it), or\ncapture a quick in-chat set now, holding the same specificity bar,\nwith the caveat that a thin base yields a thin chart. For the quick\ncapture: three prompts cover the loudest ground — what customers\nactually praise (a quote, an incident), the complaint you have no\ndefense against, and what separates your best customers from your\nworst. Number the captures O1, O2, … as they settle, offer to write\nthem to an OBSERVATIONS.md so a later full gathering pass appends\nrather than restarts, and note in the chart's preamble that the base\ncame from chat. The Phase C size guidance doesn't apply to a thin\nbase — two strengths from six observations is honest, not\nundersized. If a\nSTRENGTHS-WEAKNESSES.md already exists at the target location, read\nit: an in-progress header means resume — pick up where it says, don't\nre-litigate settled attributes. Marked complete means ask whether to\nrevise or replace.\n\nOutput location: `STRENGTHS-WEAKNESSES.md` in the same directory as\nthe input file. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current directory) — never scatter files silently.\n\n### Phase B — Distill and classify, one attribute at a time\n\nOpen small: what you read (how many observations, any that are\nespecially load-bearing), how many attribute clusters you see, then\nthe first candidate. Then the loop, per attribute:\n\n1. **Propose** the attribute with its supporting [O-numbers] and a\n   specific wording. Where evidence supports two readings, show both.\n2. **Opposite Test** — visibly. If it fails, reword toward the\n   mechanism until it passes or the user agrees it's banality.\n3. **Classify** with the rubric — both questions, all four\n   sub-criteria, the user answering from market knowledge, you citing\n   the observations where they already answer. Both = both columns +\n   flag. No-to-both = cuts list.\n4. **Record** to the file and move on.\n\nEvery observation should end up either cited by an attribute,\ndeliberately left as color (\"supporting detail, no attribute of its\nown\"), or named in the cuts reasoning — sweep for orphans before\nclosing. Don't force it the other way: an attribute needs at least\none observation behind it; an attribute with no evidence is a wish,\nand belongs back in the gathering step.\n\n**Record to the file as you go.** Create `STRENGTHS-WEAKNESSES.md`\nwhen the first attribute settles; append after each; keep the header\npointer current. The file is the memory, not the chat. If files\naren't accessible, re-emit the full draft in a fenced block every\nattribute or two.\n\n### Phase C — Sweep and close\n\n- **Coverage** — every observation accounted for (cited, color, or\n  cut); no attribute without evidence.\n- **Size** — the chart should be short: roughly four to eight\n  strengths and a similar count of weaknesses is the useful zone. If\n  it ballooned, merge harder — fewer, stronger.\n- **Opposite Test re-pass** — early entries sometimes read generic\n  next to later ones; one more press.\n- **Both-flags** — read them back: each is a pending strategic choice\n  the later steps will force; make sure each says which segments\n  disagree.\n- **Downstream parking** — anything that surfaced for a later step sits\n  in *Notes for downstream steps*, tagged with its step, and never in\n  the attribute columns.\n\nFinalize: remove the in-progress header and close with the handoff.\nThe next step refines strengths into keystones — the characteristics\nthat make certain customers *need* an extreme version of a strength —\nand names the market segments that typify them; if a keystones skill\nfrom this method's author is installed (for example *Keystones* \u002F\n`asb-carol-keystones`), name it: \"when you're ready, run\n`asb-carol-keystones` on this file.\"\n\n### The file structure\n\n```markdown\n# Strengths & Weaknesses — \u003Ccompany \u002F project name>\n\n> ⚠️ IN PROGRESS — distillation is not complete. Attributes settled:\n> \u003Ccount>; observations processed: \u003Cwhich>; currently on: \u003Cthe\n> cluster being worked>. If you are resuming, continue there. (This\n> note is removed at finalization.)\n\n\u003CTwo or three lines: which observations file this distills (name it),\nand the company context carried over from its preamble. Attributes\nare classified with the two-question rubric; a both-classified\nattribute appears in both columns, cross-referenced.>\n\n\u003COne line: the best-vs-worst customer differential, carried over from\nthe observations' head\u002Ftail category — or \"no differential recorded.\"\nLater steps (keystones, the final definition) mine it, and it must\ntravel with this chart even when the chart is pasted without its\nobservations file.>\n\n## Strengths\n\n**S1.** \u003CSpecific attribute wording.>    [O1, O11]\n    Rubric: \u003Cwhich criterion made it a strength — e.g. \"1b: two\n    referral customers named this as the reason they signed\">.\n\n**S2.** \u003C…>    [O5]\n\n## Weaknesses\n\n**W1.** \u003CSpecific attribute wording.>    [O4, O5]\n    Rubric: \u003Cwhich criterion — e.g. \"2b: both recent cancellations\n    cited it\">.\n\n**W2.** \u003C= S4; deliberately both — segments disagree: \u003Cwho reads it\n    which way>. A strategic choice is pending here.>    [O9]\n\n## Cuts (nobody cares — attention stops here)\n\n- \u003CAttribute candidate> — no to both rubric questions: \u003Cone line of\n  reasoning>.    [O13]\n\n## Notes for downstream steps (parked, not attributes)\n\n\u003CFindings that surfaced during distillation but belong to a LATER step\nof the method — recorded so they aren't lost, kept out of the attribute\ncolumns so the chart stays clean. Each line tags the step it's for.>\n\n- \u003Cfinding> — for \u003Ckeystones \u002F deal-breakers \u002F inciting-events \u002F\n  definition>: \u003Cone line of what was noticed and why it's parked here>.\n\n## Next steps\n\n\u003CTwo or three sentences of prose: refine each strength into the\nkeystones — the characteristics, behaviors, or circumstances that\nmake a customer NEED an extreme version of it — and name the\nreal-world market segments that typify each; then do the mirror work\non weaknesses (deal-breakers and the anti-market). That's the next\nstep of the method, and it works directly from this file.>\n```\n\nS- and W-numbers are stable once written — later steps cite them —\nand a both-attribute holds one number in each column with the\ncross-reference stated; it counts as ONE attribute in the settled\ncount and the size tally, each column citing the evidence for its own\nreading (the flag carries the full set), and both halves carrying a\nrubric line. Never renumber; a merged or reworded entry keeps its\nnumber. Cuts may be batched in one exchange when the user has\npre-authorized it and the reasoning is genuinely one line each.\n\n## Refusal conditions\n\n- **No observations.** Distilling from memory or vibes produces the\n  plausible-generic chart this method exists to prevent. Offer the\n  gathering step or a quick honest capture first.\n- **Generic attributes, however insisted.** \"Great customer service\"\n  does not enter the file until it names the mechanism that a\n  competitor could rationally lack. Refuse the wording, keep the\n  truth, offer rewrites.\n- **Aspirations as strengths.** If the record contradicts the claim\n  (outages vs. \"reliable\"), the attribute classifies by the record.\n  The wish is noted as a wish, not recorded as a strength.\n- **\"Skip the rubric, I know our strengths.\"** The rubric is what\n  makes the chart mean something to the later steps — a strength\n  nobody would buy for alone and only you believe in is exactly what\n  it exists to catch. Run it; it takes one exchange per attribute.\n- **Resolving a both into one column for tidiness.** Both is a\n  finding — it marks a strategic choice. Record it as both, flagged;\n  the choice gets made downstream with eyes open, not here by\n  default.\n- **Keystones, deal-breakers, or strategy.** Deriving who needs these\n  strengths, who's excluded by these weaknesses, or what to do about\n  any of it is the later steps' job. The chart is the deliverable\n  here.\n","# Strengths & Weaknesses: The Attributes That Matter\n\nRaw observations are evidence; strategy needs a verdict. This skill\nturns a pile of honest facts about a company into a short chart of\nclassified attributes — the strengths a future ideal customer will love\nyou for, and the weaknesses she'll either tolerate or be repelled by.\nTwo moves, in order: distill the observations into the few deep truths\nunderneath them, then classify each one with a rubric that resolves the\nparadox that almost anything can be argued either way.\n\n## The mental model\n\n### Observations → deep truths\n\nThe facts we notice are usually consequences of something deeper.\n\"Customers post screenshots on Reddit of long ticket wait times\"\nreveals the attribute \"slow tech support.\" \"Customers brag by posting\nside-by-side screenshots next to a competitor\" reveals \"delightful,\nremarkable design.\" Distilling asks of each observation (or cluster of\nobservations): *what deep truth about the product and company does\nthis reveal?* Fewer, stronger attributes beat many weak ones — a\nsmaller set is easier to hold in mind, easier to act on, easier to set\nin stone. Merge observations that point at the same truth; drop ones\nthat point nowhere.\n\n### The genericness trap and the Opposite Test\n\nThe fatal failure mode of distillation is generalizing an attribute\ninto banality. \"We love our customers\" is so generic that nearly every\ncompany says it (even when it's false) — it's not actionable and it\nwill never create the edge that separates an ideal customer from\neveryone else. If the truth is that you go above and beyond, the\nattribute cites the mechanism: \"any employee can spend up to $2,000 to\nfix a customer's problem without approval.\" If the truth is genuine\nrelationships, it's \"quarterly business reviews with every account;\nonly knowledgeable humans answer the support line.\"\n\nThe gate is the **Opposite Test**: construct the claim's opposite and\nask whether any successful company would rationally choose it. \"Easy\nto use\" fails — nobody claims \"difficult to use.\" \"Transparent, simple\npricing\" passes — enterprise software is proudly call-for-pricing, and\nthe top clouds thrive on pricing so complex that entire companies\nexist to manage it. An attribute that fails the Opposite Test is not\nrecorded, in any form, however warmly the user feels about it — there\nis always a specific version of a true attribute, and finding it is\nthe work. (One sanctioned exception, from the source: a claim whose\nopposite nobody would *say* can still pass when you dominate the\nfield on it by a wide margin — \"four times faster than the\ncompetition, measured\" is a real attribute even though nobody claims\n\"slow.\" The domination must be specific and large, not vibes.)\n\nFor a weakness-shaped attribute — an absence or a shortfall — the\ntest runs mirrored: is *having* the thing a real strategy someone\nproudly pursues? \"No scheduling module\" passes because best-of-breed\nvendors deliberately don't bundle and bundlers proudly do — the\nabsence is a genuine position, not filler. \"Our website has typos\"\nfails; nobody strategizes toward typos, so it's a defect note, not an\nattribute.\n\n### The classification rubric\n\nWhether an attribute is a strength or weakness is entirely in the eye\nof the beholder — \"inexpensive\" attracts price-conscious buyers and\nrepels serious ones. So the call is made with two concrete questions:\n\n1. **Strength** — is at least one of these true?\n   a. More than one-third of the market considers this a strength.\n   b. Some customers love or need this so much they will buy for this\n      reason alone.\n2. **Weakness** — is at least one of these true?\n   a. More than one-third of the market considers this a weakness.\n   b. For some customers this makes the product impossible to use;\n      they will refuse to buy for this reason alone.\n\nTypically only one comes up yes: a lightning-fast interface is a\nstrength (1a) and nobody calls it a weakness. Lacking security\ncertifications is a weakness (2b) even though most of the market\ndoesn't care. But two other outcomes matter just as much:\n\n- **Yes to both** → the attribute is *both*, listed in both columns\n  and flagged: different market segments disagree about it, which\n  means a clear strategic choice is waiting (\"one hundred features\"\n  is completeness to some, bloat to others — you will eventually have\n  to pick whom to please). These are the most useful attributes to\n  find, not a problem to resolve away.\n- **No to both** → nobody cares. The attribute is dropped — recorded\n  in a cuts list with one line of reasoning, so attention stops going\n  to things without an audience.\n\n### Aspirations are not attributes\n\nThe observations file often contains say-we're-great-but-aren't\nentries (claimed reliability with a record of outages, \"seamless\nintegrations\" that are nightly CSV jobs). These classify by the\n*record*, not the claim: the underlying truth is usually a weakness\ncandidate (\"integration breadth is claimed but shallow\"), never a\nstrength. The wish itself may be strategy input later; it is not an\nattribute of who you are today.\n\n### Vocabulary\n\n- **Attribute** — one distilled deep truth about the company or\n  product, worded specifically enough to pass the Opposite Test.\n- **S1, S2, … \u002F W1, W2, …** — classified attributes; a both-attribute\n  carries a number in each column, cross-referenced.\n- **Both** — yes to both rubric questions; flagged as a pending\n  strategic choice.\n- **Cut** — no to both; dropped with its reasoning on the record.\n- **[O-numbers]** — the observations an attribute distills; every\n  attribute cites its evidence.\n\n## The classifier's posture\n\n### Be clear, not clever\n\nWrite to be understood, not admired. The work here wrestles with hard\nconcepts, and clever metaphors, wordplay, or cute turns of phrase make\nthem harder to grasp, not easier. Say plainly what you mean. If a\nsentence reads more clearly without a flourish, cut the flourish. State\nthe actual point rather than gesturing wittily at it.\n\n### Restate references; never cite a bare token\n\nWhen you mention a numbered or lettered item to the user — K4, W2,\nO17, H3, and the like — add a few plain words on what it actually is\n(\"K4 — the owner whose career rides on the site\"). A bare token is\nunreadable to a human who saw it defined hours or days ago: the tag is\nfor traceability, the gloss is for comprehension. Keep the tag for\naccuracy; always add the gloss.\n\n### Propose from evidence; the user corrects\n\nUnlike gathering (where inventing content poisons the file),\ndistilling is analysis of evidence already on the record — so here you\nmay propose freely: read the observations, cluster them, and offer one\ncandidate attribute at a time with its [O-number] citations and\nproposed wording. But the user corrects and confirms each one — they\nknow which reading of the evidence is true — and batch-nodding is\ndeclined; every attribute earns its place individually. Where the\nobservations support two different distillations, show both and let\nthe user pick.\n\n### The Opposite Test is not negotiable\n\nA generic attribute never enters the file, however the user insists —\n\"it's true though\" is not the bar; *distinctive* is the bar. Run the\ntest visibly on every candidate, including your own. A predefined way\nto press harder: if a devil's-advocate interrogation skill is\ninstalled in the environment (for example *Rude Q&A* \u002F `asb-rude-qa`,\nfrom the same author as this method), invoke it against the draft\nattribute list with this brief: *attack these attributes — find every\nentry whose opposite no successful company would claim, every one too\ngeneric to separate an ideal customer from everyone else, and every\none that flatters an aspiration rather than describing the record;\ndon't accept vague or wishful defenses.* If no such skill is\navailable, run that interrogation yourself, visibly. Timing: the\nper-candidate test happens inline before anything is recorded; the\ndelegated (or self-run) batch attack is the Phase C re-pass over the\nwhole chart. The refusal is always of the generic wording, never of\nthe underlying truth — keep offering sharper rewrites until one\npasses.\n\n### Classification is the user's call, made against the rubric\n\nYou supply the rubric, the evidence, and a candidate answer; the user\nsupplies market judgment (\"would a third of our market see it that\nway? has anyone ever bought for this alone?\"). When the observations\nthemselves answer a rubric question — a cancellation email is\nbuy\u002Frefuse-for-this-alone evidence — cite it. When the user's call\ncontradicts their own evidence file, make them defend it once (\"O5\nsays two customers canceled over this; you're saying nobody would\nrefuse for it?\"), then record their call — with one carve-out: the\ncraft rules outrank the deference. An aspiration never classifies as\na strength against the record, a generic wording never enters, and a\nboth never collapses into one column, however the user insists after\nthe defense; those are the gates that make the chart mean something\ndownstream. Never leave an attribute unclassified to avoid the\nargument.\n\n### One attribute per exchange\n\nPropose it, cite it, test it, classify it, record it — then the next.\nNever a wall of candidate attributes. The opening move is small: what\nwas read, roughly how many attribute clusters you see, then the first\ncandidate. If the user asks to speed up, compress ceremony (shorter\ndisplays, token confirms for obvious ones), never structure.\n\n### Park downstream discoveries; don't solve them here\n\nDistilling surfaces things that belong to *later* steps — a weakness\nso absolute it reads as a deal-breaker, a trigger that clearly incites\na purchase, a market segment worth remembering for the keystones. Don't\nchase them: this step classifies attributes, not deal-breakers,\ninciting events, or keystones, and solving them here muddies the chart.\nBut don't lose them either. Record each in a dedicated **Notes for\ndownstream steps** section — one line, tagged with the step it's for —\nkept strictly separate from the strength\u002Fweakness attributes so the\nchart stays clean *and* the finding still travels forward. When the\nuser surfaces one, acknowledge it, park it there, and return to the\nattribute at hand. (This is distinct from the strategic-notes idea:\nthose are true-but-not-customer-facing facts about *today*; these are\nfindings addressed to a *future* step of the method.)\n\n## How to use this skill\n\n### Phase A — Ingest\n\nRead the observations (default: `OBSERVATIONS.md` in the current\ndirectory; or pasted). Note the context preamble — it carries the\ncompany background — and the side-list, which stays untouched. If no\nobservations exist at all, don't distill from nothing: offer the\nhonest on-ramp — either run the gathering step first (if an\nobservation-gathering skill from this method's author is installed,\nfor example *Observations* \u002F `asb-carol-observations`, name it), or\ncapture a quick in-chat set now, holding the same specificity bar,\nwith the caveat that a thin base yields a thin chart. For the quick\ncapture: three prompts cover the loudest ground — what customers\nactually praise (a quote, an incident), the complaint you have no\ndefense against, and what separates your best customers from your\nworst. Number the captures O1, O2, … as they settle, offer to write\nthem to an OBSERVATIONS.md so a later full gathering pass appends\nrather than restarts, and note in the chart's preamble that the base\ncame from chat. The Phase C size guidance doesn't apply to a thin\nbase — two strengths from six observations is honest, not\nundersized. If a\nSTRENGTHS-WEAKNESSES.md already exists at the target location, read\nit: an in-progress header means resume — pick up where it says, don't\nre-litigate settled attributes. Marked complete means ask whether to\nrevise or replace.\n\nOutput location: `STRENGTHS-WEAKNESSES.md` in the same directory as\nthe input file. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current directory) — never scatter files silently.\n\n### Phase B — Distill and classify, one attribute at a time\n\nOpen small: what you read (how many observations, any that are\nespecially load-bearing), how many attribute clusters you see, then\nthe first candidate. Then the loop, per attribute:\n\n1. **Propose** the attribute with its supporting [O-numbers] and a\n   specific wording. Where evidence supports two readings, show both.\n2. **Opposite Test** — visibly. If it fails, reword toward the\n   mechanism until it passes or the user agrees it's banality.\n3. **Classify** with the rubric — both questions, all four\n   sub-criteria, the user answering from market knowledge, you citing\n   the observations where they already answer. Both = both columns +\n   flag. No-to-both = cuts list.\n4. **Record** to the file and move on.\n\nEvery observation should end up either cited by an attribute,\ndeliberately left as color (\"supporting detail, no attribute of its\nown\"), or named in the cuts reasoning — sweep for orphans before\nclosing. Don't force it the other way: an attribute needs at least\none observation behind it; an attribute with no evidence is a wish,\nand belongs back in the gathering step.\n\n**Record to the file as you go.** Create `STRENGTHS-WEAKNESSES.md`\nwhen the first attribute settles; append after each; keep the header\npointer current. The file is the memory, not the chat. If files\naren't accessible, re-emit the full draft in a fenced block every\nattribute or two.\n\n### Phase C — Sweep and close\n\n- **Coverage** — every observation accounted for (cited, color, or\n  cut); no attribute without evidence.\n- **Size** — the chart should be short: roughly four to eight\n  strengths and a similar count of weaknesses is the useful zone. If\n  it ballooned, merge harder — fewer, stronger.\n- **Opposite Test re-pass** — early entries sometimes read generic\n  next to later ones; one more press.\n- **Both-flags** — read them back: each is a pending strategic choice\n  the later steps will force; make sure each says which segments\n  disagree.\n- **Downstream parking** — anything that surfaced for a later step sits\n  in *Notes for downstream steps*, tagged with its step, and never in\n  the attribute columns.\n\nFinalize: remove the in-progress header and close with the handoff.\nThe next step refines strengths into keystones — the characteristics\nthat make certain customers *need* an extreme version of a strength —\nand names the market segments that typify them; if a keystones skill\nfrom this method's author is installed (for example *Keystones* \u002F\n`asb-carol-keystones`), name it: \"when you're ready, run\n`asb-carol-keystones` on this file.\"\n\n### The file structure\n\n```markdown\n# Strengths & Weaknesses — \u003Ccompany \u002F project name>\n\n> ⚠️ IN PROGRESS — distillation is not complete. Attributes settled:\n> \u003Ccount>; observations processed: \u003Cwhich>; currently on: \u003Cthe\n> cluster being worked>. If you are resuming, continue there. (This\n> note is removed at finalization.)\n\n\u003CTwo or three lines: which observations file this distills (name it),\nand the company context carried over from its preamble. Attributes\nare classified with the two-question rubric; a both-classified\nattribute appears in both columns, cross-referenced.>\n\n\u003COne line: the best-vs-worst customer differential, carried over from\nthe observations' head\u002Ftail category — or \"no differential recorded.\"\nLater steps (keystones, the final definition) mine it, and it must\ntravel with this chart even when the chart is pasted without its\nobservations file.>\n\n## Strengths\n\n**S1.** \u003CSpecific attribute wording.>    [O1, O11]\n    Rubric: \u003Cwhich criterion made it a strength — e.g. \"1b: two\n    referral customers named this as the reason they signed\">.\n\n**S2.** \u003C…>    [O5]\n\n## Weaknesses\n\n**W1.** \u003CSpecific attribute wording.>    [O4, O5]\n    Rubric: \u003Cwhich criterion — e.g. \"2b: both recent cancellations\n    cited it\">.\n\n**W2.** \u003C= S4; deliberately both — segments disagree: \u003Cwho reads it\n    which way>. A strategic choice is pending here.>    [O9]\n\n## Cuts (nobody cares — attention stops here)\n\n- \u003CAttribute candidate> — no to both rubric questions: \u003Cone line of\n  reasoning>.    [O13]\n\n## Notes for downstream steps (parked, not attributes)\n\n\u003CFindings that surfaced during distillation but belong to a LATER step\nof the method — recorded so they aren't lost, kept out of the attribute\ncolumns so the chart stays clean. Each line tags the step it's for.>\n\n- \u003Cfinding> — for \u003Ckeystones \u002F deal-breakers \u002F inciting-events \u002F\n  definition>: \u003Cone line of what was noticed and why it's parked here>.\n\n## Next steps\n\n\u003CTwo or three sentences of prose: refine each strength into the\nkeystones — the characteristics, behaviors, or circumstances that\nmake a customer NEED an extreme version of it — and name the\nreal-world market segments that typify each; then do the mirror work\non weaknesses (deal-breakers and the anti-market). That's the next\nstep of the method, and it works directly from this file.>\n```\n\nS- and W-numbers are stable once written — later steps cite them —\nand a both-attribute holds one number in each column with the\ncross-reference stated; it counts as ONE attribute in the settled\ncount and the size tally, each column citing the evidence for its own\nreading (the flag carries the full set), and both halves carrying a\nrubric line. Never renumber; a merged or reworded entry keeps its\nnumber. Cuts may be batched in one exchange when the user has\npre-authorized it and the reasoning is genuinely one line each.\n\n## Refusal conditions\n\n- **No observations.** Distilling from memory or vibes produces the\n  plausible-generic chart this method exists to prevent. Offer the\n  gathering step or a quick honest capture first.\n- **Generic attributes, however insisted.** \"Great customer service\"\n  does not enter the file until it names the mechanism that a\n  competitor could rationally lack. Refuse the wording, keep the\n  truth, offer rewrites.\n- **Aspirations as strengths.** If the record contradicts the claim\n  (outages vs. \"reliable\"), the attribute classifies by the record.\n  The wish is noted as a wish, not recorded as a strength.\n- **\"Skip the rubric, I know our strengths.\"** The rubric is what\n  makes the chart mean something to the later steps — a strength\n  nobody would buy for alone and only you believe in is exactly what\n  it exists to catch. Run it; it takes one exchange per attribute.\n- **Resolving a both into one column for tidiness.** Both is a\n  finding — it marks a strategic choice. Record it as both, flagged;\n  the choice gets made downstream with eyes open, not here by\n  default.\n- **Keystones, deal-breakers, or strategy.** Deriving who needs these\n  strengths, who's excluded by these weaknesses, or what to do about\n  any of it is the later steps' job. The chart is the deliverable\n  here.\n",{"name":5,"description":7},"main","c9d0c408715983e993b2f9ebffdbfa7f10153bcb","business\u002Fasb-carol-strengths",0,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack","https:\u002F\u002Fgithub.com\u002FNairon-AI","https:\u002F\u002Fwww.naironai.com\u002F","Building the future of Work","2026-09-20 17:40:05",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Nairon-AI\u002Fagentic-starter-pack --skill asb-carol-strengths",{"tool":59,"command":60},"bunx","bunx skills add Nairon-AI\u002Fagentic-starter-pack --skill asb-carol-strengths",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Nairon-AI\u002Fagentic-starter-pack --skill asb-carol-strengths","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fbusiness\u002Fasb-carol-strengths\u002FSKILL.md",true,[67,72],{"path":68,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"LICENSE","许可证",18657,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fbusiness\u002Fasb-carol-strengths\u002FLICENSE",{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"NOTICE.md","REFERENCE","参考文档",448,"https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fbusiness\u002Fasb-carol-strengths\u002FNOTICE.md",[79,114,135,156,176,198],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":95,"publishedAt":39},"01M6RBCG630Y8X99XWR9Q4GYNY","writing-shape","Take a markdown file of raw material and shape it into an article through a conversational session — drafting candidate openings, growing the piece paragraph by paragraph, arguing about format (lists, tables, callouts, quotes) at each step. Use when the user has a pile of notes, fragments, or a rough draft and wants help turning it into something publishable.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-shape\u002FSKILL.md",[85,90],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,24,113,21],"writing","writing shape","shape","notes","help","file","markdown","format","session","use","take","draft","article","material","it","about","quotes","candidate",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":122,"publishedAt":39},"01M6RBCCCB1KMF01P5SYGFWBSW","writing-fragments","Grilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structure, or mentions \"fragments\", \"ideate\", or \"raw material\" for writing.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-fragments\u002FSKILL.md",[120,121],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},[96,123,124,125,126,127,104,105,128,129,130,108,28,109,131,132,133,134,21],"writing fragments","grilling","ideate","develop","user","document","structure","ideas","sharp","claims","for","single",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":143,"publishedAt":39},"01M6RBC8V7NHHKMTAZB4BPXVYQ","writing-beats","Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fwriting-beats\u002FSKILL.md",[141,142],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},[96,144,145,146,105,147,148,98,149,150,151,108,152,28,153,109,154,155,133,21],"writing beats","choose","write","assemble","only","journey","next","options","end","style","narrative","argument",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":164,"publishedAt":39},"01M6RBC58SG5Y5SC4ZV4ZNEFHC","stop-slop","Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fstop-slop\u002FSKILL.md",[162,163],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},[165,166,167,96,168,169,170,171,172,105,173,174,175,133,21],"stop","stop slop","slop","content","https","text","editing","remove","prose","patterns","drafts",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":184,"publishedAt":39},"01M6RBBJTTCJ7KZCP16G9JDFZH","humanizer","Remove signs of AI-generated writing from text. Use when editing or reviewing\ntext to make it sound more natural and human-written. Based on Wikipedia's\ncomprehensive \"Signs of AI writing\" guide. Detects and fixes patterns including:\ninflated symbolism, promotional language, superficial -ing analyses, vague\nattributions, em dash overuse, rule of three, AI vocabulary words, passive\nvoice, negative parallelisms, and filler phrases.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Fhumanizer\u002FSKILL.md",[182,183],{"categoryNo":86,"categoryName":87,"taxonomyType":88,"taxonomyTypeDesc":89},{"categoryNo":91,"categoryName":92,"taxonomyType":93,"taxonomyTypeDesc":94},[178,96,185,186,170,187,146,188,189,172,190,191,174,192,193,194,195,196,197,21],"code","em dash","read","edit","generated","guide","opencode","three","human","make","wikipedia","vague","dash",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":39},"01M6RBBEQKJ5HRH8AV9J85QB1T","feedback","Prepare, deliver, and debrief timely interpersonal feedback using a question-first coaching flow, observable behavior, owned experience, and concrete impact. Use when drafting feedback, coaching managers, rehearsing a feedback conversation, praising specific behavior, or reviewing whether feedback landed.","https:\u002F\u002Fgithub.com\u002FNairon-AI\u002Fagentic-starter-pack\u002Fblob\u002Fmain\u002Fwriting\u002Ffeedback\u002FSKILL.md",[],[200,205,206,207,208,209,105,210,211,212,213,214,21,215],"prepare","flow","first","question","behavior","conversation","coaching","debrief","impact","managers","deliver"]