Skip to content

feat(socratic-recovery): pin a fixed second level for the question tree #497

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rdmueller merged 2 commits into from
May 17, 2026
Merged

feat(socratic-recovery): pin a fixed second level for the question tree #497

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
546fec5
feat(socratic-recovery): pin a fixed second level for the question tree
raifdmueller May 17, 2026
330fea8
fix(socratic-recovery): address CodeRabbit review on PR #497
raifdmueller May 17, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions docs/all-anchors.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -161,6 +161,8 @@ include::anchors/timtowtdi.adoc[leveloffset=+2]

include::anchors/socratic-method.adoc[leveloffset=+2]

include::anchors/xy-problem.adoc[leveloffset=+2]

<<<

== Documentation
Expand Down Expand Up @@ -193,8 +195,12 @@ include::anchors/what-qualifies-as-a-semantic-anchor.adoc[leveloffset=+2]

include::anchors/chain-of-thought.adoc[leveloffset=+2]

include::anchors/decisional-balance-sheet.adoc[leveloffset=+2]

include::anchors/devils-advocate.adoc[leveloffset=+2]

include::anchors/double-diamond.adoc[leveloffset=+2]

include::anchors/feynman-technique.adoc[leveloffset=+2]

include::anchors/five-whys.adoc[leveloffset=+2]
Expand All @@ -205,16 +211,22 @@ include::anchors/occams-razor.adoc[leveloffset=+2]

include::anchors/what-would-chuck-norris-do.adoc[leveloffset=+2]

include::anchors/xy-problem.adoc[leveloffset=+2]

<<<

== Requirements Engineering

include::anchors/cockburn-use-cases.adoc[leveloffset=+2]

include::anchors/double-diamond.adoc[leveloffset=+2]

include::anchors/ears-requirements.adoc[leveloffset=+2]

include::anchors/invest.adoc[leveloffset=+2]

include::anchors/kano-model.adoc[leveloffset=+2]

include::anchors/moscow.adoc[leveloffset=+2]

include::anchors/prd.adoc[leveloffset=+2]
Expand Down Expand Up @@ -277,10 +289,18 @@ include::anchors/spc.adoc[leveloffset=+2]

include::anchors/cynefin-framework.adoc[leveloffset=+2]

include::anchors/decisional-balance-sheet.adoc[leveloffset=+2]

include::anchors/hoshin-kanri.adoc[leveloffset=+2]

include::anchors/impact-mapping.adoc[leveloffset=+2]

include::anchors/jobs-to-be-done.adoc[leveloffset=+2]

include::anchors/kano-model.adoc[leveloffset=+2]

include::anchors/kotter-8-step-change-model.adoc[leveloffset=+2]

include::anchors/mvp.adoc[leveloffset=+2]

include::anchors/pert.adoc[leveloffset=+2]
Expand Down Expand Up @@ -336,3 +356,17 @@ include::anchors/test-double-stub.adoc[leveloffset=+2]
include::anchors/testing-pyramid.adoc[leveloffset=+2]

<<<

== Workflow

include::anchors/workflow-architecture-documentation.adoc[leveloffset=+2]

include::anchors/workflow-code-review.adoc[leveloffset=+2]

include::anchors/workflow-requirements-to-spec.adoc[leveloffset=+2]

include::anchors/workflow-strategic-analysis.adoc[leveloffset=+2]

include::anchors/workflow-tdd-clean-architecture.adoc[leveloffset=+2]

<<<
43 changes: 26 additions & 17 deletions docs/brownfield-workflow.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ The prompts in this phase are also packaged as an installable Claude Code Skill.

=== Phase 1: Build the Question Tree

Start with five high-level questions about the bounded context and decompose them recursively. Use Semantic Anchors as decomposition guides: *arc42* for architecture, *Cockburn Use Cases* for specification, *ISO 25010* for quality, *Nygard ADRs* for decisions.
Start with five root questions about the bounded context. Their *second level is fixed*: every run emits the same prescribed set of sub-questions — the six PRD elements (Q1.1–Q1.6), six specification categories (Q2.1–Q2.6), the twelve arc42 chapters (Q3.1–Q3.12), the eight ISO/IEC 25010 characteristics plus a priority question (Q4.1–Q4.9), and five risk categories (Q5.1–Q5.5). Free, code-driven decomposition applies only *below* that fixed level. The fixed level keeps Q-IDs stable — Q3.7 is always the Deployment View — so trees from different runs can be diffed node-by-node.

Comment on lines +69 to 70

@coderabbitai coderabbitai Bot May 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Kanonische Quelle für die feste Enumeration fehlt

In Line 69-70 und erneut in Line 93-106 wird die komplette Q1.1–Q5.5-Enumeration lokal ausgeschrieben, aber ohne expliziten Verweis auf die kanonische Contract-Definition. Das erhöht das Drift-Risiko zwischen Doku und Contract bei späteren Änderungen. Bitte hier klar auf die kanonische Quelle verweisen.

Also applies to: 93-106

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/brownfield-workflow.adoc` around lines 69 - 70, Die lokal
ausgeschriebene Enumeration Q1.1–Q5.5 (inkl. Q3.1–Q3.12 und Q4.1–Q4.9) fehlt
eine Verlinkung zur kanonischen Contract-Definition; aktualisiere beide Stellen,
an denen die feste Ebene ausgeschrieben ist, so dass unmittelbar nach der
Beschreibung ein klarer Verweis auf die offizielle Contract-Quelle steht (z. B.
ein eindeutiger Contract-Identifier/URL oder ein Verweisstext wie "siehe
Canonical Question Contract <name/id>"), und ergänze optional einen kurzen
Hinweis, dass Q-IDs stabil sind (z. B. "Q3.7 = Deployment View") damit künftig
kein Drift zwischen dieser Dokumentation und dem Contract entsteht.

Each leaf in the tree is either `[ANSWERED]` (with code evidence: file, function, line) or `[OPEN]` (with Category and Ask role). The output is two AsciiDoc files: `QUESTION_TREE.adoc` (full reasoning trace) and `OPEN_QUESTIONS.adoc` (handoff document, grouped by role).

Expand All @@ -83,26 +83,33 @@ recursive question refinement, before any documentation is written.

Process:

1. Start with five high-level questions about the bounded context:
1. Start with five root questions about the bounded context:
Q1 What problem does this bounded context solve, and for whom?
Q2 What is the specification of this bounded context?
Q3 What is the architecture of this bounded context?
Q4 What quality goals drive the design?
Q5 What risks and technical debt exist?

2. Decompose each question recursively. Use these Semantic Anchors as
decomposition guides:
- arc42 — 12 sub-questions for architecture (Q3 branch)
- Cockburn Use Cases — Primary Actor, Trigger, Main Success Scenario,
Extensions, Postconditions for specification (Q2 branch)
- ISO/IEC 25010 — 8 quality characteristics for quality goals (Q4 branch)
- Nygard ADRs — Context, Decision, Status, Consequences for design
rationale (Q3.9 branch)
Stop decomposing when a question is precise enough to be answered with a
single piece of code evidence or a single fact from a stakeholder.

3. Assign a hierarchical Q-ID to every node (Q1, Q1.2, Q1.2.3, ...) so that
later documentation can cite back to it.
2. The second level of the tree is FIXED, not free. Emit exactly these
nodes, in this order, even when a node's only leaf is [OPEN] or
[ANSWERED: not applicable]:
Q1.1-Q1.6 product identity, primary users, channels, why-built,
success metrics, segment priority
Q2.1-Q2.6 actors, use-case catalog, per-interface system specs,
data/entity model, acceptance criteria, cross-cutting
business rules
Q3.1-Q3.12 the twelve arc42 chapters, in arc42 order
Q4.1-Q4.8 the eight ISO/IEC 25010 characteristics;
Q4.9 which characteristic has priority
Q5.1-Q5.5 technical debt, security risks, operational risks,
dependency/supply-chain risks, scaling/performance risks

3. Below the fixed second level, decompose freely and code-driven. Stop
when a leaf is small enough to answer from a single piece of code
evidence, or to pose as a single precise question to a stakeholder.
Third-level depth varies between runs — that is expected. Q-IDs are
stable: Q3.7 is always the Deployment View, in every run, so trees
from different runs can be diffed node-by-node.

4. For each leaf, classify it:

Expand All @@ -129,7 +136,9 @@ Process:

OPEN_QUESTIONS.adoc
- Only the [OPEN] leaves, copied verbatim from QUESTION_TREE.adoc
- Grouped by Ask role (one section per role)
- Always one section per Ask role (Product Owner, Architect,
Developer, Domain Expert, Operations) — emit every section even
when it is empty ("No open questions for this role")
- Each question short enough to be answered in 1-3 sentences

Do not write any other documentation in this phase. Phase 2 will synthesize
Expand Down Expand Up @@ -253,7 +262,7 @@ Stable code that nobody touches does not need specs.
|link:#/anchor/domain-driven-design[DDD]

|Theory Recovery (Phase 1)
|`You have access to [bounded context path]. No documentation exists. Build a Question Tree by recursively refining 5 questions: Problem/Users, Specification, Architecture, Quality Goals, Risks. Each leaf: [ANSWERED] with code evidence or [OPEN] with Category and Ask role.`
|`You have access to [bounded context path]. No documentation exists. Build a Question Tree: 5 root questions (Problem/Users, Specification, Architecture, Quality Goals, Risks), each with a FIXED second level (Q1.1-Q5.5: 6 PRD elements, 6 spec categories, 12 arc42 chapters, 8 ISO 25010 characteristics + priority, 5 risk categories); free decomposition only below it. Each leaf: [ANSWERED] with file:line evidence or [OPEN] with Category and Ask role.`
|link:#/anchor/arc42[arc42], link:#/anchor/cockburn-use-cases[Cockburn], link:#/anchor/iso-25010[ISO 25010], link:#/anchor/nygard-adrs[Nygard ADR]

|Team Answers
Expand Down
43 changes: 26 additions & 17 deletions docs/brownfield-workflow.de.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ Die Prompts dieser Phase sind auch als installierbarer Claude Code Skill verpack

=== Phase 1: Question Tree aufbauen

Mit fünf Top-Level-Fragen zum Bounded Context starten und sie rekursiv zerlegen. Semantic Anchors als Zerlegungs-Heuristiken einsetzen: *arc42* für Architektur, *Cockburn Use Cases* für Spezifikation, *ISO 25010* für Qualität, *Nygard ADRs* für Entscheidungen.
Mit fünf Wurzelfragen zum Bounded Context starten. Ihre *zweite Ebene ist fix*: jeder Lauf erzeugt denselben vorgegebenen Satz an Unterfragen — die sechs PRD-Elemente (Q1.1–Q1.6), sechs Spezifikationskategorien (Q2.1–Q2.6), die zwölf arc42-Kapitel (Q3.1–Q3.12), die acht ISO/IEC-25010-Merkmale plus eine Prioritätsfrage (Q4.1–Q4.9) und fünf Risikokategorien (Q5.1–Q5.5). Freie, code-getriebene Zerlegung gilt nur *unterhalb* dieser fixen Ebene. Die fixe Ebene hält Q-IDs stabil — Q3.7 ist immer die Verteilungssicht —, sodass Bäume verschiedener Läufe Knoten für Knoten verglichen werden können.

Comment on lines +67 to 68

@coderabbitai coderabbitai Bot May 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Kanonische Quelle für die feste Enumeration nicht referenziert

Die feste Q1.1–Q5.5-Liste wird in Line 67-68 und Line 91-103 vollständig lokal wiederholt, aber ohne expliziten Verweis auf die kanonische Contract-Quelle. Das macht spätere Inkonsistenzen wahrscheinlicher. Bitte die kanonische Quelle direkt referenzieren.

Also applies to: 91-103

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/brownfield-workflow.de.adoc` around lines 67 - 68, Die wiederholte feste
Enumeration (Q1.1–Q5.5, inklusive Q3.7 als Verteilungssicht) muss mit der
kanonischen Contract-Quelle verlinkt werden: ergänze in der kurzen Beschreibung
bei "zweite Ebene ist fix" und in der vollständigen Liste (die zweite Stelle der
Wiederholung) jeweils einen eindeutigen Verweis/Zitat (z. B. Contract-Name,
Version und URL oder AsciiDoc xref/anchor) zur offiziellen Quelle, so dass
Leserinnen direkt zur autoritativen Definition springen können und
Inkonsistenzen vermieden werden.

Jedes Blatt im Baum ist entweder `[ANSWERED]` (mit Code-Evidenz: Datei, Funktion, Zeile) oder `[OPEN]` (mit Category und Ask-Rolle). Der Output sind zwei AsciiDoc-Dateien: `QUESTION_TREE.adoc` (vollständige Begründungs-Spur) und `OPEN_QUESTIONS.adoc` (Handoff-Dokument, nach Rolle gruppiert).

Expand All @@ -81,26 +81,33 @@ recursive question refinement, before any documentation is written.

Process:

1. Start with five high-level questions about the bounded context:
1. Start with five root questions about the bounded context:
Q1 What problem does this bounded context solve, and for whom?
Q2 What is the specification of this bounded context?
Q3 What is the architecture of this bounded context?
Q4 What quality goals drive the design?
Q5 What risks and technical debt exist?

2. Decompose each question recursively. Use these Semantic Anchors as
decomposition guides:
- arc42 — 12 sub-questions for architecture (Q3 branch)
- Cockburn Use Cases — Primary Actor, Trigger, Main Success Scenario,
Extensions, Postconditions for specification (Q2 branch)
- ISO/IEC 25010 — 8 quality characteristics for quality goals (Q4 branch)
- Nygard ADRs — Context, Decision, Status, Consequences for design
rationale (Q3.9 branch)
Stop decomposing when a question is precise enough to be answered with a
single piece of code evidence or a single fact from a stakeholder.

3. Assign a hierarchical Q-ID to every node (Q1, Q1.2, Q1.2.3, ...) so that
later documentation can cite back to it.
2. The second level of the tree is FIXED, not free. Emit exactly these
nodes, in this order, even when a node's only leaf is [OPEN] or
[ANSWERED: not applicable]:
Q1.1-Q1.6 product identity, primary users, channels, why-built,
success metrics, segment priority
Q2.1-Q2.6 actors, use-case catalog, per-interface system specs,
data/entity model, acceptance criteria, cross-cutting
business rules
Q3.1-Q3.12 the twelve arc42 chapters, in arc42 order
Q4.1-Q4.8 the eight ISO/IEC 25010 characteristics;
Q4.9 which characteristic has priority
Q5.1-Q5.5 technical debt, security risks, operational risks,
dependency/supply-chain risks, scaling/performance risks

3. Below the fixed second level, decompose freely and code-driven. Stop
when a leaf is small enough to answer from a single piece of code
evidence, or to pose as a single precise question to a stakeholder.
Third-level depth varies between runs — that is expected. Q-IDs are
stable: Q3.7 is always the Deployment View, in every run, so trees
from different runs can be diffed node-by-node.

4. For each leaf, classify it:

Expand All @@ -127,7 +134,9 @@ Process:

OPEN_QUESTIONS.adoc
- Only the [OPEN] leaves, copied verbatim from QUESTION_TREE.adoc
- Grouped by Ask role (one section per role)
- Always one section per Ask role (Product Owner, Architect,
Developer, Domain Expert, Operations) — emit every section even
when it is empty ("No open questions for this role")
- Each question short enough to be answered in 1-3 sentences

Do not write any other documentation in this phase. Phase 2 will synthesize
Expand Down Expand Up @@ -251,7 +260,7 @@ Stabiler Code, den niemand anfasst, braucht keine Specs.
|link:#/anchor/domain-driven-design[DDD]

|Theory Recovery (Phase 1)
|`You have access to [bounded context path]. No documentation exists. Build a Question Tree by recursively refining 5 questions: Problem/Users, Specification, Architecture, Quality Goals, Risks. Each leaf: [ANSWERED] with code evidence or [OPEN] with Category and Ask role.`
|`You have access to [bounded context path]. No documentation exists. Build a Question Tree: 5 root questions (Problem/Users, Specification, Architecture, Quality Goals, Risks), each with a FIXED second level (Q1.1-Q5.5: 6 PRD elements, 6 spec categories, 12 arc42 chapters, 8 ISO 25010 characteristics + priority, 5 risk categories); free decomposition only below it. Each leaf: [ANSWERED] with file:line evidence or [OPEN] with Category and Ask role.`
|link:#/anchor/arc42[arc42], link:#/anchor/cockburn-use-cases[Cockburn], link:#/anchor/iso-25010[ISO 25010], link:#/anchor/nygard-adrs[Nygard ADR]

|Team Answers
Expand Down
8 changes: 4 additions & 4 deletions docs/socratic-recovery-skill.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ Recovers documentation from a brownfield codebase without hallucinating the part

=== Phase 1 — Build the Question Tree

The skill prompts the LLM to recursively decompose five questions about a bounded context (Problem/Users, Specification, Architecture, Quality Goals, Risks). Each leaf is classified:
The skill prompts the LLM to build a Question Tree from five root questions about a bounded context (Problem/Users, Specification, Architecture, Quality Goals, Risks). Their second level is fixed — every run emits the same enumerated nodes (Q1.1–Q5.5: six PRD elements, six specification categories, the twelve arc42 chapters, the eight ISO/IEC 25010 characteristics plus a priority question, five risk categories), so Q-IDs are stable and trees from different runs can be diffed node-by-node. Free, code-driven decomposition happens only below that fixed level. Each leaf is classified:

@coderabbitai coderabbitai Bot May 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Single-Source-of-Truth für die Q-Enumeration wird unterlaufen

In Line 12 und erneut im Tabellenabschnitt Line 193-199 wird die feste Knoten-Enumeration im Skill-Doc selbst ausgeschrieben. Für den Skill sollte diese Definition aus einer kanonischen Contract-Quelle referenziert werden, um Divergenzen zu vermeiden.

Also applies to: 193-199

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/socratic-recovery-skill.adoc` at line 12, The document hard-codes the
fixed Question Tree enumeration (Q-IDs like Q1.1–Q5.5, the six PRD elements,
twelve arc42 chapters, the eight ISO/IEC 25010 characteristics, etc.) in the
prose and table sections, which breaks Single Source of Truth; change the docs
to reference and/or include the canonical contract data instead of literal
lists: replace the explicit enumeration in the "Question Tree"/Q-IDs text and
the table block that repeats those entries with a generated include or template
call that pulls the authoritative enumeration from the canonical
contract/metadata source (the same JSON/YAML/constants that define the Q-IDs),
and add a simple validation step in the doc build to fail if the included
enumeration and the contract diverge so the "Q-IDs"/Question Tree and table
remain in sync.


* `[ANSWERED]` -- the LLM found it in the code, with `<file>:<line>` evidence
* `[OPEN]` -- the answer is not derivable from code; tagged with a Category and the role that must answer (Product Owner, Architect, Developer, Domain Expert, Operations)
Expand Down Expand Up @@ -190,13 +190,13 @@ Any AI assistant that accepts a system prompt or custom instructions can use thi
| The Phase 2 prompt producing PRD, Cockburn use cases, arc42, and Nygard ADRs

| `references/arc42.md`
| arc42's 12 sections as Q3 decomposition heuristic
| arc42's 12 chapters as the fixed Q3.1–Q3.12 nodes

| `references/cockburn-use-cases.md`
| Fully Dressed fields as Q2 sub-questions; persona vs system use cases
| Fully Dressed fields as use-case leaves; persona vs system use cases

| `references/iso-25010.md`
| 8 quality characteristics as Q4 sub-questions; mechanism-vs-target split
| 8 quality characteristics as the fixed Q4.1–Q4.8 nodes; mechanism-vs-target split

| `references/nygard-adrs.md`
| ADR fields as Q3.9 sub-tree; what makes a decision architecturally significant; Pugh-matrix guidance
Expand Down
8 changes: 4 additions & 4 deletions docs/socratic-recovery-skill.de.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ Stellt Dokumentation aus einem Brownfield-Codebase wieder her, ohne die Lücken

=== Phase 1 — Question Tree aufbauen

Der Skill weist das LLM an, fünf Fragen zum Bounded Context (Problem/User, Spezifikation, Architektur, Qualitätsziele, Risiken) rekursiv zu zerlegen. Jedes Blatt wird klassifiziert:
Der Skill weist das LLM an, aus fünf Wurzelfragen zum Bounded Context (Problem/User, Spezifikation, Architektur, Qualitätsziele, Risiken) einen Question Tree zu bauen. Ihre zweite Ebene ist fix — jeder Lauf erzeugt dieselben enumerierten Knoten (Q1.1–Q5.5: sechs PRD-Elemente, sechs Spezifikationskategorien, die zwölf arc42-Kapitel, die acht ISO/IEC-25010-Merkmale plus eine Prioritätsfrage, fünf Risikokategorien), sodass Q-IDs stabil sind und Bäume verschiedener Läufe Knoten für Knoten verglichen werden können. Freie, code-getriebene Zerlegung passiert nur unterhalb dieser fixen Ebene. Jedes Blatt wird klassifiziert:

@coderabbitai coderabbitai Bot May 17, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Kanonische Contract-Quelle für die feste Knotenliste fehlt

Die fixe Q1.1–Q5.5-Enumeration wird in Line 12 sowie in Line 193-199 lokal wiederholt. Für den Skill sollte diese Definition auf die kanonische Contract-Quelle verweisen, statt sie mehrfach auszuschreiben, um Drift zu verhindern.

Also applies to: 193-199

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/socratic-recovery-skill.de.adoc` at line 12, The repeated explicit
enumeration of the fixed Question Tree nodes (the Q1.1–Q5.5 list referenced in
the "Question Tree" description and the duplicate block later) must be replaced
by a canonical reference: remove the hard-coded list text and instead reference
or include the single authoritative contract/source (the canonical contract for
the Skill) so the document points to that source for the fixed node list; update
both occurrences that mention "Q1.1–Q5.5" and the repeated fixed-node paragraph
to use an AsciiDoc include or xref to the canonical contract (or a named
"Socratic Recovery Skill" contract identifier) and keep the explanatory text
about stable Q-IDs and free decomposition unchanged.


* `[ANSWERED]` -- das LLM hat es im Code gefunden, mit `<file>:<line>`-Evidenz
* `[OPEN]` -- die Antwort steckt nicht im Code; mit Category und der Rolle markiert, die antworten muss (Product Owner, Architect, Developer, Domain Expert, Operations)
Expand Down Expand Up @@ -190,13 +190,13 @@ Jeder Assistent, der einen System-Prompt oder Custom Instructions akzeptiert, ka
| Der Phase-2-Prompt, der PRD, Cockburn Use Cases, arc42 und Nygard-ADRs erzeugt

| `references/arc42.md`
| arc42 12 Sektionen als Q3-Zerlegungs-Heuristik
| arc42 12 Kapitel als die fixen Knoten Q3.1–Q3.12

| `references/cockburn-use-cases.md`
| Fully-Dressed-Felder als Q2-Subfragen; Persona- vs. System-Use-Cases
| Fully-Dressed-Felder als Use-Case-Blätter; Persona- vs. System-Use-Cases

| `references/iso-25010.md`
| 8 Qualitätsmerkmale als Q4-Subfragen; Mechanismus-vs-Target-Trennung
| 8 Qualitätsmerkmale als die fixen Knoten Q4.1–Q4.8; Mechanismus-vs-Target-Trennung

| `references/nygard-adrs.md`
| ADR-Felder als Q3.9-Sub-Tree; was eine Entscheidung architektonisch signifikant macht; Pugh-Matrix-Leitfaden
Expand Down
15 changes: 9 additions & 6 deletions plugins/semantic-anchors/skills/socratic-code-theory-recovery/SKILL.md
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading
Loading