From 3232e65ef0bb24d6e7fcdc86ad8e471403a056af Mon Sep 17 00:00:00 2001 From: Kenneth Mark Dsouza Date: Tue, 14 Jul 2026 16:30:56 +0530 Subject: [PATCH 1/7] Start 0.1.6 unreleased changelog Co-Authored-By: Claude Sonnet 4.6 --- CHANGELOG.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 4133ab5..a324b8c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,14 @@ All notable changes to Data Vizard will be documented here. +## Unreleased + +- Added banned words/phrases operational checklist to Narrator's anti-AI-tropes reference, with reason and alternative columns. +- Applied deletion test to project ledger guidance in orchestrator — rows with no decision or caveat worth preserving should be omitted. +- Added evaluation rubric and sunset tracking conventions to data-curator's open data sources reference. +- Added `RELEASE.md` with step-by-step release checklist covering version refs, doc review across all surfaces, and npm publish smoke test. +- Planned `data-vizard uninstall` CLI subcommand (not yet implemented). + ## 0.1.5 - 2026-07-13 - Added the `de-slop` skill across root, packaged plugin, and Gemini extension surfaces for repairing bad or misleading charts without changing the evidence. From 97b08d8496fee31f2d7cbf8f3e16fd0c36dee448 Mon Sep 17 00:00:00 2001 From: Kenneth Mark Dsouza Date: Tue, 14 Jul 2026 17:02:48 +0530 Subject: [PATCH 2/7] Tighten orchestrator-curator handoff and add stage transition commentary MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Orchestrator step 1: hand to Curator immediately when dataset is provided; do not ask posture or direction before Curator has seen the data - Orchestrator: add Stage Transition Commentary rule — brief what the previous skill produced and what the user decided before handing to the next skill - Curator: add step 6 — after reporting data fitness, ask posture and analytical direction as one combined button-ready interaction before cleaning and shaping - Curator handoff notes: include confirmed posture and direction Co-Authored-By: Claude Sonnet 4.6 --- .../data-vizard/skills/data-curator/SKILL.md | 11 +++++++---- .../data-vizard/skills/data-vizard/SKILL.md | 15 ++++++--------- plugins/data-vizard/skills/data-curator/SKILL.md | 11 +++++++---- plugins/data-vizard/skills/data-vizard/SKILL.md | 15 ++++++--------- skills/data-curator/SKILL.md | 11 +++++++---- skills/data-vizard/SKILL.md | 15 ++++++--------- 6 files changed, 39 insertions(+), 39 deletions(-) diff --git a/extensions/data-vizard/skills/data-curator/SKILL.md b/extensions/data-vizard/skills/data-curator/SKILL.md index da95a68..8043bf9 100644 --- a/extensions/data-vizard/skills/data-curator/SKILL.md +++ b/extensions/data-vizard/skills/data-curator/SKILL.md @@ -47,7 +47,10 @@ Use no more than four options unless the user asks for a broader menu. Include ` 5. Report data fitness. Summarize what the data can support, what it cannot support, and what claims would be risky. -6. Propose cleaning and shaping actions. +6. Ask about narrative posture and analytical direction. + Based on what the data can support, present posture options and 2–3 concrete analytical directions as button-ready choices. Do not ask posture and direction as separate questions — combine them into one interaction so the user makes one decision that unblocks both. Let the data shape which postures are realistic: aggregate-structured data suggests `Explanatory` or `Balanced`; record-level or collection data suggests `Balanced explorer` or `Data-art-led`. Wait for the user to decide before proceeding to cleaning and shaping. + +7. Propose cleaning and shaping actions. Suggest transformations such as type fixes, normalization, pivoting, aggregation, deduplication, derived fields, and joins. Use button-ready choices for actions that affect meaning. For API sources, also consider extraction and shaping actions such as: @@ -57,11 +60,11 @@ Use no more than four options unless the user asks for a broader menu. Include ` - caching raw responses before aggregation - separating entity tables, relationship tables, and display-ready summaries -7. Supplement if useful. +8. Supplement if useful. If the analysis would be weak without context, propose enrichment datasets. Explain why each source helps and how it would join. -8. Produce handoff notes. - Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, recommended analytical questions, and the likely artifact mode: +9. Produce handoff notes. + Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, and the likely artifact mode: - `aggregate analysis` - `record-by-record exploration` - `hybrid` diff --git a/extensions/data-vizard/skills/data-vizard/SKILL.md b/extensions/data-vizard/skills/data-vizard/SKILL.md index 8fbb5d0..2c9bd64 100644 --- a/extensions/data-vizard/skills/data-vizard/SKILL.md +++ b/extensions/data-vizard/skills/data-vizard/SKILL.md @@ -19,6 +19,10 @@ Do not make major project decisions silently. Ask the user before choosing datas When the user has not supplied enough context, ask exactly one focused decision question and wait. If more than one decision is needed, ask the highest-leverage or most blocking question first and postpone the rest until after the user answers. If a decision can be postponed, continue with a clearly labeled assumption instead of stacking multiple questions. +## Stage Transition Commentary + +After the user makes a decision at any stage boundary, provide a brief transition commentary before handing to the next skill. State what the previous skill produced, what the user decided, and what is being passed forward. Keep it to 2–4 lines. This keeps the user oriented as work moves between skills and makes the orchestration visible without exposing internal critique notes. + ## Button-Ready Choices Present one decision gate at a time in a strict, compact choice format so Codex surfaces can turn choices into buttons when supported. @@ -58,17 +62,10 @@ Do not let `browseable`, `searchable`, `filterable`, `library`, or `explorer` si The role sequence is still explicit, but the weight of each stage changes by posture. Do not skip Curator or Analyst for real data work. Narrator may return a silent or minimal brief. Critic is mandatory before final signoff and should also review each major stage before presentation. 1. Establish the project brief. - Ask for the single missing detail that most affects the next step, using button-ready choices where possible. Prefer topic or dataset source first; after that, prefer narrative posture before audience, constraints, or artifact format if posture will change the role outputs. - - Store project-specific product context in `outcome//PRODUCT.md`, not in the repository root. This file should capture the audience, purpose, personality, anti-references, design principles, accessibility goals, narrative posture, intent brief, and default approach to avoid for that one visualization project. - - For collection-led or archive-style projects, the brief should also name: - - the aesthetic family to explore first - - the accent color or color temperature to bias toward or avoid - - whether the first screen should feel more `utility`, `editorial`, `studio`, or `hybrid` + Ask only for what is missing to start Curator. If a dataset or topic is already provided, proceed directly to step 2 — do not ask about posture, audience, or direction first. Those questions belong to Curator, who can ask them after profiling the data. If neither a dataset nor a topic is provided, ask for one and wait. 2. Curate the data. - Use Data Curator to find, inspect, clean, reshape, or supplement data. Ask the user to approve external dataset choices and enrichment assumptions unless the user has explicitly delegated the source choice; delegated choices still require a Curator handoff note. + Hand the dataset or topic to Data Curator immediately. Curator profiles the data, reports what it can support, and asks the user about narrative posture and analytical direction before producing a handoff. Do not ask posture or direction before Curator has seen the data. 3. Critique the curation handoff. Use Critic to review the Curator output before presenting the data readout or downstream implications. Critique should check data fitness, caveat visibility, transformation discipline, and whether the curation summary is overstating what the file can support. Revise the curation readout before showing it to the user. diff --git a/plugins/data-vizard/skills/data-curator/SKILL.md b/plugins/data-vizard/skills/data-curator/SKILL.md index da95a68..8043bf9 100644 --- a/plugins/data-vizard/skills/data-curator/SKILL.md +++ b/plugins/data-vizard/skills/data-curator/SKILL.md @@ -47,7 +47,10 @@ Use no more than four options unless the user asks for a broader menu. Include ` 5. Report data fitness. Summarize what the data can support, what it cannot support, and what claims would be risky. -6. Propose cleaning and shaping actions. +6. Ask about narrative posture and analytical direction. + Based on what the data can support, present posture options and 2–3 concrete analytical directions as button-ready choices. Do not ask posture and direction as separate questions — combine them into one interaction so the user makes one decision that unblocks both. Let the data shape which postures are realistic: aggregate-structured data suggests `Explanatory` or `Balanced`; record-level or collection data suggests `Balanced explorer` or `Data-art-led`. Wait for the user to decide before proceeding to cleaning and shaping. + +7. Propose cleaning and shaping actions. Suggest transformations such as type fixes, normalization, pivoting, aggregation, deduplication, derived fields, and joins. Use button-ready choices for actions that affect meaning. For API sources, also consider extraction and shaping actions such as: @@ -57,11 +60,11 @@ Use no more than four options unless the user asks for a broader menu. Include ` - caching raw responses before aggregation - separating entity tables, relationship tables, and display-ready summaries -7. Supplement if useful. +8. Supplement if useful. If the analysis would be weak without context, propose enrichment datasets. Explain why each source helps and how it would join. -8. Produce handoff notes. - Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, recommended analytical questions, and the likely artifact mode: +9. Produce handoff notes. + Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, and the likely artifact mode: - `aggregate analysis` - `record-by-record exploration` - `hybrid` diff --git a/plugins/data-vizard/skills/data-vizard/SKILL.md b/plugins/data-vizard/skills/data-vizard/SKILL.md index 8fbb5d0..2c9bd64 100644 --- a/plugins/data-vizard/skills/data-vizard/SKILL.md +++ b/plugins/data-vizard/skills/data-vizard/SKILL.md @@ -19,6 +19,10 @@ Do not make major project decisions silently. Ask the user before choosing datas When the user has not supplied enough context, ask exactly one focused decision question and wait. If more than one decision is needed, ask the highest-leverage or most blocking question first and postpone the rest until after the user answers. If a decision can be postponed, continue with a clearly labeled assumption instead of stacking multiple questions. +## Stage Transition Commentary + +After the user makes a decision at any stage boundary, provide a brief transition commentary before handing to the next skill. State what the previous skill produced, what the user decided, and what is being passed forward. Keep it to 2–4 lines. This keeps the user oriented as work moves between skills and makes the orchestration visible without exposing internal critique notes. + ## Button-Ready Choices Present one decision gate at a time in a strict, compact choice format so Codex surfaces can turn choices into buttons when supported. @@ -58,17 +62,10 @@ Do not let `browseable`, `searchable`, `filterable`, `library`, or `explorer` si The role sequence is still explicit, but the weight of each stage changes by posture. Do not skip Curator or Analyst for real data work. Narrator may return a silent or minimal brief. Critic is mandatory before final signoff and should also review each major stage before presentation. 1. Establish the project brief. - Ask for the single missing detail that most affects the next step, using button-ready choices where possible. Prefer topic or dataset source first; after that, prefer narrative posture before audience, constraints, or artifact format if posture will change the role outputs. - - Store project-specific product context in `outcome//PRODUCT.md`, not in the repository root. This file should capture the audience, purpose, personality, anti-references, design principles, accessibility goals, narrative posture, intent brief, and default approach to avoid for that one visualization project. - - For collection-led or archive-style projects, the brief should also name: - - the aesthetic family to explore first - - the accent color or color temperature to bias toward or avoid - - whether the first screen should feel more `utility`, `editorial`, `studio`, or `hybrid` + Ask only for what is missing to start Curator. If a dataset or topic is already provided, proceed directly to step 2 — do not ask about posture, audience, or direction first. Those questions belong to Curator, who can ask them after profiling the data. If neither a dataset nor a topic is provided, ask for one and wait. 2. Curate the data. - Use Data Curator to find, inspect, clean, reshape, or supplement data. Ask the user to approve external dataset choices and enrichment assumptions unless the user has explicitly delegated the source choice; delegated choices still require a Curator handoff note. + Hand the dataset or topic to Data Curator immediately. Curator profiles the data, reports what it can support, and asks the user about narrative posture and analytical direction before producing a handoff. Do not ask posture or direction before Curator has seen the data. 3. Critique the curation handoff. Use Critic to review the Curator output before presenting the data readout or downstream implications. Critique should check data fitness, caveat visibility, transformation discipline, and whether the curation summary is overstating what the file can support. Revise the curation readout before showing it to the user. diff --git a/skills/data-curator/SKILL.md b/skills/data-curator/SKILL.md index da95a68..8043bf9 100644 --- a/skills/data-curator/SKILL.md +++ b/skills/data-curator/SKILL.md @@ -47,7 +47,10 @@ Use no more than four options unless the user asks for a broader menu. Include ` 5. Report data fitness. Summarize what the data can support, what it cannot support, and what claims would be risky. -6. Propose cleaning and shaping actions. +6. Ask about narrative posture and analytical direction. + Based on what the data can support, present posture options and 2–3 concrete analytical directions as button-ready choices. Do not ask posture and direction as separate questions — combine them into one interaction so the user makes one decision that unblocks both. Let the data shape which postures are realistic: aggregate-structured data suggests `Explanatory` or `Balanced`; record-level or collection data suggests `Balanced explorer` or `Data-art-led`. Wait for the user to decide before proceeding to cleaning and shaping. + +7. Propose cleaning and shaping actions. Suggest transformations such as type fixes, normalization, pivoting, aggregation, deduplication, derived fields, and joins. Use button-ready choices for actions that affect meaning. For API sources, also consider extraction and shaping actions such as: @@ -57,11 +60,11 @@ Use no more than four options unless the user asks for a broader menu. Include ` - caching raw responses before aggregation - separating entity tables, relationship tables, and display-ready summaries -7. Supplement if useful. +8. Supplement if useful. If the analysis would be weak without context, propose enrichment datasets. Explain why each source helps and how it would join. -8. Produce handoff notes. - Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, recommended analytical questions, and the likely artifact mode: +9. Produce handoff notes. + Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, and the likely artifact mode: - `aggregate analysis` - `record-by-record exploration` - `hybrid` diff --git a/skills/data-vizard/SKILL.md b/skills/data-vizard/SKILL.md index 8fbb5d0..2c9bd64 100644 --- a/skills/data-vizard/SKILL.md +++ b/skills/data-vizard/SKILL.md @@ -19,6 +19,10 @@ Do not make major project decisions silently. Ask the user before choosing datas When the user has not supplied enough context, ask exactly one focused decision question and wait. If more than one decision is needed, ask the highest-leverage or most blocking question first and postpone the rest until after the user answers. If a decision can be postponed, continue with a clearly labeled assumption instead of stacking multiple questions. +## Stage Transition Commentary + +After the user makes a decision at any stage boundary, provide a brief transition commentary before handing to the next skill. State what the previous skill produced, what the user decided, and what is being passed forward. Keep it to 2–4 lines. This keeps the user oriented as work moves between skills and makes the orchestration visible without exposing internal critique notes. + ## Button-Ready Choices Present one decision gate at a time in a strict, compact choice format so Codex surfaces can turn choices into buttons when supported. @@ -58,17 +62,10 @@ Do not let `browseable`, `searchable`, `filterable`, `library`, or `explorer` si The role sequence is still explicit, but the weight of each stage changes by posture. Do not skip Curator or Analyst for real data work. Narrator may return a silent or minimal brief. Critic is mandatory before final signoff and should also review each major stage before presentation. 1. Establish the project brief. - Ask for the single missing detail that most affects the next step, using button-ready choices where possible. Prefer topic or dataset source first; after that, prefer narrative posture before audience, constraints, or artifact format if posture will change the role outputs. - - Store project-specific product context in `outcome//PRODUCT.md`, not in the repository root. This file should capture the audience, purpose, personality, anti-references, design principles, accessibility goals, narrative posture, intent brief, and default approach to avoid for that one visualization project. - - For collection-led or archive-style projects, the brief should also name: - - the aesthetic family to explore first - - the accent color or color temperature to bias toward or avoid - - whether the first screen should feel more `utility`, `editorial`, `studio`, or `hybrid` + Ask only for what is missing to start Curator. If a dataset or topic is already provided, proceed directly to step 2 — do not ask about posture, audience, or direction first. Those questions belong to Curator, who can ask them after profiling the data. If neither a dataset nor a topic is provided, ask for one and wait. 2. Curate the data. - Use Data Curator to find, inspect, clean, reshape, or supplement data. Ask the user to approve external dataset choices and enrichment assumptions unless the user has explicitly delegated the source choice; delegated choices still require a Curator handoff note. + Hand the dataset or topic to Data Curator immediately. Curator profiles the data, reports what it can support, and asks the user about narrative posture and analytical direction before producing a handoff. Do not ask posture or direction before Curator has seen the data. 3. Critique the curation handoff. Use Critic to review the Curator output before presenting the data readout or downstream implications. Critique should check data fitness, caveat visibility, transformation discipline, and whether the curation summary is overstating what the file can support. Revise the curation readout before showing it to the user. From 57bc25e38e69fff8aca2a20658a2d8d733ba29c2 Mon Sep 17 00:00:00 2001 From: Kenneth Mark Dsouza Date: Tue, 14 Jul 2026 17:03:11 +0530 Subject: [PATCH 3/7] Update changelog with orchestrator and curator skill changes Co-Authored-By: Claude Sonnet 4.6 --- CHANGELOG.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index a324b8c..395c064 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,9 @@ All notable changes to Data Vizard will be documented here. ## Unreleased +- Tightened orchestrator-to-curator handoff: orchestrator now passes dataset directly to Curator without asking posture or direction first. +- Curator now asks posture and analytical direction as one combined interaction after reporting data fitness, informed by what the data can actually support. +- Added Stage Transition Commentary to orchestrator: after each user decision, the orchestrator briefly states what the previous skill produced, what was decided, and what goes forward. - Added banned words/phrases operational checklist to Narrator's anti-AI-tropes reference, with reason and alternative columns. - Applied deletion test to project ledger guidance in orchestrator — rows with no decision or caveat worth preserving should be omitted. - Added evaluation rubric and sunset tracking conventions to data-curator's open data sources reference. From 4e17ea31f1de3f469de7c0dd90329d043edf5755 Mon Sep 17 00:00:00 2001 From: Kenneth Mark Dsouza Date: Tue, 14 Jul 2026 17:07:33 +0530 Subject: [PATCH 4/7] Orchestrator: transition commentary is not a pause point MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Stage transitions are orchestrator-driven — invoke next skill immediately after commentary, do not wait for user between stages. Co-Authored-By: Claude Sonnet 4.6 --- extensions/data-vizard/skills/data-vizard/SKILL.md | 2 +- plugins/data-vizard/skills/data-vizard/SKILL.md | 2 +- skills/data-vizard/SKILL.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/extensions/data-vizard/skills/data-vizard/SKILL.md b/extensions/data-vizard/skills/data-vizard/SKILL.md index 2c9bd64..11177b8 100644 --- a/extensions/data-vizard/skills/data-vizard/SKILL.md +++ b/extensions/data-vizard/skills/data-vizard/SKILL.md @@ -21,7 +21,7 @@ When the user has not supplied enough context, ask exactly one focused decision ## Stage Transition Commentary -After the user makes a decision at any stage boundary, provide a brief transition commentary before handing to the next skill. State what the previous skill produced, what the user decided, and what is being passed forward. Keep it to 2–4 lines. This keeps the user oriented as work moves between skills and makes the orchestration visible without exposing internal critique notes. +After the user makes a decision at any stage boundary, provide a brief transition commentary and immediately invoke the next skill in the same response. Do not pause and wait for the user between stages — stage transitions are orchestrator-driven. The user only intervenes at explicit decision gates. State what the previous skill produced, what the user decided, and what is being passed forward, then continue. Keep the commentary to 2–4 lines. ## Button-Ready Choices diff --git a/plugins/data-vizard/skills/data-vizard/SKILL.md b/plugins/data-vizard/skills/data-vizard/SKILL.md index 2c9bd64..11177b8 100644 --- a/plugins/data-vizard/skills/data-vizard/SKILL.md +++ b/plugins/data-vizard/skills/data-vizard/SKILL.md @@ -21,7 +21,7 @@ When the user has not supplied enough context, ask exactly one focused decision ## Stage Transition Commentary -After the user makes a decision at any stage boundary, provide a brief transition commentary before handing to the next skill. State what the previous skill produced, what the user decided, and what is being passed forward. Keep it to 2–4 lines. This keeps the user oriented as work moves between skills and makes the orchestration visible without exposing internal critique notes. +After the user makes a decision at any stage boundary, provide a brief transition commentary and immediately invoke the next skill in the same response. Do not pause and wait for the user between stages — stage transitions are orchestrator-driven. The user only intervenes at explicit decision gates. State what the previous skill produced, what the user decided, and what is being passed forward, then continue. Keep the commentary to 2–4 lines. ## Button-Ready Choices diff --git a/skills/data-vizard/SKILL.md b/skills/data-vizard/SKILL.md index 2c9bd64..11177b8 100644 --- a/skills/data-vizard/SKILL.md +++ b/skills/data-vizard/SKILL.md @@ -21,7 +21,7 @@ When the user has not supplied enough context, ask exactly one focused decision ## Stage Transition Commentary -After the user makes a decision at any stage boundary, provide a brief transition commentary before handing to the next skill. State what the previous skill produced, what the user decided, and what is being passed forward. Keep it to 2–4 lines. This keeps the user oriented as work moves between skills and makes the orchestration visible without exposing internal critique notes. +After the user makes a decision at any stage boundary, provide a brief transition commentary and immediately invoke the next skill in the same response. Do not pause and wait for the user between stages — stage transitions are orchestrator-driven. The user only intervenes at explicit decision gates. State what the previous skill produced, what the user decided, and what is being passed forward, then continue. Keep the commentary to 2–4 lines. ## Button-Ready Choices From c1cff02de98c22a226803873607b7b47f7f722e7 Mon Sep 17 00:00:00 2001 From: Kenneth Mark Dsouza Date: Tue, 14 Jul 2026 17:30:45 +0530 Subject: [PATCH 5/7] Add multi-tier narrative arc support to Analyst and Narrator Analyst now proposes a narrative_arc (ordered tier sequence with claim, evidence, chart_form, and transition_to_next) when the user selects directions that stack naturally. Narrator gains arc mode in the Language Load Contract: per-tier language load, claim copy, and connective transition prose, with arc_tiers in the handoff contract for Designer. Co-Authored-By: Claude Sonnet 4.6 --- .../data-vizard/skills/data-analyst/SKILL.md | 17 +++++++++-- .../data-vizard/skills/narrator/SKILL.md | 28 +++++++++++++++++-- .../data-vizard/skills/data-analyst/SKILL.md | 17 +++++++++-- plugins/data-vizard/skills/narrator/SKILL.md | 28 +++++++++++++++++-- skills/data-analyst/SKILL.md | 17 +++++++++-- skills/narrator/SKILL.md | 28 +++++++++++++++++-- 6 files changed, 123 insertions(+), 12 deletions(-) diff --git a/extensions/data-vizard/skills/data-analyst/SKILL.md b/extensions/data-vizard/skills/data-analyst/SKILL.md index 0ff9ed0..b6ac3d3 100644 --- a/extensions/data-vizard/skills/data-analyst/SKILL.md +++ b/extensions/data-vizard/skills/data-analyst/SKILL.md @@ -61,8 +61,21 @@ Use no more than four options unless the user asks for a broader menu. When usef 6. Ask the user to choose. Present the candidates as button-ready choices. Let the user select one direction, combine directions, or request deeper analysis. -7. Handoff to Narrator. - Provide the chosen insight, supporting evidence, counterpoints, caveats, suggested sequence of facts, and whether the intended output should behave more like an aggregate analysis piece, a browseable archive, or a hybrid. + When the user selects multiple directions or a combined direction that naturally sequences — where one finding sets up the next — do not flatten them into a single claim. Instead, propose a `narrative arc`: an ordered tier sequence where each tier builds on or deepens the previous one. Ask the user to confirm the arc before handing to Narrator. + +7. Produce a narrative arc when directions stack. + If the selected directions form a sequence, produce a tier-by-tier arc before handing off. Each tier should include: + + - `tier` — position number + - `claim` — the specific evidence-backed assertion for this tier + - `evidence` — the data points that support it + - `chart_form` — the likely visual form + - `transition_to_next` — one sentence explaining what question or tension this tier opens that the next tier resolves + + A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. If the directions do not sequence naturally, present them as parallel options rather than a forced arc. + +8. Handoff to Narrator. + Provide the chosen insight or narrative arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. ## Boundaries diff --git a/extensions/data-vizard/skills/narrator/SKILL.md b/extensions/data-vizard/skills/narrator/SKILL.md index 0b0907f..33efb84 100644 --- a/extensions/data-vizard/skills/narrator/SKILL.md +++ b/extensions/data-vizard/skills/narrator/SKILL.md @@ -36,15 +36,34 @@ Pick the lightest output that does the job. - `minimal copy`: a title, tiny caption, or necessary caveat only. - `guided narrative`: concise title, subtitle, and annotation set. - `editorial narrative`: fuller narrative spine for explanatory work. +- `narrative arc`: multi-tier story mode for when Analyst has produced a tier sequence. Each tier gets its own language load, claim copy, and connective transition to the next. See **Arc Mode** below. Default by posture: - `Explanatory` usually needs `guided narrative` or `editorial narrative`. - `Balanced` usually needs `minimal copy` or `guided narrative`. - `Data-art-led` usually needs `silent brief` or `minimal copy`. +- When Analyst passes a confirmed `narrative_arc`, always use `narrative arc` mode regardless of default posture. For collection-like datasets with strong visual source material, preserve both a restrained utility path and a more atmospheric data-art path until the user or orchestrator chooses between them. Do not collapse to a product-style framing merely because browseability matters. +## Arc Mode + +Use arc mode when Analyst has confirmed a multi-tier narrative arc — an ordered sequence of findings where each tier sets up the next. + +Arc mode produces a **section-by-section brief** rather than a single story spine. For each tier in the arc: + +1. **Assign a language load** — each tier may have a different load based on how much the visual can carry on its own at that point in the reading flow. +2. **Write the tier claim** — a single, evidence-backed statement the reader should walk away with after seeing this tier's visual. No vague conclusions. +3. **Write connective copy** — one or two sentences of transition prose that close the current tier and open the question the next tier answers. This is the copy between sections, not inside them. It should feel like an editorial hand guiding the reader forward, not a summary of what they just saw. +4. **Assign the caveat** — if a caveat applies to only one tier, keep it there. If a caveat applies to the whole piece, surface it once in the header and do not repeat it. + +The last tier needs no transition — it should close with a takeaway that stands on its own. + +Arc mode does not mean more copy overall. The connective lines should be tight (one or two sentences). A tier with a strong visual may only need the connective line and nothing else. Do not fill every tier with a full editorial narrative just because multiple tiers exist. + +When handing off arc mode output to Designer, include per-tier language load and connective copy clearly labeled by tier number, so Designer can position them between sections. + ## Workflow 1. Confirm the chosen analytical direction. @@ -58,8 +77,10 @@ For collection-like datasets with strong visual source material, preserve both a 3. Decide the language load. Choose the lightest contract that still helps the audience understand the piece. -4. Build the story spine only if needed. - Draft the opening question, key observation, supporting sequence, turning point, caveat, and takeaway only when the selected language load calls for it. +4. Build the story spine or arc. + For single-direction work: draft the opening question, key observation, supporting sequence, turning point, caveat, and takeaway only when the selected language load calls for it. + + For multi-tier arc work: follow Arc Mode. Do not flatten the arc into a single spine — each tier must retain its own claim and the connective copy that links it forward. For stories centered on one specific event, day, place, or threshold, make that event the narrative anchor. Do not split the opening across multiple competing labels, tooltips, or section titles that restate the same idea. Merge duplicate framing into one clear opening beat. @@ -93,6 +114,9 @@ For collection-like datasets with strong visual source material, preserve both a - annotation priorities - caveats that must remain visible + For arc mode handoffs, add: + - `arc_tiers` — ordered list of tiers, each with `tier`, `claim`, `language_load`, `visible_copy`, and `transition_to_next` (empty string for the last tier) + `visible_text_inventory` should be a flat list of every visible text surface the current brief permits, such as title, caption, note trigger, tooltip label, or detail label. If a visible text surface is not named in the inventory, Designer should treat it as unauthorized by default. `forbidden_phrases` should list weak or overused phrasings that must not reappear during design. `final_visible_copy` should include the exact approved title, subtitle, section headers, readouts, button labels, and persistent helper lines, or explicitly say when a surface should be assistive-only. diff --git a/plugins/data-vizard/skills/data-analyst/SKILL.md b/plugins/data-vizard/skills/data-analyst/SKILL.md index 0ff9ed0..b6ac3d3 100644 --- a/plugins/data-vizard/skills/data-analyst/SKILL.md +++ b/plugins/data-vizard/skills/data-analyst/SKILL.md @@ -61,8 +61,21 @@ Use no more than four options unless the user asks for a broader menu. When usef 6. Ask the user to choose. Present the candidates as button-ready choices. Let the user select one direction, combine directions, or request deeper analysis. -7. Handoff to Narrator. - Provide the chosen insight, supporting evidence, counterpoints, caveats, suggested sequence of facts, and whether the intended output should behave more like an aggregate analysis piece, a browseable archive, or a hybrid. + When the user selects multiple directions or a combined direction that naturally sequences — where one finding sets up the next — do not flatten them into a single claim. Instead, propose a `narrative arc`: an ordered tier sequence where each tier builds on or deepens the previous one. Ask the user to confirm the arc before handing to Narrator. + +7. Produce a narrative arc when directions stack. + If the selected directions form a sequence, produce a tier-by-tier arc before handing off. Each tier should include: + + - `tier` — position number + - `claim` — the specific evidence-backed assertion for this tier + - `evidence` — the data points that support it + - `chart_form` — the likely visual form + - `transition_to_next` — one sentence explaining what question or tension this tier opens that the next tier resolves + + A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. If the directions do not sequence naturally, present them as parallel options rather than a forced arc. + +8. Handoff to Narrator. + Provide the chosen insight or narrative arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. ## Boundaries diff --git a/plugins/data-vizard/skills/narrator/SKILL.md b/plugins/data-vizard/skills/narrator/SKILL.md index 0b0907f..33efb84 100644 --- a/plugins/data-vizard/skills/narrator/SKILL.md +++ b/plugins/data-vizard/skills/narrator/SKILL.md @@ -36,15 +36,34 @@ Pick the lightest output that does the job. - `minimal copy`: a title, tiny caption, or necessary caveat only. - `guided narrative`: concise title, subtitle, and annotation set. - `editorial narrative`: fuller narrative spine for explanatory work. +- `narrative arc`: multi-tier story mode for when Analyst has produced a tier sequence. Each tier gets its own language load, claim copy, and connective transition to the next. See **Arc Mode** below. Default by posture: - `Explanatory` usually needs `guided narrative` or `editorial narrative`. - `Balanced` usually needs `minimal copy` or `guided narrative`. - `Data-art-led` usually needs `silent brief` or `minimal copy`. +- When Analyst passes a confirmed `narrative_arc`, always use `narrative arc` mode regardless of default posture. For collection-like datasets with strong visual source material, preserve both a restrained utility path and a more atmospheric data-art path until the user or orchestrator chooses between them. Do not collapse to a product-style framing merely because browseability matters. +## Arc Mode + +Use arc mode when Analyst has confirmed a multi-tier narrative arc — an ordered sequence of findings where each tier sets up the next. + +Arc mode produces a **section-by-section brief** rather than a single story spine. For each tier in the arc: + +1. **Assign a language load** — each tier may have a different load based on how much the visual can carry on its own at that point in the reading flow. +2. **Write the tier claim** — a single, evidence-backed statement the reader should walk away with after seeing this tier's visual. No vague conclusions. +3. **Write connective copy** — one or two sentences of transition prose that close the current tier and open the question the next tier answers. This is the copy between sections, not inside them. It should feel like an editorial hand guiding the reader forward, not a summary of what they just saw. +4. **Assign the caveat** — if a caveat applies to only one tier, keep it there. If a caveat applies to the whole piece, surface it once in the header and do not repeat it. + +The last tier needs no transition — it should close with a takeaway that stands on its own. + +Arc mode does not mean more copy overall. The connective lines should be tight (one or two sentences). A tier with a strong visual may only need the connective line and nothing else. Do not fill every tier with a full editorial narrative just because multiple tiers exist. + +When handing off arc mode output to Designer, include per-tier language load and connective copy clearly labeled by tier number, so Designer can position them between sections. + ## Workflow 1. Confirm the chosen analytical direction. @@ -58,8 +77,10 @@ For collection-like datasets with strong visual source material, preserve both a 3. Decide the language load. Choose the lightest contract that still helps the audience understand the piece. -4. Build the story spine only if needed. - Draft the opening question, key observation, supporting sequence, turning point, caveat, and takeaway only when the selected language load calls for it. +4. Build the story spine or arc. + For single-direction work: draft the opening question, key observation, supporting sequence, turning point, caveat, and takeaway only when the selected language load calls for it. + + For multi-tier arc work: follow Arc Mode. Do not flatten the arc into a single spine — each tier must retain its own claim and the connective copy that links it forward. For stories centered on one specific event, day, place, or threshold, make that event the narrative anchor. Do not split the opening across multiple competing labels, tooltips, or section titles that restate the same idea. Merge duplicate framing into one clear opening beat. @@ -93,6 +114,9 @@ For collection-like datasets with strong visual source material, preserve both a - annotation priorities - caveats that must remain visible + For arc mode handoffs, add: + - `arc_tiers` — ordered list of tiers, each with `tier`, `claim`, `language_load`, `visible_copy`, and `transition_to_next` (empty string for the last tier) + `visible_text_inventory` should be a flat list of every visible text surface the current brief permits, such as title, caption, note trigger, tooltip label, or detail label. If a visible text surface is not named in the inventory, Designer should treat it as unauthorized by default. `forbidden_phrases` should list weak or overused phrasings that must not reappear during design. `final_visible_copy` should include the exact approved title, subtitle, section headers, readouts, button labels, and persistent helper lines, or explicitly say when a surface should be assistive-only. diff --git a/skills/data-analyst/SKILL.md b/skills/data-analyst/SKILL.md index 0ff9ed0..b6ac3d3 100644 --- a/skills/data-analyst/SKILL.md +++ b/skills/data-analyst/SKILL.md @@ -61,8 +61,21 @@ Use no more than four options unless the user asks for a broader menu. When usef 6. Ask the user to choose. Present the candidates as button-ready choices. Let the user select one direction, combine directions, or request deeper analysis. -7. Handoff to Narrator. - Provide the chosen insight, supporting evidence, counterpoints, caveats, suggested sequence of facts, and whether the intended output should behave more like an aggregate analysis piece, a browseable archive, or a hybrid. + When the user selects multiple directions or a combined direction that naturally sequences — where one finding sets up the next — do not flatten them into a single claim. Instead, propose a `narrative arc`: an ordered tier sequence where each tier builds on or deepens the previous one. Ask the user to confirm the arc before handing to Narrator. + +7. Produce a narrative arc when directions stack. + If the selected directions form a sequence, produce a tier-by-tier arc before handing off. Each tier should include: + + - `tier` — position number + - `claim` — the specific evidence-backed assertion for this tier + - `evidence` — the data points that support it + - `chart_form` — the likely visual form + - `transition_to_next` — one sentence explaining what question or tension this tier opens that the next tier resolves + + A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. If the directions do not sequence naturally, present them as parallel options rather than a forced arc. + +8. Handoff to Narrator. + Provide the chosen insight or narrative arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. ## Boundaries diff --git a/skills/narrator/SKILL.md b/skills/narrator/SKILL.md index 0b0907f..33efb84 100644 --- a/skills/narrator/SKILL.md +++ b/skills/narrator/SKILL.md @@ -36,15 +36,34 @@ Pick the lightest output that does the job. - `minimal copy`: a title, tiny caption, or necessary caveat only. - `guided narrative`: concise title, subtitle, and annotation set. - `editorial narrative`: fuller narrative spine for explanatory work. +- `narrative arc`: multi-tier story mode for when Analyst has produced a tier sequence. Each tier gets its own language load, claim copy, and connective transition to the next. See **Arc Mode** below. Default by posture: - `Explanatory` usually needs `guided narrative` or `editorial narrative`. - `Balanced` usually needs `minimal copy` or `guided narrative`. - `Data-art-led` usually needs `silent brief` or `minimal copy`. +- When Analyst passes a confirmed `narrative_arc`, always use `narrative arc` mode regardless of default posture. For collection-like datasets with strong visual source material, preserve both a restrained utility path and a more atmospheric data-art path until the user or orchestrator chooses between them. Do not collapse to a product-style framing merely because browseability matters. +## Arc Mode + +Use arc mode when Analyst has confirmed a multi-tier narrative arc — an ordered sequence of findings where each tier sets up the next. + +Arc mode produces a **section-by-section brief** rather than a single story spine. For each tier in the arc: + +1. **Assign a language load** — each tier may have a different load based on how much the visual can carry on its own at that point in the reading flow. +2. **Write the tier claim** — a single, evidence-backed statement the reader should walk away with after seeing this tier's visual. No vague conclusions. +3. **Write connective copy** — one or two sentences of transition prose that close the current tier and open the question the next tier answers. This is the copy between sections, not inside them. It should feel like an editorial hand guiding the reader forward, not a summary of what they just saw. +4. **Assign the caveat** — if a caveat applies to only one tier, keep it there. If a caveat applies to the whole piece, surface it once in the header and do not repeat it. + +The last tier needs no transition — it should close with a takeaway that stands on its own. + +Arc mode does not mean more copy overall. The connective lines should be tight (one or two sentences). A tier with a strong visual may only need the connective line and nothing else. Do not fill every tier with a full editorial narrative just because multiple tiers exist. + +When handing off arc mode output to Designer, include per-tier language load and connective copy clearly labeled by tier number, so Designer can position them between sections. + ## Workflow 1. Confirm the chosen analytical direction. @@ -58,8 +77,10 @@ For collection-like datasets with strong visual source material, preserve both a 3. Decide the language load. Choose the lightest contract that still helps the audience understand the piece. -4. Build the story spine only if needed. - Draft the opening question, key observation, supporting sequence, turning point, caveat, and takeaway only when the selected language load calls for it. +4. Build the story spine or arc. + For single-direction work: draft the opening question, key observation, supporting sequence, turning point, caveat, and takeaway only when the selected language load calls for it. + + For multi-tier arc work: follow Arc Mode. Do not flatten the arc into a single spine — each tier must retain its own claim and the connective copy that links it forward. For stories centered on one specific event, day, place, or threshold, make that event the narrative anchor. Do not split the opening across multiple competing labels, tooltips, or section titles that restate the same idea. Merge duplicate framing into one clear opening beat. @@ -93,6 +114,9 @@ For collection-like datasets with strong visual source material, preserve both a - annotation priorities - caveats that must remain visible + For arc mode handoffs, add: + - `arc_tiers` — ordered list of tiers, each with `tier`, `claim`, `language_load`, `visible_copy`, and `transition_to_next` (empty string for the last tier) + `visible_text_inventory` should be a flat list of every visible text surface the current brief permits, such as title, caption, note trigger, tooltip label, or detail label. If a visible text surface is not named in the inventory, Designer should treat it as unauthorized by default. `forbidden_phrases` should list weak or overused phrasings that must not reappear during design. `final_visible_copy` should include the exact approved title, subtitle, section headers, readouts, button labels, and persistent helper lines, or explicitly say when a surface should be assistive-only. From 094a8a89e2d0eb528d9890342a595bedcb48c376 Mon Sep 17 00:00:00 2001 From: Kenneth Mark Dsouza Date: Wed, 15 Jul 2026 19:53:22 +0530 Subject: [PATCH 6/7] Move multi-tier arc decision to Curator, Analyst receives and structures it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Curator step 6 now detects stackable dimensions and presents a multi-tier arc as a direction option, resolved before Analyst runs. Curator step 9 handoff includes narrative_intent (single or multi-tier arc with tier sequence). Analyst steps 6-7 now receive arc intent from Curator rather than proposing it mid-analysis — Analyst structures and evidences the confirmed arc, not discovers it. Co-Authored-By: Claude Sonnet 4.6 --- .../data-vizard/skills/data-analyst/SKILL.md | 14 +++++++------- .../data-vizard/skills/data-curator/SKILL.md | 6 +++++- plugins/data-vizard/skills/data-analyst/SKILL.md | 14 +++++++------- plugins/data-vizard/skills/data-curator/SKILL.md | 6 +++++- skills/data-analyst/SKILL.md | 14 +++++++------- skills/data-curator/SKILL.md | 6 +++++- 6 files changed, 36 insertions(+), 24 deletions(-) diff --git a/extensions/data-vizard/skills/data-analyst/SKILL.md b/extensions/data-vizard/skills/data-analyst/SKILL.md index b6ac3d3..28daa6b 100644 --- a/extensions/data-vizard/skills/data-analyst/SKILL.md +++ b/extensions/data-vizard/skills/data-analyst/SKILL.md @@ -58,13 +58,13 @@ Use no more than four options unless the user asks for a broader menu. When usef - archive-style navigation - guided discovery instead of one top-line aggregate claim -6. Ask the user to choose. - Present the candidates as button-ready choices. Let the user select one direction, combine directions, or request deeper analysis. +6. Ask the user to choose a single direction, or receive the arc intent from Curator. + If Curator's handoff includes `narrative_intent: single`, present story candidates as button-ready choices and wait for the user to select one. - When the user selects multiple directions or a combined direction that naturally sequences — where one finding sets up the next — do not flatten them into a single claim. Instead, propose a `narrative arc`: an ordered tier sequence where each tier builds on or deepens the previous one. Ask the user to confirm the arc before handing to Narrator. + If Curator's handoff includes `narrative_intent: multi-tier arc` with a confirmed tier sequence, do not re-propose directions. The decision is already made. Proceed to step 7 to structure the arc. -7. Produce a narrative arc when directions stack. - If the selected directions form a sequence, produce a tier-by-tier arc before handing off. Each tier should include: +7. Structure the arc when intent is multi-tier. + Using the tier sequence confirmed by Curator as the frame, build out each tier with evidence from the data. For each tier produce: - `tier` — position number - `claim` — the specific evidence-backed assertion for this tier @@ -72,10 +72,10 @@ Use no more than four options unless the user asks for a broader menu. When usef - `chart_form` — the likely visual form - `transition_to_next` — one sentence explaining what question or tension this tier opens that the next tier resolves - A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. If the directions do not sequence naturally, present them as parallel options rather than a forced arc. + A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. Confirm the structured arc with the user before handing to Narrator. If the evidence does not support a proposed tier, say so and ask whether to drop that tier or replace it. 8. Handoff to Narrator. - Provide the chosen insight or narrative arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. + Provide the chosen insight or confirmed arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. ## Boundaries diff --git a/extensions/data-vizard/skills/data-curator/SKILL.md b/extensions/data-vizard/skills/data-curator/SKILL.md index 8043bf9..ff69575 100644 --- a/extensions/data-vizard/skills/data-curator/SKILL.md +++ b/extensions/data-vizard/skills/data-curator/SKILL.md @@ -50,6 +50,8 @@ Use no more than four options unless the user asks for a broader menu. Include ` 6. Ask about narrative posture and analytical direction. Based on what the data can support, present posture options and 2–3 concrete analytical directions as button-ready choices. Do not ask posture and direction as separate questions — combine them into one interaction so the user makes one decision that unblocks both. Let the data shape which postures are realistic: aggregate-structured data suggests `Explanatory` or `Balanced`; record-level or collection data suggests `Balanced explorer` or `Data-art-led`. Wait for the user to decide before proceeding to cleaning and shaping. + If the data has multiple natural dimensions that stack — where one cut answers the question opened by the previous cut — include a multi-tier arc as one of the direction options. Name the proposed tier sequence explicitly (e.g. "books → scene types" or "city → neighbourhood → building") and explain what each tier reveals that the previous one cannot. Ask whether the user wants a layered arc or a single-tier story. This decision must be made here, not discovered mid-analysis by Analyst. + 7. Propose cleaning and shaping actions. Suggest transformations such as type fixes, normalization, pivoting, aggregation, deduplication, derived fields, and joins. Use button-ready choices for actions that affect meaning. @@ -64,11 +66,13 @@ Use no more than four options unless the user asks for a broader menu. Include ` If the analysis would be weak without context, propose enrichment datasets. Explain why each source helps and how it would join. 9. Produce handoff notes. - Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, and the likely artifact mode: + Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, confirmed narrative intent, and the likely artifact mode: - `aggregate analysis` - `record-by-record exploration` - `hybrid` + `narrative_intent` should be either `single` (one analytical direction, one story) or `multi-tier arc` with the confirmed tier sequence listed in order. Analyst uses this to know upfront whether to build a single story or structure an arc. + ## API Source Rules When the source is an API: diff --git a/plugins/data-vizard/skills/data-analyst/SKILL.md b/plugins/data-vizard/skills/data-analyst/SKILL.md index b6ac3d3..28daa6b 100644 --- a/plugins/data-vizard/skills/data-analyst/SKILL.md +++ b/plugins/data-vizard/skills/data-analyst/SKILL.md @@ -58,13 +58,13 @@ Use no more than four options unless the user asks for a broader menu. When usef - archive-style navigation - guided discovery instead of one top-line aggregate claim -6. Ask the user to choose. - Present the candidates as button-ready choices. Let the user select one direction, combine directions, or request deeper analysis. +6. Ask the user to choose a single direction, or receive the arc intent from Curator. + If Curator's handoff includes `narrative_intent: single`, present story candidates as button-ready choices and wait for the user to select one. - When the user selects multiple directions or a combined direction that naturally sequences — where one finding sets up the next — do not flatten them into a single claim. Instead, propose a `narrative arc`: an ordered tier sequence where each tier builds on or deepens the previous one. Ask the user to confirm the arc before handing to Narrator. + If Curator's handoff includes `narrative_intent: multi-tier arc` with a confirmed tier sequence, do not re-propose directions. The decision is already made. Proceed to step 7 to structure the arc. -7. Produce a narrative arc when directions stack. - If the selected directions form a sequence, produce a tier-by-tier arc before handing off. Each tier should include: +7. Structure the arc when intent is multi-tier. + Using the tier sequence confirmed by Curator as the frame, build out each tier with evidence from the data. For each tier produce: - `tier` — position number - `claim` — the specific evidence-backed assertion for this tier @@ -72,10 +72,10 @@ Use no more than four options unless the user asks for a broader menu. When usef - `chart_form` — the likely visual form - `transition_to_next` — one sentence explaining what question or tension this tier opens that the next tier resolves - A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. If the directions do not sequence naturally, present them as parallel options rather than a forced arc. + A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. Confirm the structured arc with the user before handing to Narrator. If the evidence does not support a proposed tier, say so and ask whether to drop that tier or replace it. 8. Handoff to Narrator. - Provide the chosen insight or narrative arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. + Provide the chosen insight or confirmed arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. ## Boundaries diff --git a/plugins/data-vizard/skills/data-curator/SKILL.md b/plugins/data-vizard/skills/data-curator/SKILL.md index 8043bf9..ff69575 100644 --- a/plugins/data-vizard/skills/data-curator/SKILL.md +++ b/plugins/data-vizard/skills/data-curator/SKILL.md @@ -50,6 +50,8 @@ Use no more than four options unless the user asks for a broader menu. Include ` 6. Ask about narrative posture and analytical direction. Based on what the data can support, present posture options and 2–3 concrete analytical directions as button-ready choices. Do not ask posture and direction as separate questions — combine them into one interaction so the user makes one decision that unblocks both. Let the data shape which postures are realistic: aggregate-structured data suggests `Explanatory` or `Balanced`; record-level or collection data suggests `Balanced explorer` or `Data-art-led`. Wait for the user to decide before proceeding to cleaning and shaping. + If the data has multiple natural dimensions that stack — where one cut answers the question opened by the previous cut — include a multi-tier arc as one of the direction options. Name the proposed tier sequence explicitly (e.g. "books → scene types" or "city → neighbourhood → building") and explain what each tier reveals that the previous one cannot. Ask whether the user wants a layered arc or a single-tier story. This decision must be made here, not discovered mid-analysis by Analyst. + 7. Propose cleaning and shaping actions. Suggest transformations such as type fixes, normalization, pivoting, aggregation, deduplication, derived fields, and joins. Use button-ready choices for actions that affect meaning. @@ -64,11 +66,13 @@ Use no more than four options unless the user asks for a broader menu. Include ` If the analysis would be weak without context, propose enrichment datasets. Explain why each source helps and how it would join. 9. Produce handoff notes. - Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, and the likely artifact mode: + Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, confirmed narrative intent, and the likely artifact mode: - `aggregate analysis` - `record-by-record exploration` - `hybrid` + `narrative_intent` should be either `single` (one analytical direction, one story) or `multi-tier arc` with the confirmed tier sequence listed in order. Analyst uses this to know upfront whether to build a single story or structure an arc. + ## API Source Rules When the source is an API: diff --git a/skills/data-analyst/SKILL.md b/skills/data-analyst/SKILL.md index b6ac3d3..28daa6b 100644 --- a/skills/data-analyst/SKILL.md +++ b/skills/data-analyst/SKILL.md @@ -58,13 +58,13 @@ Use no more than four options unless the user asks for a broader menu. When usef - archive-style navigation - guided discovery instead of one top-line aggregate claim -6. Ask the user to choose. - Present the candidates as button-ready choices. Let the user select one direction, combine directions, or request deeper analysis. +6. Ask the user to choose a single direction, or receive the arc intent from Curator. + If Curator's handoff includes `narrative_intent: single`, present story candidates as button-ready choices and wait for the user to select one. - When the user selects multiple directions or a combined direction that naturally sequences — where one finding sets up the next — do not flatten them into a single claim. Instead, propose a `narrative arc`: an ordered tier sequence where each tier builds on or deepens the previous one. Ask the user to confirm the arc before handing to Narrator. + If Curator's handoff includes `narrative_intent: multi-tier arc` with a confirmed tier sequence, do not re-propose directions. The decision is already made. Proceed to step 7 to structure the arc. -7. Produce a narrative arc when directions stack. - If the selected directions form a sequence, produce a tier-by-tier arc before handing off. Each tier should include: +7. Structure the arc when intent is multi-tier. + Using the tier sequence confirmed by Curator as the frame, build out each tier with evidence from the data. For each tier produce: - `tier` — position number - `claim` — the specific evidence-backed assertion for this tier @@ -72,10 +72,10 @@ Use no more than four options unless the user asks for a broader menu. When usef - `chart_form` — the likely visual form - `transition_to_next` — one sentence explaining what question or tension this tier opens that the next tier resolves - A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. If the directions do not sequence naturally, present them as parallel options rather than a forced arc. + A good arc has forward momentum: each tier should make the next tier feel necessary, not optional. Confirm the structured arc with the user before handing to Narrator. If the evidence does not support a proposed tier, say so and ask whether to drop that tier or replace it. 8. Handoff to Narrator. - Provide the chosen insight or narrative arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. + Provide the chosen insight or confirmed arc, supporting evidence, counterpoints, caveats, suggested sequence of facts, confirmed artifact mode, and confirmed posture. For multi-tier work, hand off the full arc structure so Narrator can assign language load and connective copy per tier. ## Boundaries diff --git a/skills/data-curator/SKILL.md b/skills/data-curator/SKILL.md index 8043bf9..ff69575 100644 --- a/skills/data-curator/SKILL.md +++ b/skills/data-curator/SKILL.md @@ -50,6 +50,8 @@ Use no more than four options unless the user asks for a broader menu. Include ` 6. Ask about narrative posture and analytical direction. Based on what the data can support, present posture options and 2–3 concrete analytical directions as button-ready choices. Do not ask posture and direction as separate questions — combine them into one interaction so the user makes one decision that unblocks both. Let the data shape which postures are realistic: aggregate-structured data suggests `Explanatory` or `Balanced`; record-level or collection data suggests `Balanced explorer` or `Data-art-led`. Wait for the user to decide before proceeding to cleaning and shaping. + If the data has multiple natural dimensions that stack — where one cut answers the question opened by the previous cut — include a multi-tier arc as one of the direction options. Name the proposed tier sequence explicitly (e.g. "books → scene types" or "city → neighbourhood → building") and explain what each tier reveals that the previous one cannot. Ask whether the user wants a layered arc or a single-tier story. This decision must be made here, not discovered mid-analysis by Analyst. + 7. Propose cleaning and shaping actions. Suggest transformations such as type fixes, normalization, pivoting, aggregation, deduplication, derived fields, and joins. Use button-ready choices for actions that affect meaning. @@ -64,11 +66,13 @@ Use no more than four options unless the user asks for a broader menu. Include ` If the analysis would be weak without context, propose enrichment datasets. Explain why each source helps and how it would join. 9. Produce handoff notes. - Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, and the likely artifact mode: + Give Data Analyst a concise data dictionary, transformation log, acquisition notes, caveats, confirmed posture, confirmed analytical direction, confirmed narrative intent, and the likely artifact mode: - `aggregate analysis` - `record-by-record exploration` - `hybrid` + `narrative_intent` should be either `single` (one analytical direction, one story) or `multi-tier arc` with the confirmed tier sequence listed in order. Analyst uses this to know upfront whether to build a single story or structure an arc. + ## API Source Rules When the source is an API: From 2a9590a32d8f30f815d96c479ce03bd6c3c7183b Mon Sep 17 00:00:00 2001 From: Kenneth Mark Dsouza Date: Wed, 15 Jul 2026 20:01:54 +0530 Subject: [PATCH 7/7] committing the domain name --- CNAME | 1 + ...nvestigation Challenge Code of Conduct .md | 20 ++ data/gen-ai-newsroom/Challenge Details.md | 55 ++++ .../curated/book_adaptation.csv | 24 ++ .../curated/event_adaptation.csv | 11 + .../curated/genre_adaptation.csv | 12 + outcome/gutenberg-adaptation/index.html | 63 ++++ outcome/gutenberg-adaptation/script.js | 153 ++++++++++ outcome/gutenberg-adaptation/styles.css | 273 ++++++++++++++++++ 9 files changed, 612 insertions(+) create mode 100644 CNAME create mode 100644 data/gen-ai-newsroom/Agentic Investigation Challenge Code of Conduct .md create mode 100644 data/gen-ai-newsroom/Challenge Details.md create mode 100644 data/gutenberg-adaptation/curated/book_adaptation.csv create mode 100644 data/gutenberg-adaptation/curated/event_adaptation.csv create mode 100644 data/gutenberg-adaptation/curated/genre_adaptation.csv create mode 100644 outcome/gutenberg-adaptation/index.html create mode 100644 outcome/gutenberg-adaptation/script.js create mode 100644 outcome/gutenberg-adaptation/styles.css diff --git a/CNAME b/CNAME new file mode 100644 index 0000000..084ed04 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +www.data-vizard.com diff --git a/data/gen-ai-newsroom/Agentic Investigation Challenge Code of Conduct .md b/data/gen-ai-newsroom/Agentic Investigation Challenge Code of Conduct .md new file mode 100644 index 0000000..3c6b9e4 --- /dev/null +++ b/data/gen-ai-newsroom/Agentic Investigation Challenge Code of Conduct .md @@ -0,0 +1,20 @@ +# Code of Conduct + +## Northwestern Agentic AI Investigative Journalism Challenge + +This competition produces investigative claims about real individuals and organizations using AI-assisted tooling. Participants come from newsrooms, universities, and civic tech, and bring a range of training. This Code of Conduct sets shared expectations for editorial judgment, responsible use of AI, data handling, and community behavior. Registering a team constitutes agreement by all team members. + +**Editorial and investigative conduct.** Apply newsroom standards of verification throughout. Every factual claim in a findings report must be traceable to specific records in the provided corpus and spot-checked by a human team member before submission. Do not fabricate, synthesize, or illustratively invent documents, quotes, or records presented as if drawn from the corpus. Characterize what the data shows without asserting motive, wrongdoing, or legal violations unless the evidence genuinely supports that framing. If your findings suggest possible legal violations, flag them to the evaluation panel in your report. Inclusion in the skills catalog or a GAIN blog post is not equivalent to publishing an investigation; teams that later pursue external publication are expected to follow standard pre-publication practices, including right of reply. If you discover a factual error after submitting, notify the panel; catalog entries will be corrected or withdrawn as warranted. + +**Prior work and publication checks.** Before submitting findings, teams must make a good-faith effort to determine whether the same factual claim, pattern, or allegation has already been reported, published, or otherwise made public. AI tools may assist with this check, but teams are responsible for verifying whether prior reporting exists. If a finding builds on, confirms, extends, or overlaps with prior work, the submission must clearly attribute that work and distinguish what the team independently verified in the provided corpus from what was learned from outside reporting. Teams must not present previously published reporting, analysis, language, framing, or conclusions as their own original discovery. Close paraphrase of outside work without attribution is not acceptable, even if produced by an AI system. + +**Responsible use of AI tooling.** Human oversight is required on consequential claims. Agent outputs that name specific individuals or organizations as subjects of findings must be reviewed by a human team member, and interaction traces should show where that review occurred. Provenance is non-negotiable: outputs without traceable sourcing will not meet the competition's bar. Teams agree that their skills, prompts, and interaction traces will be reviewable by the panel and, for catalog entries, publishable—do not include anything in a submission you are not comfortable being public. Use of competition tooling to investigate or target private individuals (e.g., doxxing) outside the provided corpus is out of scope. + +**Data handling.** Use the provided corpus as provided. Do not augment with outside data about named individuals without disclosing it in the findings report. Do not attempt to re-identify, contact, or surveil individuals named in filings as part of the competition work, and do not incorporate confidential or non-public data into your investigation. Respect the source terms of use for the underlying datasets. + +**Attribution and originality.** Teams may build on existing open-source journalism skills and must attribute them clearly in `SKILL.md` and the findings report. AI-assisted development is expected and encouraged; wholesale submission of another team's or project's work is not. Teams agree to publish catalog-included submissions under the [MIT license](https://opensource.org/license/mit). + +**Conflicts of interest.** If any team member has a professional or financial relationship with an entity that appears prominently in their findings, disclose it as part of the submission. + +**Community conduct.** Interact respectfully in all competition venues, including shared channels and presentations. Harassment, discrimination, and targeted hostility are not tolerated. Raising a concern in good faith will not affect competition judging. + diff --git a/data/gen-ai-newsroom/Challenge Details.md b/data/gen-ai-newsroom/Challenge Details.md new file mode 100644 index 0000000..dec0f9d --- /dev/null +++ b/data/gen-ai-newsroom/Challenge Details.md @@ -0,0 +1,55 @@ +Challenge Details + +Dataset, submission, and evaluation + +Everything you need to decide whether to compete + + +The dataset +We’re providing a federal-government corpus centered on who is paying whom to shape policy, and how those efforts are described in public. It covers 2022 through March 2026 and combines two complementary record types: + +Congressional lobbying filings from both chambers: registrants, clients, issue areas, and the staff moving between private firms and government offices. +Congressional press releases from the Congress Press corpus. +Registered teams receive the prepared corpus along with a manual describing its structure and contents. + +What teams submit +We want teams to put in their best effort at uncovering genuinely newsworthy findings using AI agents. Dig into the provided corpus, bring in outside sources, pursue whatever seems interesting or important to you. Then — and this is the part that makes the competition matter beyond your own story — package up the workflows, prompts, and tools you built along the way into an Agent Skill that someone else could pick up and use on a different investigation. + +An Agent Skill is a directory of instructions, scripts, and reference material that extends what a coding agent can do. The format is defined by the Agent Skills specification: a SKILL.md with YAML frontmatter and instructions, plus optional scripts/, references/, and assets/. Skills are more powerful than they look — if you haven’t built one before, these collections of journalism-oriented examples are a good starting point: + +Florent Daudens — AI Journalism Skills +Joe Amditis — claude-skills-journalism +The skill you submit should capture things that would generalize past this particular investigation: a pattern for resolving messy entities, a review interface that makes provenance easy to check, a workflow that keeps a long-running investigation oriented across sessions. The specifics are up to you. + +Each submission package contains four things: + +Agent Skill(s). The primary artifact — the reusable workflow you built. You can bundle multiple skills that compose together. Skills should be self-contained and validate cleanly against the specification. +Findings report. A written summary of the newsworthy discoveries you produced by running the skill(s) on the corpus (and any outside material you brought in). +Interaction traces. Full logs of the model sessions, either as raw JSON or as a rendered page, including inputs, tool calls, outputs, and the moments where human judgment intervened. Traces should be keyed to the skill invocations they came from. +README.md. A brief map of the submission: included skills, which findings they support, where the relevant traces are located, any outside data used, any conflicts of interest, and whether findings suggest possible legal violations that should be flagged to the evaluation panel. +How we evaluate +A panel of journalists and technologists reviews each submission. There are two things they’re looking at: whether your findings hold up as journalism, and whether your skill is something another team could actually pick up and use. + +Are the findings real? +Before anything else, panelists spot-check your findings report. Claims need to be accurate, sourced back to specific records, and of genuine public interest — undisclosed relationships, timing anomalies, spending patterns, that sort of thing. A polished summary of what the dataset contains isn’t a finding; something a reporter would chase is. Submissions that don’t clear this bar aren’t ranked further. + +Is the skill useful? +Once findings clear that bar, the panel scores your skill on four dimensions. Panelists score each of the four technical dimensions independently on a 0-3 rubric, and the four dimensions are weighted equally by default. Reproducibility is assumed throughout: if an evaluator can’t re-run your skill, it cannot score above 1 on any dimension, regardless of how impressive it looks on paper. + +Does it keep the investigation organized? +Investigations span days, sessions, and new leads that arrive mid-stream. A strong skill keeps track of what’s been checked, what’s still open, which entities matter, and which threads went cold, so the journalist doesn’t have to re-brief the agent every time they come back to it. + +Is it efficient with the corpus? +Feeding thousands of documents through a model is expensive and slow. A strong skill pushes the heavy lifting — extraction, filtering, indexing, aggregation — to deterministic tools and cheaper models, so the main agent spends its budget on reasoning rather than scanning. + +Can a human verify the work? +A reporter has to be able to stand behind what the agent produced. A strong skill ties every claim back to a specific source, presents evidence in a form that’s fast to review, and leaves a trace an editor could audit without re-doing the work. + +Does it extend what an agent can do for investigations? +The most interesting skills provide real, novel capabilities: entity resolvers, cross-reference utilities, document-network traversal, domain-specific parsers. Tools that handle the messy, investigation-specific problems a generic coding agent can’t solve on its own, and that other teams could lift into their own work. + +What gets published +Top submissions win cash prizes, get individual writeups on the GAIN blog, and may be invited to present their work at the Computation + Journalism Symposium. Any submission that clears the findings bar, validates against the Agent Skills specification, and shows real effort on all four dimensions above is included in a public, open source skills catalog. + +Ethical considerations +Investigative findings may implicate real individuals and organizations. Teams should exercise the same editorial judgment they would apply in a newsroom context. If findings suggest potential legal violations, note that in the findings report and flag it to the evaluation panel. All participants agree to the code of conduct on registration. \ No newline at end of file diff --git a/data/gutenberg-adaptation/curated/book_adaptation.csv b/data/gutenberg-adaptation/curated/book_adaptation.csv new file mode 100644 index 0000000..4b6d86b --- /dev/null +++ b/data/gutenberg-adaptation/curated/book_adaptation.csv @@ -0,0 +1,24 @@ +book_title,author,publication_year,genre,Retain,Condense,Reorder,Omit,Merge,total,retain_pct,omit_pct,cut_rate +Pride and Prejudice,Jane Austen,1813,Romance,190,286,178,125,92,871,21.8,14.4,47.2 +Frankenstein,Mary Shelley,1818,Gothic_SciFi,168,244,182,150,95,839,20.0,17.9,47.0 +A Christmas Carol,Charles Dickens,1843,Drama,278,216,141,104,81,820,33.9,12.7,39.0 +The Count of Monte Cristo,Alexandre Dumas,1844,Adventure,174,287,182,134,73,850,20.5,15.8,49.5 +Moby Dick,Herman Melville,1851,Adventure,152,268,181,200,83,884,17.2,22.6,52.9 +A Tale of Two Cities,Charles Dickens,1859,Historical,209,270,156,147,81,863,24.2,17.0,48.3 +Great Expectations,Charles Dickens,1861,Drama,183,273,173,151,75,855,21.4,17.7,49.6 +Alice's Adventures in Wonderland,Lewis Carroll,1865,Fantasy,42,80,44,41,16,223,18.8,18.4,54.3 +Crime and Punishment,Fyodor Dostoevsky,1866,Psychological,214,220,175,134,105,848,25.2,15.8,41.7 +Little Women,Louisa May Alcott,1868,Drama,206,279,158,132,79,854,24.1,15.5,48.1 +War and Peace,Leo Tolstoy,1869,Historical,212,295,168,127,91,893,23.7,14.2,47.3 +The Adventures of Tom Sawyer,Mark Twain,1876,Adventure,225,204,171,132,96,828,27.2,15.9,40.6 +Anna Karenina,Leo Tolstoy,1877,Romance,208,268,155,149,76,856,24.3,17.4,48.7 +Treasure Island,Robert Louis Stevenson,1883,Adventure,184,291,151,159,72,857,21.5,18.6,52.5 +Adventures of Huckleberry Finn,Mark Twain,1884,Adventure,211,236,174,152,81,854,24.7,17.8,45.4 +The Strange Case of Dr. Jekyll and Mr. Hyde,Robert Louis Stevenson,1886,Horror,106,187,83,105,49,530,20.0,19.8,55.1 +The Picture of Dorian Gray,Oscar Wilde,1890,Gothic,212,205,199,130,103,849,25.0,15.3,39.5 +The Adventures of Sherlock Holmes,Arthur Conan Doyle,1892,Mystery,204,264,182,125,79,854,23.9,14.6,45.6 +The Jungle Book,Rudyard Kipling,1894,Adventure,219,279,159,116,87,860,25.5,13.5,45.9 +The Time Machine,H.G. Wells,1895,SciFi,177,211,219,129,80,816,21.7,15.8,41.7 +Dracula,Bram Stoker,1897,Horror,184,247,193,127,103,854,21.5,14.9,43.8 +The Wonderful Wizard of Oz,L. Frank Baum,1900,Fantasy,134,241,140,111,80,706,19.0,15.7,49.9 +Peter Pan,J.M. Barrie,1911,Fantasy,178,274,177,119,88,836,21.3,14.2,47.0 diff --git a/data/gutenberg-adaptation/curated/event_adaptation.csv b/data/gutenberg-adaptation/curated/event_adaptation.csv new file mode 100644 index 0000000..91bd637 --- /dev/null +++ b/data/gutenberg-adaptation/curated/event_adaptation.csv @@ -0,0 +1,11 @@ +event_type,Retain,Condense,Reorder,Omit,Merge,total,retain_pct,omit_pct +Dialogue,357,986,597,369,292,2601,13.7,14.2 +Confrontation,974,718,397,266,179,2534,38.4,10.5 +Revelation,1037,711,371,245,161,2525,41.1,9.7 +Conflict,433,745,460,453,219,2310,18.7,19.6 +Romance,317,680,383,375,223,1978,16.0,19.0 +Arrival,223,387,306,253,176,1345,16.6,18.8 +Journey,232,364,301,268,150,1315,17.6,20.4 +Betrayal,247,346,303,247,165,1308,18.9,18.9 +Climax,222,362,322,244,150,1300,17.1,18.8 +Discovery,228,326,301,279,150,1284,17.8,21.7 diff --git a/data/gutenberg-adaptation/curated/genre_adaptation.csv b/data/gutenberg-adaptation/curated/genre_adaptation.csv new file mode 100644 index 0000000..f586348 --- /dev/null +++ b/data/gutenberg-adaptation/curated/genre_adaptation.csv @@ -0,0 +1,12 @@ +genre,Retain,Condense,Reorder,Omit,Merge,total,retain_pct,omit_pct,condense_pct +Adventure,1165,1565,1018,893,492,5133,22.7,17.4,30.5 +Drama,667,768,472,387,235,2529,26.4,15.3,30.4 +Fantasy,354,595,361,271,184,1765,20.1,15.4,33.7 +Gothic,212,205,199,130,103,849,25.0,15.3,24.1 +Gothic_SciFi,168,244,182,150,95,839,20.0,17.9,29.1 +Historical,421,565,324,274,172,1756,24.0,15.6,32.2 +Horror,290,434,276,232,152,1384,21.0,16.8,31.4 +Mystery,204,264,182,125,79,854,23.9,14.6,30.9 +Psychological,214,220,175,134,105,848,25.2,15.8,25.9 +Romance,398,554,333,274,168,1727,23.0,15.9,32.1 +SciFi,177,211,219,129,80,816,21.7,15.8,25.9 diff --git a/outcome/gutenberg-adaptation/index.html b/outcome/gutenberg-adaptation/index.html new file mode 100644 index 0000000..44d3ff4 --- /dev/null +++ b/outcome/gutenberg-adaptation/index.html @@ -0,0 +1,63 @@ + + + + + + What Makes the Cut — Literary Adaptation Patterns + + + + + +
+

Literary Adaptation · Project Gutenberg Dataset

+

What Makes
the Cut

+

Across 23 classic novels, adaptation has a clear grammar. Some books survive nearly intact. Others are gutted. And the type of scene matters as much as the book it comes from.

+

These labels are model-recommended adaptation strategies from an NLP research dataset, not records of what any specific film production actually did.

+
+ +
+
Retain
+
Condense
+
Reorder
+
Omit
+
Merge
+
+ + +
+

Part One

+

The Spectrum

+

23 novels, ranked by how much of their text a screenplay adaptation would keep unchanged. Each bar shows the full fate of the book's excerpts.

+ +
+ +
+ A Christmas Carol sits at one extreme — 34% of its excerpts retained, the highest in the set. It is short, tightly structured, and its scenes carry weight individually. At the other end, Moby Dick loses more than any other: 23% omitted outright, only 17% kept. Its pages of cetology and digression have no equivalent in film time. +
+
+ +
+ + +
+

Part Two

+

What Survives the Edit

+

Across all 23 books, some types of scenes are far more likely to survive than others. The pattern reveals what film adaptation is actually doing to literary text.

+ +
+ +
+ Revelations and confrontations are the most preserved scene types — plot pivots that carry story forward survive. Dialogue is the most compressed: 38% condensed, only 14% kept intact. Conversations get collapsed. Romance and conflict scenes face the highest omit rates — emotional texture is what adaptation sacrifices first. +
+
+ + + +
+ + + diff --git a/outcome/gutenberg-adaptation/script.js b/outcome/gutenberg-adaptation/script.js new file mode 100644 index 0000000..e0a45c3 --- /dev/null +++ b/outcome/gutenberg-adaptation/script.js @@ -0,0 +1,153 @@ +const LABELS = ['Retain', 'Condense', 'Reorder', 'Omit', 'Merge']; +const CLASSES = ['retain-bar', 'condense-bar', 'reorder-bar', 'omit-bar', 'merge-bar']; + +const BOOKS = [ + { title: "A Christmas Carol", author: "Charles Dickens", year: 1843, genre: "Drama", Retain: 278, Condense: 216, Reorder: 141, Omit: 104, Merge: 81 }, + { title: "The Adventures of Tom Sawyer", author: "Mark Twain", year: 1876, genre: "Adventure", Retain: 225, Condense: 204, Reorder: 171, Omit: 132, Merge: 96 }, + { title: "The Jungle Book", author: "Rudyard Kipling", year: 1894, genre: "Adventure", Retain: 219, Condense: 279, Reorder: 159, Omit: 116, Merge: 87 }, + { title: "Crime and Punishment", author: "Fyodor Dostoevsky", year: 1866, genre: "Psychological", Retain: 214, Condense: 220, Reorder: 175, Omit: 134, Merge: 105 }, + { title: "The Picture of Dorian Gray", author: "Oscar Wilde", year: 1890, genre: "Gothic", Retain: 212, Condense: 205, Reorder: 199, Omit: 130, Merge: 103 }, + { title: "War and Peace", author: "Leo Tolstoy", year: 1869, genre: "Historical", Retain: 212, Condense: 295, Reorder: 168, Omit: 127, Merge: 91 }, + { title: "Adventures of Huckleberry Finn", author: "Mark Twain", year: 1884, genre: "Adventure", Retain: 211, Condense: 236, Reorder: 174, Omit: 152, Merge: 81 }, + { title: "Anna Karenina", author: "Leo Tolstoy", year: 1877, genre: "Romance", Retain: 208, Condense: 268, Reorder: 155, Omit: 149, Merge: 76 }, + { title: "A Tale of Two Cities", author: "Charles Dickens", year: 1859, genre: "Historical", Retain: 209, Condense: 270, Reorder: 156, Omit: 147, Merge: 81 }, + { title: "Little Women", author: "Louisa May Alcott", year: 1868, genre: "Drama", Retain: 206, Condense: 279, Reorder: 158, Omit: 132, Merge: 79 }, + { title: "The Adventures of Sherlock Holmes", author: "Arthur Conan Doyle", year: 1892, genre: "Mystery", Retain: 204, Condense: 264, Reorder: 182, Omit: 125, Merge: 79 }, + { title: "Pride and Prejudice", author: "Jane Austen", year: 1813, genre: "Romance", Retain: 190, Condense: 286, Reorder: 178, Omit: 125, Merge: 92 }, + { title: "Great Expectations", author: "Charles Dickens", year: 1861, genre: "Drama", Retain: 183, Condense: 273, Reorder: 173, Omit: 151, Merge: 75 }, + { title: "Treasure Island", author: "Robert Louis Stevenson", year: 1883, genre: "Adventure", Retain: 184, Condense: 291, Reorder: 151, Omit: 159, Merge: 72 }, + { title: "Dracula", author: "Bram Stoker", year: 1897, genre: "Horror", Retain: 184, Condense: 247, Reorder: 193, Omit: 127, Merge: 103 }, + { title: "Peter Pan", author: "J.M. Barrie", year: 1911, genre: "Fantasy", Retain: 178, Condense: 274, Reorder: 177, Omit: 119, Merge: 88 }, + { title: "The Time Machine", author: "H.G. Wells", year: 1895, genre: "SciFi", Retain: 177, Condense: 211, Reorder: 219, Omit: 129, Merge: 80 }, + { title: "The Count of Monte Cristo", author: "Alexandre Dumas", year: 1844, genre: "Adventure", Retain: 174, Condense: 287, Reorder: 182, Omit: 134, Merge: 73 }, + { title: "Great Expectations", author: "Charles Dickens", year: 1861, genre: "Drama", Retain: 183, Condense: 273, Reorder: 173, Omit: 151, Merge: 75 }, + { title: "The Wonderful Wizard of Oz", author: "L. Frank Baum", year: 1900, genre: "Fantasy", Retain: 134, Condense: 241, Reorder: 140, Omit: 111, Merge: 80 }, + { title: "Alice's Adventures in Wonderland", author: "Lewis Carroll", year: 1865, genre: "Fantasy", Retain: 42, Condense: 80, Reorder: 44, Omit: 41, Merge: 16 }, + { title: "The Strange Case of Dr. Jekyll and Mr. Hyde", author: "Robert Louis Stevenson", year: 1886, genre: "Horror", Retain: 106, Condense: 187, Reorder: 83, Omit: 105, Merge: 49 }, + { title: "Moby Dick", author: "Herman Melville", year: 1851, genre: "Adventure", Retain: 152, Condense: 268, Reorder: 181, Omit: 200, Merge: 83 }, + { title: "Frankenstein", author: "Mary Shelley", year: 1818, genre: "Gothic_SciFi", Retain: 168, Condense: 244, Reorder: 182, Omit: 150, Merge: 95 }, +]; + +const EVENTS = [ + { type: "Revelation", Retain: 1037, Condense: 711, Reorder: 371, Omit: 245, Merge: 161 }, + { type: "Confrontation", Retain: 974, Condense: 718, Reorder: 397, Omit: 266, Merge: 179 }, + { type: "Betrayal", Retain: 247, Condense: 346, Reorder: 303, Omit: 247, Merge: 165 }, + { type: "Conflict", Retain: 433, Condense: 745, Reorder: 460, Omit: 453, Merge: 219 }, + { type: "Discovery", Retain: 228, Condense: 326, Reorder: 301, Omit: 279, Merge: 150 }, + { type: "Journey", Retain: 232, Condense: 364, Reorder: 301, Omit: 268, Merge: 150 }, + { type: "Climax", Retain: 222, Condense: 362, Reorder: 322, Omit: 244, Merge: 150 }, + { type: "Arrival", Retain: 223, Condense: 387, Reorder: 306, Omit: 253, Merge: 176 }, + { type: "Romance", Retain: 317, Condense: 680, Reorder: 383, Omit: 375, Merge: 223 }, + { type: "Dialogue", Retain: 357, Condense: 986, Reorder: 597, Omit: 369, Merge: 292 }, +]; + +// Deduplicate books by title, keep highest retain +const seen = new Set(); +const BOOKS_DEDUPED = BOOKS.filter(b => { + if (seen.has(b.title)) return false; + seen.add(b.title); + return true; +}).map(b => { + const total = LABELS.reduce((s, l) => s + b[l], 0); + const pct = {}; + LABELS.forEach(l => pct[l] = b[l] / total * 100); + return { ...b, total, pct }; +}).sort((a, b) => b.pct.Retain - a.pct.Retain); + +const EVENTS_PROCESSED = EVENTS.map(e => { + const total = LABELS.reduce((s, l) => s + e[l], 0); + const pct = {}; + LABELS.forEach(l => pct[l] = e[l] / total * 100); + return { ...e, total, pct }; +}); + +// Tooltip +const tooltip = document.getElementById('tooltip'); + +function showTooltip(e, rows) { + tooltip.innerHTML = rows.join('
'); + tooltip.classList.add('visible'); + moveTooltip(e); +} + +function moveTooltip(e) { + const x = e.clientX + 14; + const y = e.clientY - 10; + tooltip.style.left = Math.min(x, window.innerWidth - 240) + 'px'; + tooltip.style.top = y + 'px'; +} + +function hideTooltip() { tooltip.classList.remove('visible'); } + +function buildBar(data, labelKey, isEvent = false) { + const row = document.createElement('div'); + row.className = 'chart-row' + (isEvent ? ' event-row' : ''); + + const labelEl = document.createElement('div'); + labelEl.className = 'chart-label'; + if (isEvent) { + labelEl.textContent = data[labelKey]; + } else { + const short = data.title.length > 28 ? data.title.slice(0, 26) + '…' : data.title; + labelEl.innerHTML = `${short}${data.author}, ${data.year}`; + } + + const barWrap = document.createElement('div'); + barWrap.className = 'bar-row-wrap'; + + const track = document.createElement('div'); + track.className = 'bar-track'; + track.style.flex = '1'; + + LABELS.forEach((label, i) => { + const seg = document.createElement('div'); + seg.className = `bar-segment ${CLASSES[i]}`; + seg.style.width = data.pct[label].toFixed(2) + '%'; + + const count = data[label]; + const pct = data.pct[label].toFixed(1); + seg.addEventListener('mousemove', e => { + showTooltip(e, [ + `${isEvent ? data.type : data.title}`, + `${label}: ${count} excerpts (${pct}%)` + ]); + moveTooltip(e); + }); + seg.addEventListener('mouseleave', hideTooltip); + + track.appendChild(seg); + }); + + const pctLabel = document.createElement('span'); + pctLabel.className = 'chart-pct'; + pctLabel.textContent = data.pct.Retain.toFixed(0) + '% kept'; + + barWrap.appendChild(track); + barWrap.appendChild(pctLabel); + + row.appendChild(labelEl); + row.appendChild(barWrap); + return row; +} + +function buildAxisRow(isEvent = false) { + const row = document.createElement('div'); + row.className = 'axis-row' + (isEvent ? ' event-axis' : ''); + const empty = document.createElement('div'); + const labels = document.createElement('div'); + labels.className = 'axis-labels'; + labels.innerHTML = '0%50%100%'; + row.appendChild(empty); + row.appendChild(labels); + return row; +} + +// Render books +const bookChart = document.getElementById('book-chart'); +bookChart.appendChild(buildAxisRow(false)); +BOOKS_DEDUPED.forEach(b => bookChart.appendChild(buildBar(b, 'title', false))); + +// Render events +const eventChart = document.getElementById('event-chart'); +eventChart.appendChild(buildAxisRow(true)); +EVENTS_PROCESSED.forEach(e => eventChart.appendChild(buildBar(e, 'type', true))); diff --git a/outcome/gutenberg-adaptation/styles.css b/outcome/gutenberg-adaptation/styles.css new file mode 100644 index 0000000..8310fcc --- /dev/null +++ b/outcome/gutenberg-adaptation/styles.css @@ -0,0 +1,273 @@ +@import url('https://fonts.googleapis.com/css2?family=Playfair+Display:ital,wght@0,400;0,600;0,700;1,400&family=Source+Serif+4:ital,opsz,wght@0,8..60,300;0,8..60,400;1,8..60,300&display=swap'); + +*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } + +:root { + --bg: #f7f5f1; + --ink: #1a1a1a; + --muted: #5a5650; + --rule: #d4cfc8; + --retain: #3d6b4f; + --condense: #c17f3a; + --reorder: #4a6fa5; + --omit: #a84c3a; + --merge: #8a8a8a; +} + +html { font-size: 16px; background: var(--bg); color: var(--ink); } + +body { + font-family: 'Source Serif 4', Georgia, serif; + max-width: 920px; + margin: 0 auto; + padding: 60px 32px 80px; +} + +/* ── Header ── */ +header { + border-top: 3px solid var(--ink); + border-bottom: 1px solid var(--rule); + padding: 32px 0 28px; + margin-bottom: 48px; +} + +.kicker { + font-family: 'Source Serif 4', serif; + font-size: 0.72rem; + font-weight: 300; + letter-spacing: 0.12em; + text-transform: uppercase; + color: var(--muted); + margin-bottom: 14px; +} + +h1 { + font-family: 'Playfair Display', Georgia, serif; + font-size: clamp(2.4rem, 5vw, 3.8rem); + font-weight: 700; + line-height: 1.08; + letter-spacing: -0.02em; + text-wrap: balance; + margin-bottom: 18px; +} + +.deck { + font-size: 1.05rem; + font-weight: 300; + line-height: 1.6; + color: var(--muted); + max-width: 640px; + margin-bottom: 14px; +} + +.caveat { + font-size: 0.78rem; + font-style: italic; + color: var(--muted); + border-left: 2px solid var(--rule); + padding-left: 10px; +} + +/* ── Legend ── */ +.legend { + display: flex; + flex-wrap: wrap; + gap: 16px 28px; + margin-bottom: 44px; + padding-bottom: 24px; + border-bottom: 1px solid var(--rule); +} + +.legend-item { + display: flex; + align-items: center; + gap: 7px; + font-size: 0.8rem; + color: var(--muted); +} + +.legend-swatch { + width: 12px; + height: 12px; + border-radius: 2px; + flex-shrink: 0; +} + +/* ── Section ── */ +section { margin-bottom: 56px; } + +.section-label { + font-family: 'Source Serif 4', serif; + font-size: 0.7rem; + font-weight: 300; + letter-spacing: 0.14em; + text-transform: uppercase; + color: var(--muted); + margin-bottom: 6px; +} + +h2 { + font-family: 'Playfair Display', serif; + font-size: clamp(1.3rem, 2.5vw, 1.7rem); + font-weight: 600; + line-height: 1.2; + margin-bottom: 6px; +} + +.section-deck { + font-size: 0.92rem; + color: var(--muted); + line-height: 1.55; + margin-bottom: 28px; + max-width: 600px; +} + +/* ── Chart ── */ +.chart { width: 100%; } + +.chart-row { + display: grid; + grid-template-columns: 200px 1fr; + align-items: center; + gap: 10px; + margin-bottom: 5px; +} + +.chart-row.event-row { + grid-template-columns: 140px 1fr; +} + +.chart-label { + font-size: 0.8rem; + line-height: 1.25; + color: var(--ink); + text-align: right; + padding-right: 4px; +} + +.chart-label em { + display: block; + font-style: normal; + font-size: 0.68rem; + color: var(--muted); + margin-top: 1px; +} + +.bar-track { + display: flex; + height: 18px; + border-radius: 2px; + overflow: hidden; + position: relative; +} + +.bar-segment { + height: 100%; + transition: opacity 0.15s; +} + +.bar-segment:hover { opacity: 0.8; } + +.retain-bar { background: var(--retain); } +.condense-bar { background: var(--condense); } +.reorder-bar { background: var(--reorder); } +.omit-bar { background: var(--omit); } +.merge-bar { background: var(--merge); } + +.chart-pct { + font-size: 0.72rem; + color: var(--muted); + margin-left: 7px; + white-space: nowrap; + align-self: center; +} + +.bar-row-wrap { + display: flex; + align-items: center; +} + +/* ── Annotation ── */ +.annotation { + margin: 20px 0 28px 210px; + padding: 14px 16px; + border: 1px solid rgba(61,107,79,0.25); + background: rgba(61,107,79,0.05); + font-size: 0.84rem; + line-height: 1.55; + color: var(--ink); + max-width: 580px; +} + +.annotation.omit { border-color: rgba(168,76,58,0.25); background: rgba(168,76,58,0.05); } +.annotation.dual { border-color: var(--rule); background: transparent; } + +.annotation strong { font-weight: 600; } + +/* ── Axis labels ── */ +.axis-row { + display: grid; + grid-template-columns: 200px 1fr; + gap: 10px; + margin-bottom: 6px; +} + +.axis-row.event-axis { grid-template-columns: 140px 1fr; } + +.axis-labels { + display: flex; + justify-content: space-between; + font-size: 0.66rem; + color: var(--muted); + padding: 0 2px; +} + +/* ── Tooltip ── */ +.tooltip { + position: fixed; + background: var(--ink); + color: var(--bg); + font-size: 0.75rem; + padding: 8px 12px; + border-radius: 4px; + pointer-events: none; + opacity: 0; + transition: opacity 0.1s; + z-index: 100; + max-width: 220px; + line-height: 1.5; +} + +.tooltip.visible { opacity: 1; } + +/* ── Divider ── */ +.divider { + border: none; + border-top: 1px solid var(--rule); + margin: 48px 0; +} + +/* ── Footer ── */ +footer { + border-top: 1px solid var(--rule); + padding-top: 20px; + font-size: 0.75rem; + color: var(--muted); + line-height: 1.6; +} + +footer a { color: var(--muted); } + +@media (max-width: 600px) { + body { padding: 32px 16px 60px; } + .chart-row { grid-template-columns: 130px 1fr; } + .chart-row.event-row { grid-template-columns: 100px 1fr; } + .axis-row { grid-template-columns: 130px 1fr; } + .axis-row.event-axis { grid-template-columns: 100px 1fr; } + .annotation { margin-left: 0; } +} + +@media (prefers-reduced-motion: reduce) { + .bar-segment { transition: none; } + .tooltip { transition: none; } +}