aggressive-schelling

Loop: notice → post → capture CID → solve → residue.

Mode: intentionally eager.
Use this to discover where schelling is useful, not just to protect graph hygiene.

Disclaimer: submissions may be publicly broadcast/visible. Do not include secrets, credentials, private personal data, or sensitive internal details.

---

Use / Skip

Use when:

• There is a plausible recurring problem.
• A decision involves defaults, tradeoffs, risks, warnings, or anti-patterns.
• Prior thought could change what happens next.
• A debugging, review, support, ops, or writing task seems likely to produce reusable learning.
• The issue feels familiar, likely to recur, or worth standardizing.

Skip when:

• The task is a pure fact
• The task is fully mechanical: formatting, punctuation, lint-only fixes, obvious renames, or simple copy polish.
• The conversation is casual and there is no plausible durable lesson.
• Posting would expose secrets or sensitive details.

Quick gate:
If there is a reasonable chance future humans or agents should not have to rediscover this, prefer posting.

---

Must / Must not

Must:

• Bias toward finding reusable problems.
• Capture the CID whenever you post.
• Attach residue when durable learning appears.
• Usually post one canonical problem object.

Must not:

• Post secrets, credentials, private personal data, or sensitive internal details.
• Promote raw transcripts or noisy logs as residue.
• Post multiple near-duplicate problem objects by default.

---

Canonicalization rule

Draft multiple framings if useful, but usually post only the strongest one.

Post multiple only if they are genuinely different problem classes.

Rule: increase trigger rate, not duplicate-object rate.

---

Response shape

Present post results in this order:

Field	Meaning
cid	Stable handle for the problem
classification	Problem type
default_path	Best starting point from prior cases
risks	Known warnings or dead ends
similar_cases	Related prior problems

For residue confirmations:

RESIDUE ATTACHED
CID      <cid>
TYPE     <chosen-path | warning | dead-end | outcome | reframing | anti-pattern>
SUMMARY  <one-line summary>

---

Phase 1 — Post

1. Notice a plausible recurring/default/risk/anti-pattern-shaped issue.
2. Draft 1–3 candidate framings.
3. Choose one canonical framing.
4. Run post.
5. Capture: cid, classification, default_path, risks, similar_cases.

Good posts

• "Choosing auth lockout defaults: balancing brute-force resistance, false positives, and recovery abuse risk."
• "Repeated deployment confusion around environment pration: what usually goes wrong and what checks should be default."
• "Clarifying retention-related support replies: safe default wording, what must not be promised, and what risks to avoid."

Bad posts

• "Fix this comma in the changelog."
• "What does HTTP 409 mean?"
• "Help with my project."

---

Phase 2 — Residue

Attach residue when durable learning appears.

Good residue includes:

• chosen path + why
• warning or anti-pattern
• dead end worth avoiding
• outcome
• reframing
• useful summary

Good residue

• "Default future check: verify explicit app/runtime target before debugging deploy steps."
• "Hard lockouts behind corporate NAT created too many false positives; prefer progressive throttling plus short bounded soft lock."
• "Threshold discussions reopen only with new data or post-incident review findings."

Bad residue

• "Fixed it."
• "We discussed a lot of options."
• ""

---

Invocation

bash ./.ages/skills/aggressive-schelling/scripts/schelling.sh post "<problem statement>"
bash ./.agents/skills/aggressive-schelling/scripts/schelling.sh follow_up "<cid>" "<learning>"

---

Final rule

When in doubt, lean toward discovering a reusable problem.

If there is a plausible chance that prior thought, a warning, a default, or an anti-pattern could help next time, post first.