renewable-market-research

name

renewable-market-research

description

Workflow skill for evidence-based renewable energy market research, V4 full country wind-market status reports, source-to-final continuity, project pipeline verification, deduplication, product-fit analysis, factual procurement-window mapping, and executive briefing compression. Use for overseas wind, solar, storage, hydrogen, grid, or clean-energy market research where evidence quality, source traceability, omission control, uncertainty control, and decision usefulness matter more than long reports.

Renewable Market Research

Goal

Research any country + any renewable/new-energy technology as an evidence-driven market intelligence workflow for market judgment, project pipeline verification, product-fit analysis, factual procurement-window mapping, and executive reporting. Preserve reusable market data plus traditional report deliverables:

1. Full report: V4 country wind-market status master report with scope/evidence rules, capacity segmentation, full project ledger, key project cards, participant/decision-chain mapping, OEM/EPC/finance/O&M/localization/grid/tariff/risk facts, and source-confidence appendix. It is not a strategy recommendation memo.
2. Lite report: shorter delivery version with polished structure, project pipeline essentials, and reduced deep/proprietary analysis.
3. Executive or action brief: optional separate output when the user asks for strategy, sales actions, or management recommendations.

Use an effective-harnesses mindset: persist state to files, make progress resumable, validate outputs, and avoid returning large raw search payloads through chat.

Operating Principle

Wind first, recall first, ledger strict, full report descriptive.

For wind-market tasks, treat the report as a national wind market study, not a broad energy overview. The core line is project pipeline, market participants, OEM/EPC competition, policy/PPA/tariff context, procurement-window facts, and evidence boundaries. Keep recommendations outside the full report unless the user asks for a separate executive or action brief.

Run research in two modes. First, run high-recall discovery with dynamic frontier expansion: search entry names must not be assumed complete at initialization. Start from fixed seed templates, historical baseline entries, and authority-source categories; then extract every discovered project, developer, SPV, OEM, EPC, lender, law/decree, offtaker, grid entity, region, authority source, and adjacent-opportunity signal into search_frontier.json. Search the newly discovered entries in later rounds. Do not reject early-stage items during recall. Any candidate with a project name plus at least one signal such as capacity, actor, location, agreement, decree, news, financing, OEM/EPC link, or grid/PPA clue must enter candidate_project_pool.json.

Bound high recall with frontier priority, not with early deletion. Treat P0 as wind project/commercial core, P1 as wind policy/grid/revenue context, P2 as one-hop market enablers, P3 as adjacent topics that expand only with explicit wind impact, and P4 as deferred macro background. P0/P1 entries drive convergence; P2/P3/P4 entries are preserved but must not create infinite search drift unless promoted by wind-linked evidence.

Harden P0/P1 with role-separated execution and evaluation. Every P0/P1 frontier entry must receive an executor role, a different evaluator role, an execution artifact, an evaluation artifact, and an evaluation status before ledger admission. P2/P3/P4 entries do not need this hard gate unless promoted to P0/P1. Role separation does not require two real processes when unavailable; a single session may run separate executor and evaluator passes, but must write separate artifacts.

Second, run verification and reconciliation: merge duplicates, classify every candidate as operational, financing_closed, under_construction, ppa_signed, decree_backed, mou_or_early_stage, watchlist, duplicate, rejected, or unresolved, backtrace policies and tariffs, verify source traces, and calculate all capacity totals from {slug}-pipeline-ledger.json. Search should be broad; ledger admission should be strict. Final reports must be generated from the reconciled ledger and rich master JSON, not from raw notes.

Adjacent topics such as storage, solar PV, grid, green hydrogen, ammonia, methanol, I-REC, CBAM, and industrial green-power demand may enter the main report only when they change wind project value, PPA/tariff economics, interconnection, procurement route, OEM opportunity, or sales entry point. Otherwise keep them as appendix/gap notes.

Required Reading

Load only the reference needed for the current step:

• references/file-mode-research.md: parallel/file-mode collection workflow, tool priority, convergence rules, and child-agent prompt template.
• references/data-model.md: directory layout, index.json, main JSON schema, canonical project ledger, depth JSON schema, and CSV columns.
• workflow.md: Lite, Standard, and Deep workflow modes for decision-oriented market intelligence.
• agent_roles.md: writer, reviewer, synthesis, and executive role separation.
• review_gates.md: Evidence, Contradiction, Business, and Executive gates that final claims must pass.
• schema/*.schema.json: machine-readable schemas for evidence, findings, projects, decisions, reviews, and reports.
• prompts/*.md: role-specific prompts for orchestrator, policy, pipeline, owner, product-fit, grid, finance, competitor, verification, skeptic/reflection, synthesis, and executive agents.
• references/full-report-v4.md: required V4 full-report architecture, chapter contract, project-ledger fields, project-card fields, and full-report writer flow.
• references/pdf-pipeline.md: full/lite report structure, Markdown/HTML/PDF pipeline, Chinese/English font handling, table alignment, and output risks.
• references/windows-native.md: Windows native PowerShell/Python startup commands, CSV export wrapper, PDF caveats, and Chrome MCP browser rules.
• references/search-orchestration.md: intent-aware query planning, search-lane coverage gates, local-language/china-capital/anomaly passes, validation script usage, and evidence-ranking guidance.

Workflow Modes

Choose the mode in workflow.md before collecting data:

• Lite Workflow: quick market checks using policy, pipeline, product-fit, skeptic, synthesis, and executive agents. Output a one-page market judgment, confirmed leads, risks, and next actions.
• Standard Workflow: country-level reports using policy, pipeline, owner, grid, product-fit, finance, competitor, skeptic, synthesis, and executive agents. Output lite report, V4 full report, project ledger/cards, procurement-window and decision-chain tables, and an executive brief or action memo only when requested.
• Heavy Workflow: default for V4 full country wind-market reports. Use the v4-heavy-chapter-agent profile: at least 15 logical agents and a target topology of 20 roles covering chapter workers, one independent verification agent, and one independent reflection/reviewer. Output all Standard deliverables plus source-audit, chapter-verification, reflection-review, and gap-task artifacts. If fewer real agents are available, collapse lanes sequentially but keep the same roles, files, gates, and review loops.
• Deep Workflow: strategic questions requiring multiple review loops, scenario comparison, assumptions register, evidence archive, and human review gates.

Standard Workflow

1. Normalize task

   • Extract country, technology, language, report depth, and target audience.
   • Identify official/local languages plus English before search. If unknown, add an early query to identify official language names and scripts.
   • Collect known project aliases, translated names, local names, developer names, and Chinese company names as seed terms for later anomaly and deduplication passes.
   • Slugify to {country_slug}-{technology_slug} such as uzbekistan-wind.
   • Create data/renewable-market/ and data/renewable-market/depth/ if missing.
   • For long-form research, generate a search plan with scripts/search_orchestration.py plan before assigning workers.

2. Resume or initialize harness state

   • Read data/renewable-market/index.json if present.
   • If {country_slug}-{technology_slug}.json exists, run an incremental update; otherwise run first-time collection.
   • Optionally add/maintain feature_list.json entries for: collection, aggregation, full report, lite report, PDF rendering.

3. Split research dimensions Use focused dimensions depending on scope. For OEM/commercial-entry asks (for example Mingyang), use demand-first framing: start from electricity demand gap and monetizable offtake, then validate resource/technology constraints.

   • demand-load-gap (generation, consumption, peak load, imports/exports, 5-10 year outlook)
   • market-key-indicators-timeseries (generation YoY, latest Q/month data, wind/solar 3-year trend, installed capacity, imports/exports, pipeline MW)
   • power-mix-replacement (retirements, thermal constraints, hydro flexibility, wind/solar complementarity)
   • grid-storage-transmission (curtailment risk, substations/lines, storage requirement, cross-border corridors)
   • policy-ppa-economics (auction/FIT/PPA, tariff history, FX risk, localization, IRR/ROE if estimable)
   • auction-tariff-comparison (project-level winning tariffs, PPA tenor, currency/indexation, sponsor, capacity, source confidence)
   • project-pipeline-layered (operational, under-construction, awarded/PPA, MOU, early stage)
   • owners-partners-routes (state entities, IPPs, EPC/developer networks, contact pathways)
   • anchor-developer-deep-dives (material developers such as ACWA/Masdar/state entities: financials, full local portfolio, key people, partners, IRR assumptions when supportable)

Default Output Paths

For {slug}=uzbekistan-wind:

data/renewable-market/
├── index.json
├── uzbekistan-wind.json
├── uzbekistan-wind.csv
├── depth/
│   ├── project-pipeline.json
│   ├── ifi-financing.json
│   ├── technology-epc.json
│   └── carbon-hydrogen.json
├── uzbekistan-wind-report.md
├── uzbekistan-wind-lite.md
├── uzbekistan-wind-report.pdf
└── uzbekistan-wind-lite.pdf

Also produce:

• data/renewable-market/{slug}-pipeline-ledger.json
• data/renewable-market/{slug}-seed_entities.json
• data/renewable-market/{slug}-search_frontier.json
• data/renewable-market/{slug}-discovered_entries.json
• data/renewable-market/{slug}-authority_sources.json
• data/renewable-market/{slug}-candidate_project_pool.json
• data/renewable-market/{slug}-developer_project_map.json
• data/renewable-market/{slug}-source_trace.json
• data/renewable-market/{slug}-frontier_execution_review.json
• data/renewable-market/{slug}-project_ledger.json
• data/renewable-market/{slug}-project_cards.json
• data/renewable-market/{slug}-participant_ledger.json
• data/renewable-market/{slug}-oem_competition.json
• data/renewable-market/{slug}-procurement_window.json
• data/renewable-market/{slug}-evidence_table.json
• data/renewable-market/{slug}-risk_matrix.json
• data/renewable-market/{slug}-tracking_watchlist.json
• data/renewable-market/{slug}-v4_agent_plan.json
• data/renewable-market/report_chapters/{slug}-chapter-*.md
• data/renewable-market/chapter_verification/{slug}-chapter-*-verification.json
• data/renewable-market/{slug}-search_coverage_matrix.md
• data/renewable-market/{slug}-frontier_convergence.json
• data/renewable-market/{slug}-capacity_reconciliation.md
• data/renewable-market/{slug}-contradiction_queue.json
• data/renewable-market/{slug}-integrity.json
• data/renewable-market/{slug}-source-audit.json in Heavy Workflow
• data/renewable-market/chapter_verification/ artifacts for critical V4 chapters in Heavy Workflow
• data/renewable-market/{slug}-reflection-review.json in Heavy Workflow
• data/renewable-market/{slug}-gap-tasks.json in Heavy Workflow when gaps remain

Review Gates

Before final writing, apply review_gates.md:

1. Continuity Gate: every final summary claim must trace back to the latest canonical ledger or reviewed synthesis, and stale summaries must be rewritten after downstream chapter updates.
2. Evidence Gate: unsupported claims and weak single-source claims cannot become high-confidence final claims; every final conclusion must pass this gate.
3. Critical Field Gate: confirmed-pipeline critical fields must have chrome-mcp, exa-fetch, or manual-file verification. Otherwise downgrade the project/field to watchlist or uncertainty; do not leave it as a final confirmed fact.
4. Contradiction Gate: reconcile installed/planned/pipeline capacity, status conflicts, COD conflicts, duplicates, translated names, local-language aliases, phase confusion, and offshore/floating/onshore classification; every final conclusion must pass this gate before synthesis.
5. Business Gate: convert important facts into report implications such as capacity treatment, procurement window, product-fit relevance, risk judgment, pending verification, or executive decision context.
6. Reflection Gate: require the independent reviewer to score each stage, list critical blockers, and generate gap tasks. Do not advance a stage merely because its score improved; it must meet the stage threshold and have zero critical blockers.
7. Executive Gate: compress final output into three evidence-backed core judgments and avoid vague potential claims unless quantified and qualified.

Quality Gates

Run these checks when files are produced. Use the host's Python launcher (python3 on Unix-like systems, py -3 on Windows):

python -m json.tool data/renewable-market/index.json > <temp>/renewable-index.validated.json
python -m json.tool data/renewable-market/{slug}.json > <temp>/renewable-main.validated.json
python -m json.tool data/renewable-market/{slug}-project_ledger.json > <temp>/renewable-project-ledger.validated.json
python -m json.tool data/renewable-market/{slug}-project_cards.json > <temp>/renewable-project-cards.validated.json
python -m json.tool data/renewable-market/{slug}-evidence_table.json > <temp>/renewable-evidence-table.validated.json
python skills/renewable-market-research/scripts/export_projects_csv.py data/renewable-market/{slug}.json data/renewable-market/{slug}.csv
python skills/renewable-market-research/scripts/validate_market_integrity.py data/renewable-market/{slug}.json --depth-dir data/renewable-market/depth --candidate-pool data/renewable-market/{slug}-candidate_project_pool.json --project-ledger data/renewable-market/{slug}-project_ledger.json --project-cards data/renewable-market/{slug}-project_cards.json --evidence-table data/renewable-market/{slug}-evidence_table.json --full-report data/renewable-market/{slug}-report.md --output data/renewable-market/{slug}-integrity.json

On Windows native, use the PowerShell commands in references/windows-native.md. Mark unavailable checks as skipped only with an explicit environment reason.

Windows Native Quick Commands

When running on Windows native, read references/windows-native.md and use PowerShell/Python commands such as:

New-Item -ItemType Directory -Force data/renewable-market/depth | Out-Null
py -3 -m json.tool data/renewable-market/index.json > $env:TEMP\renewable-index.validated.json
.\skills\renewable-market-research\scripts\export_projects_csv.ps1 -InputJson .\data\renewable-market\{slug}.json -OutputCsv .\data\renewable-market\{slug}.csv
.\skills\renewable-market-research\scripts\validate_market_integrity.ps1 -MarketJson .\data\renewable-market\{slug}.json -DepthDir .\data\renewable-market\depth -CandidatePool .\data\renewable-market\{slug}-candidate_project_pool.json -ProjectLedger .\data\renewable-market\{slug}-project_ledger.json -ProjectCards .\data\renewable-market\{slug}-project_cards.json -EvidenceTable .\data\renewable-market\{slug}-evidence_table.json -FullReport .\data\renewable-market\{slug}-report.md -Output .\data\renewable-market\{slug}-integrity.json

Do not require WSL, Git Bash, make.sh, or Bash-only syntax for the standard workflow.

Multi-Agent Harness Rules

When running long-form market research, use a harness-based multi-agent file workflow.

Default long-form profile is Heavy Workflow. Use Lite or Standard only when the user asks for speed or a smaller deliverable.

Required Skills (when available)

1. effective-harnesses
   • Manage feature decomposition, task status, recovery points, and validation state.
   • Maintain feature_list.json and agent-progress.md.
2. renewable-market-research
   • Run market research file mode.
   • Produce depth JSON files, master JSON, CSV, project timeline CSV, full report, lite report, and PDFs.
3. company-research
   • Support owner/developer/competitor/EPC/logistics/crane/financing/partner analysis.

Agent Roles and File Ownership

Main agent responsibilities:

• initialize harness and schemas
• create/update build scripts
• assign worker modules
• normalize worker outputs
• merge depth files
• build and maintain the canonical project pipeline ledger
• produce master JSON, CSV, timeline CSV, markdown reports, and PDFs
• rerun summary/conclusion backpropagation after downstream section updates
• run validations and final business judgment

Heavy Workflow uses the V4 chapter-agent profile for full reports: at least 15 logical agents, with a target topology of 20 roles. Workers may be real child agents when the host supports that pattern, or sequential lanes when it does not. The final aggregation, canonical ledger, synthesis integration, executive summary refresh, and final report assembly remain single-owner tasks under the main agent. Critical chapters require a separate verification artifact before release.

Worker agent responsibilities:

• only the assigned research module
• only the assigned data/renewable-market/depth/*.json files
• only evidence-backed findings

Worker agents MUST NOT:

• edit master JSON
• edit final Markdown reports
• edit PDF outputs
• edit build scripts
• edit harness files
• edit other workers' depth files

Required Evidence and Facts Schema

Every key fact must include:

• statement
• sources[] with url, title, publisher, accessedAt, sourceLanguage, collectionMethod
• confidence
• uncertainty

Facts schema:

{
  "topic": "...",
  "facts": [
    {
      "statement": "...",
      "sources": [],
      "confidence": "high | medium | low",
      "uncertainty": "..."
    }
  ]
}

Project pipeline timeline schema:

{
  "project": "...",
  "stage": "...",
  "auctionDate": "...",
  "ppaDate": "...",
  "fidDate": "...",
  "constructionStart": "...",
  "codOrTargetCod": "...",
  "timingConfidence": "...",
  "timingUncertainty": "..."
}

Required Outputs (Kazakhstan wind example)

• data/renewable-market/index.json
• data/renewable-market/kazakhstan-wind.json
• data/renewable-market/kazakhstan-wind.csv
• data/renewable-market/kazakhstan-wind-pipeline-ledger.json
• data/renewable-market/kazakhstan-wind-integrity.json
• data/renewable-market/kazakhstan-wind-project-timeline.csv
• data/renewable-market/kazakhstan-wind-report.md
• data/renewable-market/kazakhstan-wind-lite.md
• data/renewable-market/kazakhstan-wind-report.pdf
• data/renewable-market/kazakhstan-wind-lite.pdf

Main-Agent Normalization Layer

Main agent should implement/maintain:

• normalize_sources
• normalize_facts
• humanize_value
• dedupe_projects
• merge_project_aliases
• build_pipeline_ledger
• policy_legal_backtrace
• refresh_summary_from_latest_ledger
• project_timeline_records
• validate_depth_files
• build_search_plan
• validate_search_coverage
• validate_market_integrity

Report Quality Gates

• Markdown/CSV/PDF must be human-readable outputs, not raw JSON object dumps.
• Standard and Deep full reports must follow the V4 0-16 chapter structure in references/full-report-v4.md; a 6-section compressed structure is acceptable only for Lite mode.
• Report-body project pipeline must be rendered as project cards grouped by status/evidence stage, not as a large table.
• Regional benchmark sections are omitted by default and included only when the user explicitly requests a benchmark.
• Do not render raw structures such as {\"claim\": ...} or {\"sources\": ...} directly in reports.
• Keep structured evidence in JSON/depth files only.
• Missing values must be unavailable or not found.
• Any inference must be marked as assumption.
• Never fabricate sources.

Acceptance Commands

Use commands like:

uv run python scripts/build_kazakhstan_wind_outputs.py
uv run python -m json.tool data/renewable-market/index.json
uv run python -m json.tool data/renewable-market/kazakhstan-wind.json
uv run python skills/renewable-market-research/scripts/search_orchestration.py validate --plan data/renewable-market/kazakhstan-wind-search-plan.json --depth-dir data/renewable-market/depth --output data/renewable-market/kazakhstan-wind-search-coverage.json
uv run python skills/renewable-market-research/scripts/validate_market_integrity.py data/renewable-market/kazakhstan-wind.json --depth-dir data/renewable-market/depth --output data/renewable-market/kazakhstan-wind-integrity.json

And verify:

• all depth JSON files parse
• master JSON parses
• rich project-card fields found in depth files are propagated into the master JSON or explicitly marked unavailable
• CSV opens
• canonical pipeline ledger exists and duplicate candidates are resolved or explicitly watchlisted/rejected
• project timeline CSV exists
• full and lite Markdown reports exist
• PDFs exist when PDF toolchain is available
• executive summary was refreshed after the latest project ledger and synthesis updates
• reports do not contain raw JSON object artifacts