diff --git a/website/public/data/anchors.json b/website/public/data/anchors.json index 00d759d..5a08d8f 100644 --- a/website/public/data/anchors.json +++ b/website/public/data/anchors.json @@ -449,6 +449,37 @@ "filePath": "docs/anchors/cynefin-framework.adoc", "tier": 3 }, + { + "id": "decisional-balance-sheet", + "title": "Decisional Balance Sheet", + "categories": [ + "problem-solving", + "strategic-planning" + ], + "roles": [ + "consultant", + "team-lead", + "product-owner", + "business-analyst" + ], + "related": [ + "pugh-matrix", + "adr-according-to-nygard", + "moscow" + ], + "proponents": [ + "Irving Janis", + "Leon Mann" + ], + "tags": [ + "decision-making", + "pros-cons", + "ambivalence", + "motivational-interviewing" + ], + "filePath": "docs/anchors/decisional-balance-sheet.adoc", + "tier": 3 + }, { "id": "definition-of-done", "title": "Definition of Done", @@ -552,6 +583,38 @@ "filePath": "docs/anchors/domain-driven-design.adoc", "tier": 3 }, + { + "id": "double-diamond", + "title": "Double Diamond", + "categories": [ + "problem-solving", + "requirements-engineering" + ], + "roles": [ + "ux-designer", + "product-owner", + "business-analyst", + "consultant" + ], + "related": [ + "jobs-to-be-done", + "problem-space-nvc", + "xy-problem", + "mvp" + ], + "proponents": [ + "UK Design Council" + ], + "tags": [ + "design-thinking", + "problem-framing", + "divergent-convergent", + "ux", + "innovation" + ], + "filePath": "docs/anchors/double-diamond.adoc", + "tier": 3 + }, { "id": "ears-requirements", "title": "EARS-Requirements", @@ -1810,6 +1873,36 @@ "filePath": "docs/anchors/hexagonal-architecture.adoc", "tier": 3 }, + { + "id": "hoshin-kanri", + "title": "Hoshin Kanri", + "categories": [ + "strategic-planning" + ], + "roles": [ + "team-lead", + "consultant", + "product-owner" + ], + "related": [ + "kotter-8-step-change-model", + "moscow", + "kano-model" + ], + "proponents": [ + "Yoji Akao", + "Thomas L. Jackson" + ], + "tags": [ + "strategy-deployment", + "lean", + "alignment", + "x-matrix", + "catchball" + ], + "filePath": "docs/anchors/hoshin-kanri.adoc", + "tier": 3 + }, { "id": "iec-61508-sil-levels", "title": "IEC 61508 SIL Levels", @@ -1943,6 +2036,36 @@ "filePath": "docs/anchors/jobs-to-be-done.adoc", "tier": 3 }, + { + "id": "kano-model", + "title": "Kano Model", + "categories": [ + "strategic-planning", + "requirements-engineering" + ], + "roles": [ + "product-owner", + "business-analyst", + "ux-designer", + "team-lead" + ], + "related": [ + "moscow", + "jobs-to-be-done", + "ears-requirements" + ], + "proponents": [ + "Noriaki Kano" + ], + "tags": [ + "customer-satisfaction", + "feature-prioritization", + "product-management", + "requirements" + ], + "filePath": "docs/anchors/kano-model.adoc", + "tier": 3 + }, { "id": "kishotenketsu", "title": "Kishōtenketsu", @@ -2010,6 +2133,35 @@ "filePath": "docs/anchors/kiss-principle.adoc", "tier": 1 }, + { + "id": "kotter-8-step-change-model", + "title": "Kotter’s 8-Step Change Model", + "categories": [ + "strategic-planning" + ], + "roles": [ + "team-lead", + "consultant", + "product-owner", + "business-analyst" + ], + "related": [ + "swot", + "cynefin-framework", + "wardley-mapping" + ], + "proponents": [ + "John P. Kotter" + ], + "tags": [ + "change-management", + "transformation", + "leadership", + "organizational-change" + ], + "filePath": "docs/anchors/kotter-8-step-change-model.adoc", + "tier": 3 + }, { "id": "lasr", "title": "LASR according to Toth/Zörner", @@ -3696,6 +3848,140 @@ "filePath": "docs/anchors/what-would-chuck-norris-do.adoc", "tier": 3 }, + { + "id": "workflow-architecture-documentation", + "title": "Workflow: Architecture Documentation", + "categories": [ + "workflow" + ], + "roles": [ + "software-architect", + "technical-writer" + ], + "related": [], + "proponents": [ + "Ralf D. Müller", + "Gernot Starke", + "Michael Nygard" + ], + "tags": [], + "filePath": "docs/anchors/workflow-architecture-documentation.adoc", + "tier": 3 + }, + { + "id": "workflow-code-review", + "title": "Workflow: Structured Code Review", + "categories": [ + "workflow" + ], + "roles": [ + "software-developer", + "team-lead", + "qa-engineer" + ], + "related": [], + "proponents": [ + "Michael Fagan", + "Robert C. Martin" + ], + "tags": [], + "filePath": "docs/anchors/workflow-code-review.adoc", + "tier": 3 + }, + { + "id": "workflow-requirements-to-spec", + "title": "Workflow: Requirements to Specification", + "categories": [ + "workflow" + ], + "roles": [ + "business-analyst", + "product-owner", + "qa-engineer" + ], + "related": [], + "proponents": [ + "Dan North", + "Jeff Patton", + "Mike Cohn" + ], + "tags": [], + "filePath": "docs/anchors/workflow-requirements-to-spec.adoc", + "tier": 3 + }, + { + "id": "workflow-strategic-analysis", + "title": "Workflow: Strategic Architecture Analysis", + "categories": [ + "workflow" + ], + "roles": [ + "software-architect", + "consultant", + "team-lead" + ], + "related": [], + "proponents": [ + "Simon Wardley", + "Fritz Zwicky", + "Dave Snowden" + ], + "tags": [], + "filePath": "docs/anchors/workflow-strategic-analysis.adoc", + "tier": 3 + }, + { + "id": "workflow-tdd-clean-architecture", + "title": "Workflow: TDD with Clean Architecture", + "categories": [ + "workflow" + ], + "roles": [ + "software-developer", + "software-architect" + ], + "related": [], + "proponents": [ + "Robert C. Martin", + "Steve Freeman", + "Nat Pryce" + ], + "tags": [], + "filePath": "docs/anchors/workflow-tdd-clean-architecture.adoc", + "tier": 3 + }, + { + "id": "xy-problem", + "title": "XY Problem", + "categories": [ + "dialogue-interaction", + "problem-solving" + ], + "roles": [ + "software-developer", + "team-lead", + "consultant", + "business-analyst" + ], + "related": [ + "socratic-method", + "bluf", + "problem-space-nvc" + ], + "proponents": [ + "Mark Jason Dominus", + "Eric S. Raymond" + ], + "tags": [ + "communication", + "troubleshooting", + "requirements", + "problem-framing", + "anti-pattern" + ], + "filePath": "docs/anchors/xy-problem.adoc", + "tier": 3 + }, { "id": "yagni", "title": "YAGNI (You Aren’t Gonna Need It)", diff --git a/website/public/data/categories.json b/website/public/data/categories.json index f676206..7c110e3 100644 --- a/website/public/data/categories.json +++ b/website/public/data/categories.json @@ -94,7 +94,8 @@ "id": "dialogue-interaction", "name": "Dialogue Interaction", "anchors": [ - "socratic-method" + "socratic-method", + "xy-problem" ] }, { @@ -127,12 +128,15 @@ "name": "Problem Solving", "anchors": [ "chain-of-thought", + "decisional-balance-sheet", "devils-advocate", + "double-diamond", "feynman-technique", "five-whys", "morphological-box", "occams-razor", - "what-would-chuck-norris-do" + "what-would-chuck-norris-do", + "xy-problem" ] }, { @@ -140,8 +144,10 @@ "name": "Requirements Engineering", "anchors": [ "cockburn-use-cases", + "double-diamond", "ears-requirements", "invest", + "kano-model", "moscow", "prd", "problem-space-nvc", @@ -185,8 +191,12 @@ "name": "Strategic Planning", "anchors": [ "cynefin-framework", + "decisional-balance-sheet", + "hoshin-kanri", "impact-mapping", "jobs-to-be-done", + "kano-model", + "kotter-8-step-change-model", "mvp", "pert", "pugh-matrix", @@ -219,5 +229,16 @@ "test-double-stub", "testing-pyramid" ] + }, + { + "id": "workflow", + "name": "Workflow", + "anchors": [ + "workflow-architecture-documentation", + "workflow-code-review", + "workflow-requirements-to-spec", + "workflow-strategic-analysis", + "workflow-tdd-clean-architecture" + ] } ] \ No newline at end of file diff --git a/website/public/data/metadata.json b/website/public/data/metadata.json index 82b4de4..2eb43bd 100644 --- a/website/public/data/metadata.json +++ b/website/public/data/metadata.json @@ -1,15 +1,15 @@ { - "generatedAt": "2026-05-02T07:48:21.886Z", + "generatedAt": "2026-05-17T07:55:37.723Z", "version": "1.0.0", "counts": { - "anchors": 136, - "categories": 14, + "anchors": 147, + "categories": 15, "roles": 13 }, "statistics": { - "averageRolesPerAnchor": "3.17", - "averageCategoriesPerAnchor": "1.01", - "anchorsWithTags": 96, - "anchorsWithRelated": 67 + "averageRolesPerAnchor": "3.18", + "averageCategoriesPerAnchor": "1.03", + "anchorsWithTags": 102, + "anchorsWithRelated": 73 } } \ No newline at end of file diff --git a/website/public/data/roles.json b/website/public/data/roles.json index 2a12c50..258a025 100644 --- a/website/public/data/roles.json +++ b/website/public/data/roles.json @@ -7,7 +7,9 @@ "bluf", "chain-of-thought", "cockburn-use-cases", + "decisional-balance-sheet", "domain-driven-design", + "double-diamond", "ears-requirements", "gherkin", "gom", @@ -16,6 +18,8 @@ "invest", "iso-25010", "jobs-to-be-done", + "kano-model", + "kotter-8-step-change-model", "linddun", "mece", "moscow", @@ -27,7 +31,9 @@ "regulated-environment", "ssot-principle", "swot", - "user-story-mapping" + "user-story-mapping", + "workflow-requirements-to-spec", + "xy-problem" ] }, { @@ -40,7 +46,9 @@ "cohesion-criteria", "crc-cards", "cynefin-framework", + "decisional-balance-sheet", "devils-advocate", + "double-diamond", "feynman-technique", "fichtean-curve", "freytags-pyramid", @@ -49,10 +57,12 @@ "gutes-deutsch-wolf-schneider", "hemingway-bridge", "heros-journey", + "hoshin-kanri", "iec-61508-sil-levels", "impact-mapping", "kishotenketsu", "kiss-principle", + "kotter-8-step-change-model", "lasr", "linddun", "mece", @@ -80,6 +90,8 @@ "wardley-mapping", "what-qualifies-as-a-semantic-anchor", "what-would-chuck-norris-do", + "workflow-strategic-analysis", + "xy-problem", "yagni" ] }, @@ -165,13 +177,18 @@ "bdd-given-when-then", "cockburn-use-cases", "cynefin-framework", + "decisional-balance-sheet", "definition-of-done", + "double-diamond", "gherkin", "gtd", + "hoshin-kanri", "impact-mapping", "invest", "iso-25010", "jobs-to-be-done", + "kano-model", + "kotter-8-step-change-model", "morphological-box", "moscow", "mvp", @@ -184,7 +201,8 @@ "swot", "thin-vertical-slice", "user-story-mapping", - "wardley-mapping" + "wardley-mapping", + "workflow-requirements-to-spec" ] }, { @@ -217,7 +235,9 @@ "test-double-mock", "test-double-spy", "test-double-stub", - "testing-pyramid" + "testing-pyramid", + "workflow-code-review", + "workflow-requirements-to-spec" ] }, { @@ -308,6 +328,9 @@ "walking-skeleton", "wardley-mapping", "what-would-chuck-norris-do", + "workflow-architecture-documentation", + "workflow-strategic-analysis", + "workflow-tdd-clean-architecture", "yagni" ] }, @@ -411,6 +434,9 @@ "vertical-slice-architecture", "walking-skeleton", "what-would-chuck-norris-do", + "workflow-code-review", + "workflow-tdd-clean-architecture", + "xy-problem", "yagni" ] }, @@ -427,6 +453,7 @@ "code-smells", "control-chart-shewhart", "cynefin-framework", + "decisional-balance-sheet", "definition-of-done", "devils-advocate", "domain-driven-design", @@ -437,9 +464,12 @@ "github-flow", "gom", "gtd", + "hoshin-kanri", "impact-mapping", "invest", "iso-25010", + "kano-model", + "kotter-8-step-change-model", "lasr", "lehmans-classification", "madr", @@ -467,7 +497,10 @@ "user-story-mapping", "walking-skeleton", "wardley-mapping", - "what-would-chuck-norris-do" + "what-would-chuck-norris-do", + "workflow-code-review", + "workflow-strategic-analysis", + "xy-problem" ] }, { @@ -494,7 +527,8 @@ "save-the-cat", "story-circle-dan-harmon", "three-act-structure", - "todotxt-flavoured-markdown" + "todotxt-flavoured-markdown", + "workflow-architecture-documentation" ] }, { @@ -502,7 +536,9 @@ "name": "UX Designer / Researcher", "anchors": [ "bem-methodology", + "double-diamond", "jobs-to-be-done", + "kano-model", "myers-briggs-type-indicator", "problem-space-nvc", "user-story-mapping" diff --git a/website/public/llms.txt b/website/public/llms.txt index 5100f77..f940d2f 100644 --- a/website/public/llms.txt +++ b/website/public/llms.txt @@ -1,6 +1,6 @@ # Semantic Anchors — Complete Reference -> 137 well-defined terms, methodologies, and frameworks +> 152 well-defined terms, methodologies, and frameworks > that serve as precision reference points when communicating with LLMs. > Source: https://github.com/LLM-Coding/Semantic-Anchors > Website: https://llm-coding.github.io/Semantic-Anchors/ @@ -2660,6 +2660,52 @@ A class should have only one reason to change. Each module or class should be re * Constructivist learning theory * Critical thinking pedagogy +### XY Problem + +***Also known as***: Solution Fixation, Asking the Wrong Question + +[discrete] +## **Core Concepts**: + +***X is the Real Problem***: The underlying goal the asker actually wants to achieve + +***Y is the Attempted Solution***: The approach the asker has chosen, often based on an incomplete model of X + +***The Question Hides X***: The asker phrases their request as "How do I do Y?" — X is never stated, only assumed by the asker + +***Solution Fixation***: Commitment to Y obscures whether Y solves X at all, and may rule out simpler approaches + +***Goal-Step Confusion***: Conflating "what I want" with "the steps I think will get me there" + +***Recognition Heuristic***: Y looks unusual, brittle, or disproportionate to the questioner's apparent expertise — usually a sign that X is hidden + +***Resolution by Probing***: Ask "What are you actually trying to accomplish?" — surface X, then propose solutions for X (which may or may not include Y) + +***Asker's Discipline***: State X first, then your attempted Y, then the specific blocker — this lets the helper validate the whole chain + +***Key Proponents***: Mark Jason Dominus (coined the term in a 2001 post to comp.lang.perl.misc), Eric S. Raymond ("How To Ask Questions The Smart Way", 2001 — "describe the goal, not the step") + +***Historical Context***: Crystallized in Usenet and IRC help culture of the early 2000s; canonical reference at https://xyproblem.info/ and Greg's Wiki (mywiki.wooledge.org/XyProblem); now part of the standard vocabulary on Stack Overflow, Hacker News, and software help channels. + +[discrete] +## **When to Use**: + +* As a helper, when a question feels strange, over-specific, or asks for an awkward technical workaround — pause and ask for the underlying goal +* In LLM dialogues, to break out of solution-fixation when a model keeps trying to make Y work +* In requirements clarification, when a stakeholder demands a specific feature that looks like a workaround for an unstated need +* In code review, when a change looks like a hack — check whether the wrong problem is being solved +* In support tickets and bug reports, to redirect from "this UI doesn't let me do Y" toward "what task X were you doing?" +* As an asker, to discipline yourself to state the goal before the attempt + +[discrete] +## **Related Anchors**: + +* Socratic Method — questioning to surface the underlying problem +* BLUF — the asker's analogue: lead with the goal, not the step +* Problem Space (NVC) — distinguish needs from strategies, the same X/Y move from a Nonviolent Communication frame + +***Counter-example***: Concrete reproduction steps for a confirmed bug — the steps **are** the problem, not a workaround for it. + --- ## Documentation @@ -3077,6 +3123,47 @@ Let's solve this step by step: Therefore: [Conclusion] ``` +### Decisional Balance Sheet + +***Also known as***: Benjamin Franklin Analysis, Moral Algebra, Pros-and-Cons Sheet + +[discrete] +## **Core Concepts**: + +***Four-Cell Matrix***: The full Janis & Mann form has four categories of consequence for each alternative — **utilitarian gains/losses for self**, **utilitarian gains/losses for significant others**, **self-approval/disapproval**, and **approval/disapproval from others**. Stretches "pros and cons" beyond instrumental outcomes into identity and social cost. + +***Simplified Two-Column Form***: The everyday "pros vs cons" list popularised by Benjamin Franklin (1772 letter to Joseph Priestley). Strictly a degenerate case of the four-cell matrix — useful for quick decisions, lossy for complex ones. + +***Weighting***: Each entry gets a numeric weight reflecting its importance. The decision is **not** a vote count — the discipline is to make trade-offs explicit, not to mechanise the choice. + +***Resolving Ambivalence***: The artifact's primary purpose is **not** arithmetic but surfacing concerns the decider has not yet articulated. Listing the cons of a tempting option, or the pros of the rejected one, breaks the "all pros, no cons" framing that drives impulsive decisions. + +***Decisional Conflict***: Janis & Mann's parent theory; high-stakes decisions produce stress that distorts judgment. The balance sheet is one of several debiasing techniques alongside vigilant information search and contingency planning. + +***Motivational Interviewing Variant***: In the Prochaska–DiClemente **Stages of Change** model and Miller & Rollnick's **Motivational Interviewing**, the balance sheet is used to elicit change-talk: the client **says** the cons of staying the same and the pros of changing — moving them through ambivalence rather than persuading them. + +***Limits***: The model is **deliberative**, not intuitive. It works poorly under time pressure and for decisions dominated by uncertainty (where Pugh Matrix or scenario-based methods fit better). It also doesn't surface options that aren't on the list — separate from the option-generation step. + +***Key Proponents***: Irving Janis & Leon Mann ("Decision Making: A Psychological Analysis of Conflict, Choice, and Commitment", 1977 — the formal four-cell model). Benjamin Franklin (1772 letter, "moral algebra" — the informal pros/cons ancestor). William R. Miller & Stephen Rollnick ("Motivational Interviewing", 1991) for the clinical adaptation. + +***Historical Context***: Franklin's pros/cons letter is one of the earliest documented decision-aid techniques in the Western tradition. Janis & Mann turned it into a research instrument in the 1970s; the simplified two-column form has spread through self-help, coaching, and Motivational Interviewing into mainstream use. Now a staple of decision coaching, financial advisory, and health-behaviour-change interventions. + +[discrete] +## **When to Use**: + +* Personal or career decisions where the alternatives are roughly comparable and the deciding factor is the decider's own clarity +* Coaching conversations where the client is **stuck in ambivalence** — the four-cell version surfaces concerns the simple pros/cons list misses +* Pre-mortem variant: pre-listing the "approval/disapproval from others" cell often predicts political resistance the team forgot to address +* Motivational Interviewing settings — health behaviour, addiction recovery, career changes +* Decision documentation in low-formality contexts where a full ADR is overkill but "we considered the alternatives" must be visible + +[discrete] +## **Related Anchors**: + +* Pugh Matrix — scores alternatives against weighted criteria; complement when uncertainty or technical trade-offs dominate over personal/social cost +* ADR according to Nygard — captures architecture decisions with Context/Decision/Consequences; the balance sheet feeds the Consequences section +* MoSCoW — prioritisation among items chosen **after** the decision is made; the balance sheet helps decide **whether** to do the work at all + ### Devil's Advocate ***Full Name***: Devil's Advocate (Latin: **Advocatus Diaboli**) @@ -3132,6 +3219,54 @@ I propose [idea/design/decision]. Play devil's advocate: What are the strongest arguments against this approach? ``` +### Double Diamond + +***Full Name***: Double Diamond Design Process Model + +***Also known as***: 4Ds Model, Design Council Double Diamond + +[discrete] +## **Core Concepts**: + +***Two Diamonds, Four Phases***: **Discover → Define → Develop → Deliver**. Each diamond is one divergent-convergent cycle. The first diamond explores and frames the **problem**; the second diamond explores and ships the **solution**. + +***Discover (Divergent, Problem Space)***: Broad research — interviews, observation, immersion, data analysis. Goal: widen the understanding of what's actually going on, not jump to causes. + +***Define (Convergent, Problem Space)***: Synthesize findings into a sharp problem statement. The famous slogan: **"Are we solving the right problem?"** — the diamond ends with a problem worth solving, not a list of features. + +***Develop (Divergent, Solution Space)***: Generate many candidate solutions — sketches, prototypes, co-design workshops. Diverge widely before narrowing; resist solution fixation. + +***Deliver (Convergent, Solution Space)***: Test, refine, ship. The chosen concept is iterated until it's production-ready; failed candidates are explicitly killed rather than left lingering. + +***Design the Right Thing, Then Design the Thing Right***: The canonical summary. The first diamond addresses "right thing" (problem worth solving); the second addresses "thing right" (solution that works). + +***Divergent Before Convergent***: A hard discipline at every phase. Premature convergence — picking the obvious problem or obvious solution — is the failure mode the model is designed to prevent. + +***Iteration, Not Waterfall***: The diamonds are not strictly linear. Learnings in Develop frequently send the team back to Discover or Define. The 2019 **Framework for Innovation** update made this explicit. + +***Mindsets and Principles***: The Design Council pairs the four phases with four principles (Put people first, Communicate visually and inclusively, Collaborate and co-create, Iterate, iterate, iterate) — the diamonds without the mindset is just process theater. + +***Key Proponents***: UK Design Council (originally published 2005; expanded as **Framework for Innovation** in 2019). Built on the divergent-convergent tradition of J.P. Guilford (1956) and Béla H. Bánáthy. + +***Historical Context***: Developed by the Design Council in 2005 after research into how leading design organizations actually worked. The 2019 update reframed it as a system-level innovation framework, adding the principles, key roles, and explicit iteration arrows. Adopted broadly in UX, service design, government innovation (UK GDS, NHS, Danish Mindlab), and design education. + +[discrete] +## **When to Use**: + +* Framing UX or service design projects when the team is at risk of jumping to solutions +* Innovation workshops and design sprints — the diamonds give a shared visual model for sequencing divergent and convergent work +* Discovery phases of product development when the problem itself is not yet well understood +* Teaching design thinking — the model is more concrete than abstract "design thinking" because it names the four moves +* Communicating **why** a discovery phase is necessary to stakeholders who want to skip straight to delivery + +[discrete] +## **Related Anchors**: + +* Jobs to be Done — sharpens the **Define** output by reframing customer needs as functional, emotional, and social jobs +* Problem Space (NVC) — separates needs from strategies; complements the first-diamond discipline of staying in problem space +* XY Problem — anti-pattern that the first diamond is designed to prevent (solving Y before understanding X) +* MVP — the **Deliver** output is often shaped as an MVP to validate the chosen solution against the defined problem + ### Feynman Technique ***Full Name***: Feynman Technique (also Feynman Learning Method) @@ -3427,6 +3562,52 @@ GPT-5.3 Codex activates the decisiveness signal but **not** the character voice * YAGNI - Both resist ceremony and speculative complexity * Occam's Razor - Occam selects the most parsimonious **explanation**; WWCND commits to the most direct **response** +### XY Problem + +***Also known as***: Solution Fixation, Asking the Wrong Question + +[discrete] +## **Core Concepts**: + +***X is the Real Problem***: The underlying goal the asker actually wants to achieve + +***Y is the Attempted Solution***: The approach the asker has chosen, often based on an incomplete model of X + +***The Question Hides X***: The asker phrases their request as "How do I do Y?" — X is never stated, only assumed by the asker + +***Solution Fixation***: Commitment to Y obscures whether Y solves X at all, and may rule out simpler approaches + +***Goal-Step Confusion***: Conflating "what I want" with "the steps I think will get me there" + +***Recognition Heuristic***: Y looks unusual, brittle, or disproportionate to the questioner's apparent expertise — usually a sign that X is hidden + +***Resolution by Probing***: Ask "What are you actually trying to accomplish?" — surface X, then propose solutions for X (which may or may not include Y) + +***Asker's Discipline***: State X first, then your attempted Y, then the specific blocker — this lets the helper validate the whole chain + +***Key Proponents***: Mark Jason Dominus (coined the term in a 2001 post to comp.lang.perl.misc), Eric S. Raymond ("How To Ask Questions The Smart Way", 2001 — "describe the goal, not the step") + +***Historical Context***: Crystallized in Usenet and IRC help culture of the early 2000s; canonical reference at https://xyproblem.info/ and Greg's Wiki (mywiki.wooledge.org/XyProblem); now part of the standard vocabulary on Stack Overflow, Hacker News, and software help channels. + +[discrete] +## **When to Use**: + +* As a helper, when a question feels strange, over-specific, or asks for an awkward technical workaround — pause and ask for the underlying goal +* In LLM dialogues, to break out of solution-fixation when a model keeps trying to make Y work +* In requirements clarification, when a stakeholder demands a specific feature that looks like a workaround for an unstated need +* In code review, when a change looks like a hack — check whether the wrong problem is being solved +* In support tickets and bug reports, to redirect from "this UI doesn't let me do Y" toward "what task X were you doing?" +* As an asker, to discipline yourself to state the goal before the attempt + +[discrete] +## **Related Anchors**: + +* Socratic Method — questioning to surface the underlying problem +* BLUF — the asker's analogue: lead with the goal, not the step +* Problem Space (NVC) — distinguish needs from strategies, the same X/Y move from a Nonviolent Communication frame + +***Counter-example***: Concrete reproduction steps for a confirmed bug — the steps **are** the problem, not a workaround for it. + --- ## Requirements Engineering @@ -3480,6 +3661,54 @@ Cockburn's format is deliberately **prose-based and notation-agnostic**. It does * arc42 - Use cases feed Section 6 (Runtime View) and inform Section 3 (Context and Scope) * ISO 25010 - Quality goals that use case extensions should address (error handling, performance, security) +### Double Diamond + +***Full Name***: Double Diamond Design Process Model + +***Also known as***: 4Ds Model, Design Council Double Diamond + +[discrete] +## **Core Concepts**: + +***Two Diamonds, Four Phases***: **Discover → Define → Develop → Deliver**. Each diamond is one divergent-convergent cycle. The first diamond explores and frames the **problem**; the second diamond explores and ships the **solution**. + +***Discover (Divergent, Problem Space)***: Broad research — interviews, observation, immersion, data analysis. Goal: widen the understanding of what's actually going on, not jump to causes. + +***Define (Convergent, Problem Space)***: Synthesize findings into a sharp problem statement. The famous slogan: **"Are we solving the right problem?"** — the diamond ends with a problem worth solving, not a list of features. + +***Develop (Divergent, Solution Space)***: Generate many candidate solutions — sketches, prototypes, co-design workshops. Diverge widely before narrowing; resist solution fixation. + +***Deliver (Convergent, Solution Space)***: Test, refine, ship. The chosen concept is iterated until it's production-ready; failed candidates are explicitly killed rather than left lingering. + +***Design the Right Thing, Then Design the Thing Right***: The canonical summary. The first diamond addresses "right thing" (problem worth solving); the second addresses "thing right" (solution that works). + +***Divergent Before Convergent***: A hard discipline at every phase. Premature convergence — picking the obvious problem or obvious solution — is the failure mode the model is designed to prevent. + +***Iteration, Not Waterfall***: The diamonds are not strictly linear. Learnings in Develop frequently send the team back to Discover or Define. The 2019 **Framework for Innovation** update made this explicit. + +***Mindsets and Principles***: The Design Council pairs the four phases with four principles (Put people first, Communicate visually and inclusively, Collaborate and co-create, Iterate, iterate, iterate) — the diamonds without the mindset is just process theater. + +***Key Proponents***: UK Design Council (originally published 2005; expanded as **Framework for Innovation** in 2019). Built on the divergent-convergent tradition of J.P. Guilford (1956) and Béla H. Bánáthy. + +***Historical Context***: Developed by the Design Council in 2005 after research into how leading design organizations actually worked. The 2019 update reframed it as a system-level innovation framework, adding the principles, key roles, and explicit iteration arrows. Adopted broadly in UX, service design, government innovation (UK GDS, NHS, Danish Mindlab), and design education. + +[discrete] +## **When to Use**: + +* Framing UX or service design projects when the team is at risk of jumping to solutions +* Innovation workshops and design sprints — the diamonds give a shared visual model for sequencing divergent and convergent work +* Discovery phases of product development when the problem itself is not yet well understood +* Teaching design thinking — the model is more concrete than abstract "design thinking" because it names the four moves +* Communicating **why** a discovery phase is necessary to stakeholders who want to skip straight to delivery + +[discrete] +## **Related Anchors**: + +* Jobs to be Done — sharpens the **Define** output by reframing customer needs as functional, emotional, and social jobs +* Problem Space (NVC) — separates needs from strategies; complements the first-diamond discipline of staying in problem space +* XY Problem — anti-pattern that the first diamond is designed to prevent (solving Y before understanding X) +* MVP — the **Deliver** output is often shaped as an MVP to validate the chosen solution against the defined problem + ### EARS-Requirements ***Full Name***: Easy Approach to Requirements Syntax @@ -3550,6 +3779,54 @@ INVEST = **I**ndependent / **N**egotiable / **V**aluable / **E**stimable / **S** * User Story Mapping * MoSCoW +### Kano Model + +***Also known as***: Kano Analysis, Kano-Modell, Customer Satisfaction Model + +[discrete] +## **Core Concepts**: + +***Two-dimensional Quality***: Customer satisfaction is not the simple inverse of dissatisfaction — they are two separate axes (presence/absence of a feature × resulting satisfaction) + +***Five Feature Categories***: Every feature falls into one of five classes that map differently onto the satisfaction curve + +***Must-be (Basic, Threshold)***: Expected baseline — absence causes strong dissatisfaction, presence is taken for granted and earns no credit (e.g., car has wheels, app does not lose data) + +***One-dimensional (Performance, Linear)***: Satisfaction grows roughly linearly with how well the feature is delivered (e.g., fuel efficiency, response time, battery life) + +***Attractive (Excitement, Delighter)***: Unexpected — absence causes no dissatisfaction, presence delights and differentiates (e.g., a thoughtful onboarding gesture, a surprising shortcut) + +***Indifferent***: Customer does not care either way — flag for cost reduction + +***Reverse***: Presence actually causes dissatisfaction for the target segment — flag for removal or segmentation + +***Functional / Dysfunctional Questionnaire***: For each candidate feature, ask the user two paired questions: "How would you feel if this feature were present?" and "How would you feel if it were absent?". The cross-tab of answers maps the feature to one of the five categories + +***Time Decay***: Categories migrate over time. Today's **Delighter** becomes tomorrow's **Performer** and eventually a **Must-be** as the market matures (mobile camera, HTTPS, dark mode) + +***Key Proponent***: Noriaki Kano (Tokyo University of Science), originally published in 1984 in the Japanese journal **Hinshitsu** ("Quality") + +***Historical Context***: Developed in the context of Japanese quality management, alongside Total Quality Management and the Kaizen movement; widely adopted in product management, UX research, and requirements engineering since the late 1990s. + +[discrete] +## **When to Use**: + +* Prioritising features in a product backlog beyond raw business value +* Distinguishing the "non-negotiables" (Must-be) from the "wow features" (Delighter) before estimation +* User research where you need to understand **why** a feature affects satisfaction, not just whether users like it +* MVP scoping: ensure all **Must-be** features are covered before investing in **Delighters** +* Product strategy reviews: spot **Delighters** that have decayed into **Performers** or **Must-be** and update positioning +* Combining with **MoSCoW Method** — Must-be → Must, Performance → Should, Delighter → Could + +[discrete] +## **Related Anchors**: + +* MoSCoW Method — complementary prioritisation lens (organisation-driven), often combined with Kano (customer-driven) +* Jobs To Be Done — discovery side: what job is the customer hiring the feature for, before classifying its impact +* EARS Requirements — once a feature is classified as Must-be, EARS gives it the unambiguous wording + +***Counter-example***: Pure ROI-based ranking — useful but blind to the asymmetry between dissatisfaction (Must-be) and delight (Attractive). Kano corrects that. + ### MoSCoW ***Full Name***: MoSCoW Prioritization Method @@ -4581,6 +4858,92 @@ Lehman derived eight laws from observing E-type systems, including **Continuing * Wardley Mapping +### Decisional Balance Sheet + +***Also known as***: Benjamin Franklin Analysis, Moral Algebra, Pros-and-Cons Sheet + +[discrete] +## **Core Concepts**: + +***Four-Cell Matrix***: The full Janis & Mann form has four categories of consequence for each alternative — **utilitarian gains/losses for self**, **utilitarian gains/losses for significant others**, **self-approval/disapproval**, and **approval/disapproval from others**. Stretches "pros and cons" beyond instrumental outcomes into identity and social cost. + +***Simplified Two-Column Form***: The everyday "pros vs cons" list popularised by Benjamin Franklin (1772 letter to Joseph Priestley). Strictly a degenerate case of the four-cell matrix — useful for quick decisions, lossy for complex ones. + +***Weighting***: Each entry gets a numeric weight reflecting its importance. The decision is **not** a vote count — the discipline is to make trade-offs explicit, not to mechanise the choice. + +***Resolving Ambivalence***: The artifact's primary purpose is **not** arithmetic but surfacing concerns the decider has not yet articulated. Listing the cons of a tempting option, or the pros of the rejected one, breaks the "all pros, no cons" framing that drives impulsive decisions. + +***Decisional Conflict***: Janis & Mann's parent theory; high-stakes decisions produce stress that distorts judgment. The balance sheet is one of several debiasing techniques alongside vigilant information search and contingency planning. + +***Motivational Interviewing Variant***: In the Prochaska–DiClemente **Stages of Change** model and Miller & Rollnick's **Motivational Interviewing**, the balance sheet is used to elicit change-talk: the client **says** the cons of staying the same and the pros of changing — moving them through ambivalence rather than persuading them. + +***Limits***: The model is **deliberative**, not intuitive. It works poorly under time pressure and for decisions dominated by uncertainty (where Pugh Matrix or scenario-based methods fit better). It also doesn't surface options that aren't on the list — separate from the option-generation step. + +***Key Proponents***: Irving Janis & Leon Mann ("Decision Making: A Psychological Analysis of Conflict, Choice, and Commitment", 1977 — the formal four-cell model). Benjamin Franklin (1772 letter, "moral algebra" — the informal pros/cons ancestor). William R. Miller & Stephen Rollnick ("Motivational Interviewing", 1991) for the clinical adaptation. + +***Historical Context***: Franklin's pros/cons letter is one of the earliest documented decision-aid techniques in the Western tradition. Janis & Mann turned it into a research instrument in the 1970s; the simplified two-column form has spread through self-help, coaching, and Motivational Interviewing into mainstream use. Now a staple of decision coaching, financial advisory, and health-behaviour-change interventions. + +[discrete] +## **When to Use**: + +* Personal or career decisions where the alternatives are roughly comparable and the deciding factor is the decider's own clarity +* Coaching conversations where the client is **stuck in ambivalence** — the four-cell version surfaces concerns the simple pros/cons list misses +* Pre-mortem variant: pre-listing the "approval/disapproval from others" cell often predicts political resistance the team forgot to address +* Motivational Interviewing settings — health behaviour, addiction recovery, career changes +* Decision documentation in low-formality contexts where a full ADR is overkill but "we considered the alternatives" must be visible + +[discrete] +## **Related Anchors**: + +* Pugh Matrix — scores alternatives against weighted criteria; complement when uncertainty or technical trade-offs dominate over personal/social cost +* ADR according to Nygard — captures architecture decisions with Context/Decision/Consequences; the balance sheet feeds the Consequences section +* MoSCoW — prioritisation among items chosen **after** the decision is made; the balance sheet helps decide **whether** to do the work at all + +### Hoshin Kanri + +***Full Name***: Hoshin Kanri (方針管理 — "direction management") + +***Also known as***: Policy Deployment, Strategy Deployment, Hoshin Planning + +[discrete] +## **Core Concepts**: + +***True North***: The 3-5 year **breakthrough objectives** that define where the organization must be — chosen sparingly so the whole company can pull in the same direction. + +***Annual Hoshin***: The 1-year priorities derived from True North. Typically 3-5 organization-wide goals; everything else is "business as usual" and not on the hoshin. + +***X-Matrix***: Single-page A3 artifact that links four legs — **long-term strategy**, **annual objectives**, **improvement priorities**, and **metrics/targets** — plus the accountable owners. Correlations between legs are made explicit with symbols (strong/medium/weak). + +***Catchball***: Iterative two-way negotiation of goals between levels. Leadership proposes targets; teams respond with "what's possible and what's needed"; the ball passes back and forth until commitments are realistic **and** ambitious. Distinguishes Hoshin Kanri from top-down cascades. + +***PDCA for Strategy***: Plan-Do-Check-Act applied to the annual hoshin itself — monthly or quarterly **check** reviews ensure the strategy adapts to reality, not just the tactics. + +***Cascade and Alignment***: Each level translates the level above into its own X-Matrix. Vertical alignment is verified at every step; horizontal alignment is verified across peer teams to prevent local optimization. + +***Bowling Chart / Hoshin Review***: Monthly status board comparing actual vs target for each KPI; red/yellow/green status forces conversations about countermeasures rather than excuses. + +***Few Vital, Not Many Trivial***: A core discipline — restrict the hoshin to the small number of goals that **require** breakthrough thinking. Most organizational work continues outside the hoshin process. + +***Key Proponents***: Yoji Akao ("Hoshin Kanri: Policy Deployment for Successful TQM", 1991), Thomas L. Jackson ("Hoshin Kanri for the Lean Enterprise", 2006), Pascal Dennis ("Getting the Right Things Done", 2006) + +***Historical Context***: Emerged in Japanese manufacturing in the 1960s; Bridgestone Tire is widely credited with the first formalized use after winning the Deming Prize. Spread through Toyota, Komatsu, and the broader TQM movement; translated to Western practice in the 1980s as part of Lean. Now widely adopted in Lean enterprises, healthcare systems (Virginia Mason), and increasingly in scaled agile contexts. + +[discrete] +## **When to Use**: + +* Annual or multi-year strategic planning when alignment across many teams is the critical risk +* Translating a vision or mission into measurable, accountable work +* Scaling an organization where local optimization is starting to dominate over global goals +* Lean transformations — Hoshin Kanri is the strategy-layer counterpart to Kaizen at the operational layer +* As an alternative to OKRs when the organization needs explicit cause-and-effect links and stronger accountability than quarterly self-set objectives provide + +[discrete] +## **Related Anchors**: + +* Kotter's 8-Step Change Model — large-scale transformation framework; Hoshin Kanri is the recurring discipline that operationalizes a Kotter-style vision year after year +* MoSCoW — tactical prioritization within the hoshin's improvement priorities +* Kano Model — feature classification that often feeds the customer-facing leg of the X-Matrix + ### Impact Mapping ***Full Name***: Impact Mapping according to Gojko Adzic @@ -4652,6 +5015,103 @@ Lehman derived eight laws from observing E-type systems, including **Continuing * Writing more meaningful user stories * Market segmentation based on jobs, not demographics +### Kano Model + +***Also known as***: Kano Analysis, Kano-Modell, Customer Satisfaction Model + +[discrete] +## **Core Concepts**: + +***Two-dimensional Quality***: Customer satisfaction is not the simple inverse of dissatisfaction — they are two separate axes (presence/absence of a feature × resulting satisfaction) + +***Five Feature Categories***: Every feature falls into one of five classes that map differently onto the satisfaction curve + +***Must-be (Basic, Threshold)***: Expected baseline — absence causes strong dissatisfaction, presence is taken for granted and earns no credit (e.g., car has wheels, app does not lose data) + +***One-dimensional (Performance, Linear)***: Satisfaction grows roughly linearly with how well the feature is delivered (e.g., fuel efficiency, response time, battery life) + +***Attractive (Excitement, Delighter)***: Unexpected — absence causes no dissatisfaction, presence delights and differentiates (e.g., a thoughtful onboarding gesture, a surprising shortcut) + +***Indifferent***: Customer does not care either way — flag for cost reduction + +***Reverse***: Presence actually causes dissatisfaction for the target segment — flag for removal or segmentation + +***Functional / Dysfunctional Questionnaire***: For each candidate feature, ask the user two paired questions: "How would you feel if this feature were present?" and "How would you feel if it were absent?". The cross-tab of answers maps the feature to one of the five categories + +***Time Decay***: Categories migrate over time. Today's **Delighter** becomes tomorrow's **Performer** and eventually a **Must-be** as the market matures (mobile camera, HTTPS, dark mode) + +***Key Proponent***: Noriaki Kano (Tokyo University of Science), originally published in 1984 in the Japanese journal **Hinshitsu** ("Quality") + +***Historical Context***: Developed in the context of Japanese quality management, alongside Total Quality Management and the Kaizen movement; widely adopted in product management, UX research, and requirements engineering since the late 1990s. + +[discrete] +## **When to Use**: + +* Prioritising features in a product backlog beyond raw business value +* Distinguishing the "non-negotiables" (Must-be) from the "wow features" (Delighter) before estimation +* User research where you need to understand **why** a feature affects satisfaction, not just whether users like it +* MVP scoping: ensure all **Must-be** features are covered before investing in **Delighters** +* Product strategy reviews: spot **Delighters** that have decayed into **Performers** or **Must-be** and update positioning +* Combining with **MoSCoW Method** — Must-be → Must, Performance → Should, Delighter → Could + +[discrete] +## **Related Anchors**: + +* MoSCoW Method — complementary prioritisation lens (organisation-driven), often combined with Kano (customer-driven) +* Jobs To Be Done — discovery side: what job is the customer hiring the feature for, before classifying its impact +* EARS Requirements — once a feature is classified as Must-be, EARS gives it the unambiguous wording + +***Counter-example***: Pure ROI-based ranking — useful but blind to the asymmetry between dissatisfaction (Must-be) and delight (Attractive). Kano corrects that. + +### Kotter's 8-Step Change Model + +***Also known as***: Kotter's 8 Steps for Leading Change, Kotter's Change Process + +[discrete] +## **Core Concepts**: + +***Step 1 — Establish a Sense of Urgency***: Surface the threats and opportunities that make change necessary now; without urgency, the organisation defaults to the status quo + +***Step 2 — Form a Guiding Coalition***: Assemble a powerful enough cross-functional group with the credibility, authority and energy to lead the effort; lone champions fail + +***Step 3 — Develop a Vision and Strategy***: Create a clear, compelling vision of the future state and a strategy to reach it; the vision must be simple enough to communicate in five minutes + +***Step 4 — Communicate the Change Vision***: Use every channel and repeat the vision constantly; walk the talk — leadership behaviour speaks louder than memos + +***Step 5 — Empower Broad-based Action***: Remove the obstacles that block change — outdated structures, misaligned incentives, fearful middle management; enable people to act on the vision + +***Step 6 — Generate Short-term Wins***: Plan, create and visibly celebrate quick, unambiguous improvements within 6–18 months; wins fund credibility and silence sceptics + +***Step 7 — Consolidate Gains and Produce More Change***: Use the credibility from short-term wins to tackle bigger systems, structures and policies; do not declare victory too early + +***Step 8 — Anchor the Changes in Corporate Culture***: Make the new approaches "the way we do things around here" by tying them to leadership succession, hiring, onboarding and storytelling + +***The 8 Errors***: The model is the inversion of the **eight common errors** Kotter identified in failed transformations: complacency, no powerful coalition, underestimating vision, undercommunicating, ignoring obstacles, no short-term wins, premature victory, and not anchoring change in culture + +***Linear but Iterative***: Kotter presents the steps as sequential because each step builds on the credibility and infrastructure of the previous ones, but in practice teams loop within and across steps as the change scales + +***Key Proponent***: John P. Kotter (Harvard Business School), introduced in the 1995 **Harvard Business Review** article **"Leading Change: Why Transformation Efforts Fail"** and expanded in the 1996 book **Leading Change** (Harvard Business Press) + +***Historical Context***: One of the most cited change management frameworks in business literature; widely used in M&A integrations, digital transformations, agile rollouts and culture change programmes; later complemented by Kotter's 2014 **Accelerate** (XLR8), which adds a "dual operating system" of hierarchy plus network for continuous change + +[discrete] +## **When to Use**: + +* Planning a non-trivial organisational change (digital transformation, agile rollout, restructuring, M&A integration) +* Diagnosing why a stalled transformation is stalled — which of the 8 errors is biting? +* Sequencing communication and intervention activities so that quick wins land before the political resistance forms +* Stakeholder analysis and coalition building before kicking off a change initiative +* Reviewing whether a "completed" change is actually anchored in culture, or just a temporary policy + +[discrete] +## **Related Anchors**: + +* SWOT — strategic analysis to feed the urgency and vision steps +* Cynefin Framework — choose the right approach (Clear / Complicated / Complex / Chaotic) for the kind of change you face +* Wardley Mapping — visualise where change is needed in the value chain before defining the vision + +***Counter-example***: Pure top-down mandate ("from Monday we will be agile") — Kotter's whole point is that without urgency, coalition, vision and short-term wins, the mandate produces compliance theatre, not change. + ### Minimum Viable Product (MVP) ***Full Name***: Minimum Viable Product @@ -5624,6 +6084,145 @@ SWOT = **S**trengths / **W**eaknesses / **O**pportunities / **T**hreats --- +## Workflow + +### Workflow: Architecture Documentation + +[discrete] +## **Core Concepts**: + +***arc42 template***: 12 sections for comprehensive architecture docs + +***Docs-as-Code***: Documentation in the repo, versioned, reviewed, CI-built + +***ADR according to Nygard***: Lightweight decision records (Context, Decision, Consequences) + +***Pugh Matrix***: 3-point scale (-1, 0, +1) for comparing architecture alternatives + +***docToolchain***: Gradle-based toolchain for AsciiDoc pipelines + +[discrete] +## **When to Use**: + +* Starting a new project that needs architecture documentation +* Migrating from Confluence/Wiki to Docs-as-Code +* When architecture decisions need to be traceable + +[discrete] +## **Combined Prompt**: + +Create an arc42 architecture documentation using the Docs-as-Code approach. Include ADRs according to Nygard for all key decisions, each with a 3-point (-1, 0, +1) Pugh Matrix comparing alternatives. + +### Workflow: Structured Code Review + +[discrete] +## **Core Concepts**: + +***SOLID Principles***: Check for SRP, OCP, LSP, ISP, DIP violations + +***Clean Architecture***: Verify dependency direction (inward only) + +***Conventional Commits***: Commit messages follow type(scope): description + +***Fagan Inspection***: Structured review with defined roles and phases + +***OWASP Top 10***: Security checklist for common vulnerabilities + +[discrete] +## **When to Use**: + +* Pull request reviews +* Architecture review sessions +* Security-focused code audits + +[discrete] +## **Combined Prompt**: + +Review this code against SOLID Principles. Check that dependencies follow Clean Architecture rules (inward only). Verify commit messages follow Conventional Commits. Flag any OWASP Top 10 security issues. + +### Workflow: Requirements to Specification + +[discrete] +## **Core Concepts**: + +***User Story Mapping***: Backbone + walking skeleton for release planning + +***INVEST Criteria***: Independent, Negotiable, Valuable, Estimable, Small, Testable + +***BDD / Gherkin***: Given-When-Then scenarios as executable specifications + +***MoSCoW Prioritization***: Must, Should, Could, Won't for scope decisions + +***Definition of Done***: Shared checklist for "really done" + +[discrete] +## **When to Use**: + +* Starting a new product or major feature +* When business and dev teams need shared understanding +* Transitioning from ad-hoc requirements to structured specs + +[discrete] +## **Combined Prompt**: + +Create a User Story Map for this feature. Prioritize stories using MoSCoW. For each Must-have story, verify it meets INVEST criteria and write BDD scenarios in Gherkin (Given-When-Then). Define a clear Definition of Done. + +### Workflow: Strategic Architecture Analysis + +[discrete] +## **Core Concepts**: + +***Wardley Mapping***: Map value chain + evolution for strategic positioning + +***Cynefin Framework***: Categorize situation (Simple, Complicated, Complex, Chaotic) + +***Morphological Box***: Explore solution space systematically + +***ATAM***: Architecture Tradeoff Analysis Method for quality evaluation + +***Five Whys***: Root cause analysis for architecture problems + +[discrete] +## **When to Use**: + +* Evaluating build-vs-buy decisions +* Assessing architecture fitness for changing requirements +* Strategic technology radar reviews + +[discrete] +## **Combined Prompt**: + +Analyze this system using Wardley Mapping to understand component evolution. Categorize each challenge using the Cynefin Framework. For complex decisions, use a Morphological Box to explore alternatives, then evaluate tradeoffs with ATAM. + +### Workflow: TDD with Clean Architecture + +[discrete] +## **Core Concepts**: + +***TDD, London School***: Outside-in, mock-heavy, interface discovery + +***Clean Architecture***: Dependency Rule — inner layers don't know outer layers + +***SOLID Principles***: SRP, OCP, LSP, ISP, DIP guide class design + +***Hexagonal Architecture***: Ports & Adapters separate domain from infrastructure + +***Testing Pyramid***: Many unit tests, fewer integration, fewest E2E + +[discrete] +## **When to Use**: + +* Building a new service with complex business logic +* When testability is a primary architecture driver +* Refactoring a legacy codebase toward clean boundaries + +[discrete] +## **Combined Prompt**: + +Implement this feature using TDD London School with Clean Architecture. Start outside-in: write a failing acceptance test, then drive the implementation through the layers. Apply SOLID principles and keep the domain free of framework dependencies. + +--- + # Semantic Contracts diff --git a/website/public/sitemap.xml b/website/public/sitemap.xml index 0f1d400..5396d51 100644 --- a/website/public/sitemap.xml +++ b/website/public/sitemap.xml @@ -2,98 +2,98 @@ https://llm-coding.github.io/Semantic-Anchors/ - 2026-05-14 + 2026-05-17 weekly 1.0 https://llm-coding.github.io/Semantic-Anchors/about - 2026-05-14 + 2026-05-17 monthly 0.8 https://llm-coding.github.io/Semantic-Anchors/spec-driven-development - 2026-05-14 + 2026-05-17 monthly 0.8 https://llm-coding.github.io/Semantic-Anchors/brownfield - 2026-05-14 + 2026-05-17 monthly 0.8 https://llm-coding.github.io/Semantic-Anchors/brownfield-experiment-report - 2026-05-14 + 2026-05-17 monthly 0.7 https://llm-coding.github.io/Semantic-Anchors/brownfield-fair-comparison - 2026-05-14 + 2026-05-17 monthly 0.7 https://llm-coding.github.io/Semantic-Anchors/socratic-recovery-skill - 2026-05-14 + 2026-05-17 monthly 0.7 https://llm-coding.github.io/Semantic-Anchors/contracts - 2026-05-14 + 2026-05-17 monthly 0.7 https://llm-coding.github.io/Semantic-Anchors/evaluations - 2026-05-14 + 2026-05-17 monthly 0.8 https://llm-coding.github.io/Semantic-Anchors/all-anchors - 2026-05-14 + 2026-05-17 weekly 0.8 https://llm-coding.github.io/Semantic-Anchors/agentskill - 2026-05-14 + 2026-05-17 monthly 0.7 https://llm-coding.github.io/Semantic-Anchors/changelog - 2026-05-14 + 2026-05-17 weekly 0.7 https://llm-coding.github.io/Semantic-Anchors/contributing - 2026-05-14 + 2026-05-17 monthly 0.7 https://llm-coding.github.io/Semantic-Anchors/rejected-proposals - 2026-05-14 + 2026-05-17 monthly 0.5 @@ -101,7 +101,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/4mat - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -109,7 +109,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/adr-according-to-nygard - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -117,7 +117,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/arc42 - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -125,7 +125,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/atam - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -133,7 +133,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/bdd-given-when-then - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -141,7 +141,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/bem-methodology - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -149,7 +149,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/bluf - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -157,7 +157,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/c4-diagrams - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -165,7 +165,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/chain-of-thought - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -173,7 +173,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/clean-architecture - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -181,7 +181,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/cockburn-use-cases - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -189,7 +189,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/code-smells - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -197,7 +197,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/cohesion-criteria - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -205,7 +205,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/control-chart-shewhart - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -213,7 +213,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/conventional-commits - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -221,7 +221,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/cqrs - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -229,7 +229,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/crc-cards - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -237,7 +237,15 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/cynefin-framework - 2026-05-14 + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/decisional-balance-sheet + 2026-05-17 monthly 0.6 @@ -245,7 +253,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/definition-of-done - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -253,7 +261,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/devils-advocate - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -261,7 +269,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/diataxis-framework - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -269,7 +277,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/docs-as-code - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -277,7 +285,15 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/domain-driven-design - 2026-05-14 + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/double-diamond + 2026-05-17 monthly 0.6 @@ -285,7 +301,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/ears-requirements - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -293,7 +309,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/effective-go - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -301,7 +317,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/event-driven-architecture - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -309,7 +325,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/fagan-inspection - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -317,7 +333,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/feynman-technique - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -325,7 +341,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/fichtean-curve - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -333,7 +349,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/five-whys - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -341,7 +357,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/fowler-patterns - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -349,7 +365,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/freytags-pyramid - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -357,7 +373,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gherkin - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -365,7 +381,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/github-flow - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -373,7 +389,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-abstract-factory-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -381,7 +397,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-adapter-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -389,7 +405,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-bridge-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -397,7 +413,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-builder-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -405,7 +421,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-chain-of-responsibility-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -413,7 +429,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-command-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -421,7 +437,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-composite-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -429,7 +445,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-decorator-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -437,7 +453,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-design-patterns - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -445,7 +461,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-facade-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -453,7 +469,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-factory-method-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -461,7 +477,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-flyweight-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -469,7 +485,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-interpreter-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -477,7 +493,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-iterator-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -485,7 +501,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-mediator-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -493,7 +509,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-memento-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -501,7 +517,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-observer-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -509,7 +525,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-prototype-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -517,7 +533,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-proxy-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -525,7 +541,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-singleton-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -533,7 +549,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-state-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -541,7 +557,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-strategy-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -549,7 +565,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-template-method-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -557,7 +573,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gof-visitor-pattern - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -565,7 +581,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gom - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -573,7 +589,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/grasp - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -581,7 +597,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gtd - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -589,7 +605,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/gutes-deutsch-wolf-schneider - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -597,7 +613,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/hemingway-bridge - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -605,7 +621,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/heros-journey - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -613,7 +629,15 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/hexagonal-architecture - 2026-05-14 + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/hoshin-kanri + 2026-05-17 monthly 0.6 @@ -621,7 +645,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/iec-61508-sil-levels - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -629,7 +653,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/impact-mapping - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -637,7 +661,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/invest - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -645,7 +669,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/iso-25010 - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -653,7 +677,15 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/jobs-to-be-done - 2026-05-14 + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/kano-model + 2026-05-17 monthly 0.6 @@ -661,7 +693,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/kishotenketsu - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -669,7 +701,15 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/kiss-principle - 2026-05-14 + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/kotter-8-step-change-model + 2026-05-17 monthly 0.6 @@ -677,7 +717,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/lasr - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -685,7 +725,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/lehmans-classification - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -693,7 +733,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/linddun - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -701,7 +741,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/llm-evaluations - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -709,7 +749,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/madr - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -717,7 +757,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/mece - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -725,7 +765,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/mental-model-according-to-naur - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -733,7 +773,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/mikado-method - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -741,7 +781,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/morphological-box - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -749,7 +789,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/moscow - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -757,7 +797,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/mutation-testing - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -765,7 +805,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/mvp - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -773,7 +813,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/myers-briggs-type-indicator - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -781,7 +821,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/nelson-rules - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -789,7 +829,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/occams-razor - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -797,7 +837,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/owasp-top-10 - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -805,7 +845,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/para-method - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -813,7 +853,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/pert - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -821,7 +861,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/plain-english-strunk-white - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -829,7 +869,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/prd - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -837,7 +877,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/problem-space-nvc - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -845,7 +885,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/property-based-testing - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -853,7 +893,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/pugh-matrix - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -861,7 +901,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/pyramid-principle - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -869,7 +909,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/red-green-tdd - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -877,7 +917,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/regulated-environment - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -885,7 +925,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/save-the-cat - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -893,7 +933,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/semantic-versioning - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -901,7 +941,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/single-level-of-abstraction-principle - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -909,7 +949,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/socratic-method - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -917,7 +957,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/solid-dip - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -925,7 +965,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/solid-isp - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -933,7 +973,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/solid-lsp - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -941,7 +981,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/solid-ocp - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -949,7 +989,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/solid-principles - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -957,7 +997,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/solid-srp - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -965,7 +1005,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/sota - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -973,7 +1013,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/spc - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -981,7 +1021,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/spike-solution - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -989,7 +1029,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/ssot-principle - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -997,7 +1037,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/story-circle-dan-harmon - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1005,7 +1045,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/stride - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1013,7 +1053,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/swot - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1021,7 +1061,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/tdd-chicago-school - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1029,7 +1069,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/tdd-london-school - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1037,7 +1077,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/test-double-dummy - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1045,7 +1085,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/test-double-fake - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1053,7 +1093,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/test-double-meszaros - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1061,7 +1101,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/test-double-mock - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1069,7 +1109,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/test-double-spy - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1077,7 +1117,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/test-double-stub - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1085,7 +1125,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/testing-pyramid - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1093,7 +1133,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/thin-vertical-slice - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1101,7 +1141,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/three-act-structure - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1109,7 +1149,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/timtowtdi - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1117,7 +1157,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/todotxt-flavoured-markdown - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1125,7 +1165,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/tracer-bullet - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1133,7 +1173,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/user-story-mapping - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1141,7 +1181,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/vertical-slice-architecture - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1149,7 +1189,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/walking-skeleton - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1157,7 +1197,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/wardley-mapping - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1165,7 +1205,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/what-qualifies-as-a-semantic-anchor - 2026-05-14 + 2026-05-17 monthly 0.6 @@ -1173,7 +1213,55 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/what-would-chuck-norris-do - 2026-05-14 + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/workflow-architecture-documentation + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/workflow-code-review + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/workflow-requirements-to-spec + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/workflow-strategic-analysis + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/workflow-tdd-clean-architecture + 2026-05-17 + monthly + 0.6 + + + + + https://llm-coding.github.io/Semantic-Anchors/anchor/xy-problem + 2026-05-17 monthly 0.6 @@ -1181,7 +1269,7 @@ https://llm-coding.github.io/Semantic-Anchors/anchor/yagni - 2026-05-14 + 2026-05-17 monthly 0.6