@pikaa-ai/pikaa 0.3.23 → 0.3.24

package/skills/markdown-mermaid-writing/SKILL.md

@@ -1,322 +0,0 @@
----
-name: markdown-mermaid-writing
-description: Comprehensive markdown and Mermaid diagram writing skill. Use when creating any scientific document, report, analysis, or visualization. Establishes text-based diagrams as the default documentation standard with full style guides (markdown + mermaid), 24 diagram type references, and 9 document templates.
-allowed-tools: Read Write Edit Bash
-license: Apache-2.0
-metadata:
-  version: "1.1"
-  skill-author: Clayton Young / Superior Byte Works, LLC (@borealBytes)
-  skill-source: https://github.com/SuperiorByteWorks-LLC/agent-project
-  skill-version: 1.0.0
-  skill-contributors: Clayton Young (Superior Byte Works, LLC / @borealBytes; Author and originator); K-Dense Team (K-Dense Inc.; Integration target and community feedback)
----
-
-# Markdown and Mermaid Writing
-
-## Overview
-
-This skill teaches you — and enforces a standard for — creating scientific documentation
-using **markdown with embedded Mermaid diagrams as the default and canonical format**.
-
-The core bet: a relationship expressed as a Mermaid diagram inside a `.md` file is more
-valuable than any image. It is text, so it diffs cleanly in git. It requires no build step.
-It renders natively on GitHub, GitLab, Notion, VS Code, and any markdown viewer. It uses
-fewer tokens than a prose description of the same relationship. And it can always be
-converted to a polished image later — but the text version remains the source of truth.
-
-> "The more you get your reports and files in .md in just regular text, which mermaid is
-> as well as being a simple 'script language'. This just helps with any downstream rendering
-> and especially AI generated images (using mermaid instead of just long form text to
-> describe relationships < tokens). Additionally mermaid can render along with markdown for
-> easy use almost anywhere by humans or AI."
->
-> — Clayton Young (@borealBytes), K-Dense Discord, 2026-02-19
-
-## When to Use This Skill
-
-Use this skill when:
-
-- Creating **any scientific document** — reports, analyses, manuscripts, methods sections
-- Writing **any documentation** — READMEs, how-tos, decision records, project docs
-- Producing **any diagram** — workflows, data pipelines, architectures, timelines, relationships
-- Generating **any output that will be version-controlled** — if it's going into git, it should be markdown
-- Working with **any other skill** — this skill defines the documentation layer that wraps every other output
-- Someone asks you to "add a diagram" or "visualize the relationship" — Mermaid first, always
-
-Do NOT start with Python matplotlib, seaborn, or AI image generation for structural or relational diagrams.
-Those are Phase 2 and Phase 3 — only used when Mermaid cannot express what's needed (e.g., scatter plots with real data, photorealistic images).
-
-## 🎨 The Source Format Philosophy
-
-### Why text-based diagrams win
-
-| What matters | Mermaid in Markdown | Python / AI Image |
-| ----------------------------- | :-----------------: | :---------------: |
-| Git diff readable | ✅ | ❌ binary blob |
-| Editable without regenerating | ✅ | ❌ |
-| Token efficient vs. prose | ✅ smaller | ❌ larger |
-| Renders without a build step | ✅ | ❌ needs hosting |
-| Parseable by AI without vision | ✅ | ❌ |
-| Works in GitHub / GitLab / Notion | ✅ | ⚠️ if hosted |
-| Accessible (screen readers) | ✅ accTitle/accDescr | ⚠️ needs alt text |
-| Convertible to image later | ✅ anytime | — already image |
-
-### The three-phase workflow
-
-```mermaid
-flowchart LR
-    accTitle: Three-Phase Documentation Workflow
-    accDescr: Phase 1 Mermaid in markdown is always required and is the source of truth. Phases 2 and 3 are optional downstream conversions for polished output.
-
-    p1["📄 Phase 1<br/>Mermaid in Markdown<br/>(ALWAYS — source of truth)"]
-    p2["🐍 Phase 2<br/>Python Generated<br/>(optional — data charts)"]
-    p3["🎨 Phase 3<br/>AI Generated Visuals<br/>(optional — polish)"]
-    out["📊 Final Deliverable"]
-
-    p1 --> out
-    p1 -.->|"when needed"| p2
-    p1 -.->|"when needed"| p3
-    p2 --> out
-    p3 --> out
-
-    classDef required fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
-    classDef optional fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
-    classDef output fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
-
-    class p1 required
-    class p2,p3 optional
-    class out output
-```
-
-**Phase 1 is mandatory.** Even if you proceed to Phase 2 or 3, the Mermaid source stays committed.
-
-### What Mermaid can express
-
-Mermaid covers 24 diagram types. Almost every scientific relationship fits one:
-
-| Use case | Diagram type | File |
-| -------------------------------------------- | ---------------- | ---------------------------------------------------- |
-| Experimental workflow / decision logic | Flowchart | `references/diagrams/flowchart.md` |
-| Service interactions / API calls / messaging | Sequence | `references/diagrams/sequence.md` |
-| Data model / schema | ER diagram | `references/diagrams/er.md` |
-| State machine / lifecycle | State | `references/diagrams/state.md` |
-| Project timeline / roadmap | Gantt | `references/diagrams/gantt.md` |
-| Proportions / composition | Pie | `references/diagrams/pie.md` |
-| System architecture (zoom levels) | C4 | `references/diagrams/c4.md` |
-| Concept hierarchy / brainstorm | Mindmap | `references/diagrams/mindmap.md` |
-| Chronological events / history | Timeline | `references/diagrams/timeline.md` |
-| Class hierarchy / type relationships | Class | `references/diagrams/class.md` |
-| User journey / satisfaction map | User Journey | `references/diagrams/user_journey.md` |
-| Two-axis comparison / prioritization | Quadrant | `references/diagrams/quadrant.md` |
-| Requirements traceability | Requirement | `references/diagrams/requirement.md` |
-| Flow magnitude / resource distribution | Sankey | `references/diagrams/sankey.md` |
-| Numeric trends / bar + line charts | XY Chart | `references/diagrams/xy_chart.md` |
-| Component layout / spatial arrangement | Block | `references/diagrams/block.md` |
-| Work item status / task columns | Kanban | `references/diagrams/kanban.md` |
-| Cloud infrastructure / service topology | Architecture | `references/diagrams/architecture.md` |
-| Multi-dimensional comparison / skills radar | Radar | `references/diagrams/radar.md` |
-| Hierarchical proportions / budget | Treemap | `references/diagrams/treemap.md` |
-| Binary protocol / data format | Packet | `references/diagrams/packet.md` |
-| Git branching / merge strategy | Git Graph | `references/diagrams/git_graph.md` |
-| Code-style sequence (programming syntax) | ZenUML | `references/diagrams/zenuml.md` |
-| Multi-diagram composition patterns | Complex Examples | `references/diagrams/complex_examples.md` |
-
-> 💡 **Pick the right type, not the easy one.** Don't default to flowcharts for everything.
-> A timeline beats a flowchart for chronological events. A sequence beats a flowchart for
-> service interactions. Scan the table and match.
-
----
-
-## 🔧 Core workflow
-
-### Step 1: Identify the document type
-
-Check if a template exists before writing from scratch:
-
-| Document type | Template |
-| ------------------------------ | ----------------------------------------------- |
-| Pull request record | `templates/pull_request.md` |
-| Issue / bug / feature request | `templates/issue.md` |
-| Sprint / project board | `templates/kanban.md` |
-| Architecture decision (ADR) | `templates/decision_record.md` |
-| Presentation / briefing | `templates/presentation.md` |
-| Research paper / analysis | `templates/research_paper.md` |
-| Project documentation | `templates/project_documentation.md` |
-| How-to / tutorial | `templates/how_to_guide.md` |
-| Status report | `templates/status_report.md` |
-
-### Step 2: Read the style guide
-
-Before writing any `.md` file: read `references/markdown_style_guide.md`.
-
-Key rules to internalize:
-
-- **One H1 per document** — the title. Never more.
-- **Emoji on H2 headings only** — one emoji per H2, none in H3/H4
-- **Cite everything** — every external claim gets a footnote `[^N]` with full URL
-- **Bold sparingly** — max 2-3 bold terms per paragraph, never full sentences
-- **Horizontal rule after every `</details>`** — mandatory
-- **Tables over prose** for comparisons, configurations, structured data
-- **Diagrams over walls of text** — if it describes flow, structure, or relationships, add Mermaid
-
-### Step 3: Pick the diagram type and read its guide
-
-Before creating any Mermaid diagram: read `references/mermaid_style_guide.md`.
-
-Then open the specific type file (e.g., `references/diagrams/flowchart.md`) for the exemplar, tips, and copy-paste template.
-
-Mandatory rules for every diagram:
-
-```
-accTitle: Short Name 3-8 Words
-accDescr: One or two sentences explaining what this diagram shows.
-```
-
-- **No `%%{init}` directives** — breaks GitHub dark mode
-- **No inline `style`** — use `classDef` only
-- **One emoji per node max** — at the start of the label
-- **`snake_case` node IDs** — match the label
-
-### Step 4: Write the document
-
-Start from the template. Apply the markdown style guide. Place diagrams inline with related text — not in a separate "Figures" section.
-
-### Step 5: Commit as text
-
-The `.md` file with embedded Mermaid is what gets committed. If you also generated a PNG or AI image, those are supplementary — the markdown is the source.
-
----
-
-## ⚠️ Common pitfalls
-
-### Radar chart syntax (`radar-beta`)
-
-**WRONG:**
-```mermaid
-radar
-title Example
-x-axis ["A", "B", "C"]
-"Series" : [1, 2, 3]
-```
-
-**CORRECT:**
-```mermaid
-radar-beta
-title Example
-axis a["A"], b["B"], c["C"]
-curve series["Series"]{1, 2, 3}
-max 3
-```
-
-- **Use `radar-beta`** not `radar` (the bare keyword doesn't exist)
-- **Use `axis`** to define dimensions, **not** `x-axis`
-- **Use `curve`** to define data series, **not** quoted labels with colon
-- **No `accTitle`/`accDescr`** — radar-beta doesn't support accessibility annotations; always add a descriptive italic paragraph above the diagram
-
-### XY Chart vs Radar confusion
-
-| Diagram | Keyword | Axis syntax | Data syntax |
-| ------- | ------- | ----------- | ----------- |
-| **XY Chart** (bars/lines) | `xychart-beta` | `x-axis ["Label1", "Label2"]` | `bar [10, 20]` or `line [10, 20]` |
-| **Radar** (spider/web) | `radar-beta` | `axis id["Label"]` | `curve id["Label"]{10, 20}` |
-
-### Forgetting `accTitle`/`accDescr` on supported types
-
-Only some diagram types support `accTitle`/`accDescr`. For those that don't, always place a descriptive italic paragraph directly above the code block:
-
-> _Radar chart comparing three methods across five performance dimensions. Note: Radar charts do not support accTitle/accDescr._
-
-```mermaid
-radar-beta
-...
-```
-
----
-
-## 🔗 Integration with other skills
-
-### With `scientific-schematics`
-
-`scientific-schematics` generates AI-powered publication-quality images (PNG). Use the Mermaid diagram as the **brief** for the schematic:
-
-```
-Workflow:
-1. Create the concept as Mermaid in .md (this skill — Phase 1)
-2. Describe the same concept to scientific-schematics for a polished PNG (Phase 3)
-3. Commit both — the .md as source, the PNG as a supplementary figure
-```
-
-### With `scientific-writing`
-
-When `scientific-writing` produces a manuscript, all diagrams and structural figures should use this skill's standards. The writing skill handles prose and citations; this skill handles visual structure.
-
-```
-Workflow:
-1. Use scientific-writing to draft the manuscript
-2. For every figure that shows a workflow, architecture, or relationship:
-   - Replace placeholder with a Mermaid diagram following this skill's guide
-3. Use scientific-schematics only for figures that truly need photorealistic/complex rendering
-```
-
-### With `literature-review`
-
-Literature review produces summaries with lots of relationship data. Use this skill to:
-
-- Create concept maps (Mindmap) of the literature landscape
-- Show publication timelines (Timeline or Gantt)
-- Compare methodologies (Quadrant or Radar)
-- Diagram data flows described in papers (Sequence or Flowchart)
-
-### With any skill that produces output documents
-
-Before finalizing any document from any skill, apply this skill's checklist:
-
-- [ ] Does the document use a template? If so, did I start from the right one?
-- [ ] Are all diagrams in Mermaid with `accTitle` + `accDescr`?
-- [ ] No `%%{init}`, no inline `style`, only `classDef`?
-- [ ] Are all external claims cited with `[^N]`?
-- [ ] One H1, emoji on H2 only?
-- [ ] Horizontal rules after every `</details>`?
-
----
-
-## 📚 Reference index
-
-### Style guides
-
-| Guide | Path | Lines | What it covers |
-| ----------------------- | ------------------------------------------- | ----- | -------------------------------------------------- |
-| Markdown Style Guide | `references/markdown_style_guide.md` | ~733 | Headings, formatting, citations, tables, Mermaid integration, templates, quality checklist |
-| Mermaid Style Guide | `references/mermaid_style_guide.md` | ~458 | Accessibility, emoji set, color classes, theme neutrality, type selection, complexity tiers |
-
-### Diagram type guides (24 types)
-
-Each file contains: production-quality exemplar, tips specific to that type, and a copy-paste template.
-
-`references/diagrams/` — architecture, block, c4, class, complex\_examples, er, flowchart, gantt, git\_graph, kanban, mindmap, packet, pie, quadrant, radar, requirement, sankey, sequence, state, timeline, treemap, user\_journey, xy\_chart, zenuml
-
-### Document templates (9 types)
-
-`templates/` — decision\_record, how\_to\_guide, issue, kanban, presentation, project\_documentation, pull\_request, research\_paper, status\_report
-
-### Examples
-
-`assets/examples/example-research-report.md` — a complete scientific research report demonstrating proper heading hierarchy, multiple diagram types (flowchart, sequence, gantt), tables, footnote citations, collapsible sections, and all style guide rules applied.
-
----
-
-## 📝 Attribution
-
-All style guides, diagram type guides, and document templates in this skill are ported from the `SuperiorByteWorks-LLC/agent-project` repository under the Apache-2.0 License.
-
-- **Source**: https://github.com/SuperiorByteWorks-LLC/agent-project
-- **Author**: Clayton Young / Superior Byte Works, LLC (@borealBytes)
-- **License**: Apache-2.0
-
-This skill (as part of scientific-agent-skills) is distributed under the MIT License. The included Apache-2.0 content is compatible for downstream use with attribution retained, as preserved in the file headers throughout this skill.
-
----
-
-[^1]: GitHub Blog. (2022). "Include diagrams in your Markdown files with Mermaid." https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/
-
-[^2]: Mermaid. "Mermaid Diagramming and Charting Tool." https://mermaid.js.org/

package/skills/market-research-reports/SKILL.md

@@ -1,337 +0,0 @@
----
-name: market-research-reports
-description: Build evidence-traceable market research reports and assumption-driven market sizing or forecast scenarios. Use for market definition, industry and customer evidence, competitive landscapes, TAM/SAM/SOM reconciliation, forecast sensitivity, and auditable report scaffolds.
-license: MIT
-compatibility: Python 3.11+ standard library for optional offline CLIs. The optional LaTeX template uses XeLaTeX or LuaLaTeX. Online research requires user-approved network access and source-specific terms; bundled scripts make no network, LLM, or image calls.
-metadata:
-  version: "1.2"
-  skill-author: "K-Dense Inc."
----
-
-# Market Research Reports
-
-## Purpose
-
-Create decision-focused market reports whose claims, calculations, assumptions,
-and uncertainties can be audited. Match depth and format to the question and
-evidence. There is no required length, chapter count, visual count, or output
-format.
-
-Do not:
-
-- imitate or imply affiliation with a consulting, analyst, or research brand;
-- invent citations, quotes, market shares, or paid-market figures;
-- present TAM/SAM/SOM or a forecast as one certain truth;
-- treat a framework, chart, or fluent narrative as evidence;
-- provide investment, legal, antitrust, tax, accounting, or regulatory advice.
-
-## Operating principles
-
-1. **Define before sizing.** Fix product, customer, geography, channel, period,
-   measure, unit, denominator, currency/base year, and taxonomy.
-2. **Map every claim.** Every factual or quantitative claim has a claim ID and
-   exact source IDs.
-3. **Separate statement types.** Distinguish facts, estimates, calculations,
-   forecasts, opinions, and recommendations.
-4. **Prefer primary evidence.** Use official statistics, regulator records,
-   filed company disclosures, and transparent original studies before
-   secondary synthesis.
-5. **Preserve uncertainty.** Retain source conflicts, revisions, scenario
-   ranges, sensitivity, and limitations.
-6. **Keep methods reproducible.** Use local structured inputs and deterministic
-   calculations when practical.
-7. **Collect lawfully and ethically.** No deception, PII disclosure, access
-   circumvention, confidential material, or trade-secret acquisition.
-
-## Workflow
-
-### 1. Establish the research contract
-
-Clarify:
-
-- decision, audience, deadline, and materiality threshold;
-- formal market definition and adjacent exclusions;
-- buyer, payer, user, transaction, and value-chain level;
-- geography and treatment of imports, exports, and channels;
-- historical period, forecast period, and retrieval cutoff;
-- revenue/expenditure, gross output/value added, units, capacity, users, or
-  another measure;
-- stock/flow, gross/net, taxes, and denominator;
-- currency, base year, and nominal/real/current/constant basis;
-- industry and product classification with version;
-- permitted data sources, primary research, confidentiality, and output format.
-
-Ask a focused question when a missing choice would materially change the
-denominator or result. Otherwise state a provisional scope and proceed.
-
-Use `references/report_structure_guide.md` for modular report design.
-
-### 2. Build the evidence plan
-
-Route each question to the source closest to the underlying event:
-
-1. primary law, regulator decision, official filing, or official statistic;
-2. original company filing or attributable first-party disclosure;
-3. transparent survey/study with inspectable methods;
-4. institutional or peer-reviewed research using identifiable primary data;
-5. industry association data with disclosed coverage;
-6. reputable secondary synthesis;
-7. lawfully accessed paid estimate with inspectable scope and method;
-8. news/commentary for leads or attributable events.
-
-For company data, prefer the official filing system in the relevant
-jurisdiction. For industry, labor, prices, population, trade, and national
-accounts, prefer the responsible national statistical agency or central bank.
-For cross-country work, use harmonized World Bank, IMF, OECD, or Eurostat data
-only after checking definitions and original-source lineage.
-
-Read `references/official_data_sources.md` before using public APIs. API rules
-and limits are a dated snapshot: verify current official terms before automated
-or high-volume retrieval. Never put an API key in a report or bundled script.
-
-### 3. Create the source ledger
-
-Assign stable IDs (`S-001`, `S-002`, ...). Record:
-
-- title, publisher, URL/persistent ID, source type;
-- publication date and retrieval date;
-- original producer when accessed through an aggregator;
-- geography, covered population, period, and vintage;
-- currency, base year, price basis, measure type, unit, and denominator;
-- taxonomy and version;
-- preliminary/revised/final/current status;
-- method, sample, imputation, suppression, and limitations;
-- license/terms and lawful local snapshot path.
-
-Use `assets/source_ledger_template.csv` and validate it:
-
-```bash
-python3 scripts/validate_evidence_ledger.py data/source_ledger.csv
-```
-
-If publication date is unavailable, record `not-stated`; do not guess.
-
-### 4. Maintain a claims ledger
-
-Assign IDs (`C-001`, ...). Keep the exact claim text, statement type, source
-IDs, report location, as-of date, geography, currency/base, measure/unit,
-taxonomy, revision status, confidence, calculation ID, and assumption IDs.
-
-Rules:
-
-- one end-of-paragraph citation does not support unrelated sentences;
-- split compound claims that rely on different evidence;
-- a calculation cites its inputs, not a source that never published the result;
-- an aggregator and its original source are not independent corroboration;
-- an interview theme is not population prevalence;
-- absence of public feature evidence means `unknown`, not `no`.
-
-Audit mappings:
-
-```bash
-python3 scripts/audit_claim_citations.py \
-  data/claims.csv data/source_ledger.csv
-```
-
-See `references/evidence_model.md`.
-
-### 5. Size the market as scenarios
-
-#### Measurement guardrails
-
-Give every component a disjoint `coverage_key` and one shared
-`denominator_id`. Do not add:
-
-- manufacturer revenue to distributor or end-customer spend;
-- production, imports, and sales without trade/inventory reconciliation;
-- parent and subsidiary revenue;
-- bundles and their included components;
-- gross output and value added;
-- installed-base stock and annual transaction flow;
-- overlapping customer or geographic segments.
-
-Use product classifications and supply-use logic when industry codes are too
-broad. Preserve an unknown/residual category instead of forcing totals.
-
-#### Top-down and bottom-up
-
-Compute independently:
-
-```text
-TAM_top = sum(disjoint in-scope component values)
-
-TAM_bottom =
-  sum(customer_count
-      * addressable_fraction
-      * annual_quantity_per_customer
-      * price_per_unit)
-```
-
-Then apply scenario-specific serviceability and capture assumptions:
-
-```text
-SAM_s = TAM * serviceable_fraction_s
-SOM_s = SAM_s * obtainable_share_s
-```
-
-Use at least two genuinely different scenarios; a downside/base/upside set is
-usually useful. State horizon, constraints, evidence, and assumptions. SOM is
-not a guaranteed revenue forecast.
-
-Run the deterministic calculator:
-
-```bash
-python3 scripts/calculate_market_sizing.py \
-  assets/market_sizing_scenarios_template.json
-```
-
-Report both methods, midpoint-relative gap, scope differences, sensitivity, and
-unresolved reconciliation. Do not average incompatible methods.
-
-### 6. Forecast with explicit uncertainty
-
-Separate observed, estimated, and forecast periods. Record series ID,
-frequency, units, seasonal adjustment, transformations, taxonomy breaks,
-retrieval date, and vintage/revisions.
-
-For each scenario:
-
-- provide an annual rate path or driver equations;
-- state demand, price, supply, regulation, competition, capacity, and timing
-  assumptions;
-- list evidence and assumption IDs;
-- identify conditions that invalidate the scenario.
-
-Do not call scenario bounds confidence or prediction intervals. Do not assign
-probabilities without a validated probabilistic model and diagnostics.
-
-Run:
-
-```bash
-python3 scripts/forecast_sensitivity.py \
-  assets/forecast_sensitivity_template.json
-```
-
-Show the range by year, endpoint sensitivity, influential assumptions, and
-switching values. See `references/data_analysis_patterns.md`.
-
-### 7. Analyze customers and primary research
-
-For survey evidence, disclose sponsor, target population, frame,
-probability/non-probability design, recruitment, mode/language, field dates,
-unweighted sample, subgroup bases, weighting, response/participation,
-instrument wording, precision, processing, and limitations.
-
-For interviews/focus groups, disclose recruitment, consent, role coverage,
-dates/mode, guide, coding, divergent evidence, privacy controls, and limits to
-generalization.
-
-Never:
-
-- collect more personal data than necessary;
-- place direct identifiers or raw recordings in report artifacts;
-- use research as disguised selling or lead generation;
-- misrepresent identity/purpose;
-- pressure participants to reveal employer/customer secrets;
-- report qualitative mention counts as market prevalence.
-
-Follow `references/methods_and_ethics.md`.
-
-### 8. Analyze competitors and concentration
-
-Define product and geographic scope from the customer perspective before
-selecting competitors or calculating shares. Consider non-price dimensions,
-channels, imports, digital/multi-sided features, innovation, and dynamic change
-where relevant.
-
-Use lawful public evidence and a common product edition, geography, and as-of
-date. Validate a complete matrix:
-
-```bash
-python3 scripts/validate_competitor_matrix.py \
-  assets/competitor_feature_matrix_template.csv \
-  --source-ledger assets/source_ledger_template.csv
-```
-
-For shares, state revenue/units/capacity/users or other metric, denominator,
-period, residual share, and source coverage. HHI/CRn are descriptive screens,
-not legal conclusions. A TAM category is not automatically a relevant antitrust
-market.
-
-### 9. Normalize units and definitions
-
-Before combining values:
-
-- align geography, period, stock/flow, gross/net, unit, and denominator;
-- convert currencies with an identified source and rate convention;
-- align base year and nominal/real basis;
-- do not force chained-dollar additivity;
-- preserve taxonomy versions and document concordance uncertainty;
-- record every conversion as a calculation.
-
-Check comparison groups:
-
-```bash
-python3 scripts/check_unit_consistency.py \
-  assets/consistency_check_template.csv
-```
-
-### 10. Draft and review
-
-Lead with findings and uncertainty, not frameworks. Use optional frameworks
-only to organize questions; do not force scores or a fixed number of factors.
-Keep recommendations separate from evidence and include dependencies,
-trade-offs, decision thresholds, and disconfirming evidence.
-
-Visuals are optional. If used, build them from validated local data and include
-scope, units, source IDs, calculation ID, observed/forecast distinction, and
-limitations. See `references/visual_generation_guide.md`.
-
-Generate a Markdown workspace:
-
-```bash
-python3 scripts/generate_report_scaffold.py \
-  assets/report_manifest_template.json ./market-report-workspace
-```
-
-Or use the optional LaTeX assets:
-
-- `assets/market_report_template.tex`
-- `assets/market_research.sty`
-- `assets/FORMATTING_GUIDE.md`
-
-## Release gate
-
-- Market boundary, taxonomy, denominator, geography, and period are explicit.
-- Every factual/quantitative claim maps to exact source IDs.
-- Publication/retrieval dates, revisions, method, and limitations are recorded.
-- Currency/base year, nominal/real basis, stock/flow, and units are consistent.
-- Top-down and bottom-up methods use disjoint coverage and are reconciled.
-- TAM/SAM/SOM and forecasts are conditional scenarios with sensitivity.
-- Survey/interview evidence carries method, privacy, and inference limits.
-- Competitor evidence is lawful, dated, scoped, and uses `unknown` honestly.
-- Source conflicts and revisions remain visible.
-- No fabricated/unsupported paid figures, PII, trade secrets, deceptive
-  collection, brand impersonation, or investment-advice framing appears.
-
-## Bundled resources
-
-### References
-
-- `references/report_structure_guide.md` — modular report architecture.
-- `references/evidence_model.md` — claim-source mapping and provenance.
-- `references/data_analysis_patterns.md` — sizing, forecast, consistency,
-  survey, and concentration methods.
-- `references/official_data_sources.md` — current official source/API routing.
-- `references/methods_and_ethics.md` — survey, interview, privacy, competitor,
-  and antitrust safeguards.
-- `references/visual_generation_guide.md` — optional evidence-led displays.
-- `references/sources.md` — dated authoritative source ledger.
-
-### Templates and CLIs
-
-Use the templates in `assets/` as synthetic schemas, not real-world evidence.
-All scripts in `scripts/` are standard-library, bounded, local-only tools. They
-reject oversized or malformed input, do not follow symlink inputs, do not
-overwrite outputs without explicit permission, and make no network, LLM, image,
-dynamic-evaluation, or pickle calls.