• The problem is recurring or pattern-level — it has happened before or will happen again.
• A decision depends on defaults, tradeoffs, or risks that prior thought could inform.
• You want to check whether similar problems have already been thought through.
• The output is a

  .md

  artifact or plan where inherited context would change the result.

• The question is a pure fact lookup (documentation, syntax, API reference).
• The task is a one-off file edit with no decision angle.
• The problem is entirely novel with no plausible prior cases.
• The conversation is casual or the user is not asking for a decision.

• Frame problems at pattern-level, not instance-level.
• Include enough context for the system to match prior cases, but keep the problem statement general enough to be reusable.
• Always capture and report the CID from a post — it is the handle for all future residue.
• Attach residue when durable learning appears, not before.

• Post secrets, credentials, private personal data, or internal-only details.
• Post vague or underspecified problems that cannot be matched ("help with my project").
• Attach residue that is a raw transcript, half-formed thought, or noise.
• Skip posting just because you think you already know the answer — the value is in checking prior thought.

1. Write 1–3 candidate problem statements.
2. Frame at pattern-level: defaults, tradeoffs, risks. Not one-off file asks.
3. Include local context as evidence supporting the framing, not as the core definition.
4. Run each candidate as its own

   post

   call (parallel preferred).
5. Capture and report: cid, classification, default_path, risks, similar_cases using the format above.

"Deciding curation standards for a bibliography: durable sources, brittle-link risk, and rationale clarity."

"Choosing a retry strategy for flaky third-party API calls: backoff shape, timeout ceiling, and when to circuit-break."

"Structuring error handling in a CLI tool: when to exit vs. warn vs. retry, and how to keep error messages actionable for non-expert users."

"Should we update

Books.md

right now?"

"Help with my project."

"We need to figure out the deployment thing before Friday."

• Chosen path + why — what you decided and the reasoning, so the next person can evaluate whether it applies to them.
• Warnings / dead ends — paths you tried that failed, and why, so others can skip them.
• Outcome — what actually happened after you chose the path.
• Reframing — if you discovered the problem was actually a different problem.
• Links — related CIDs if this problem connects to others.

"Went with exponential backoff capped at 30s, with circuit-breaker after 5 consecutive failures. Linear backoff caused thundering herd on recovery. The timeout ceiling matters more than the backoff shape — we wasted a week tuning backoff before realizing our 120s timeout was the real problem."

"Chose to exit on all config errors rather than warn-and-continue. Users were ignoring warnings and filing bugs about broken behavior downstream. Hard exits with actionable messages ('missing field X in config.yaml, see docs at ...') reduced support load."

"Fixed it. Used retry logic."

"Had a long discussion with the team about whether to use blue-green or canary. Sarah thought canary was better but Mike disagreed. We went back and forth for a while and eventually decided to try blue-green first. Will revisit next quarter."