Pdd Generator

PDD Generator

Generates a Project Design Document (PDD) for a carbon credit project, structured to the conventions of the major voluntary registries (Verra VCS, Gold Standard, ACR, CAR) and sized for whichever one applies.

A PDD is the foundational document in carbon markets. Every other document in this skills pack (legal agreements, monitoring plan, timeline, decision memos) either feeds into the PDD or gets generated from decisions made in it. Treat the PDD as the source of truth for project facts; don't let other skills introduce inconsistent numbers.

Before drafting

Ask (or infer from context if already provided):

1. Registry — Verra VCS, Gold Standard, ACR, or CAR. Each has a different template skeleton and different terminology (e.g. Verra calls it a "PD," Gold Standard a "PDD"). Default to Verra VCS structure if unspecified since it's the most widely used, but flag the assumption.
2. Project category — removal (e.g. biochar, afforestation, soil carbon, DAC, enhanced weathering) vs. avoidance/reduction (e.g. REDD+, improved forest management, methane capture).
3. Methodology — named methodology if already selected (e.g. VM0042 for improved agricultural land management, VM0044 for biochar). If not selected, this skill should help narrow it down based on project type and geography — load references/methodology-selection.md.
4. Crediting period — fixed or renewable, and the proposed start date.
5. Monitoring approach — remote sensing only, in-situ instrumentation, hybrid. This determines how rigorous Section on Monitoring needs to be and whether it should reference hardware-verified dMRV language (relevant for Mālama-style projects).

Don't ask all five up front if the user has clearly already given most of it in conversation. Fill gaps with explicit assumptions stated inline, not silent defaults.

PDD structure (registry-agnostic core, maps to all four)

1. Project Description — title, proponent, location, sector, scale (micro/small/large), start date, crediting period, estimated GHG benefit.
2. Application of Methodology — methodology ID and version, applicability conditions checked against the project, deviations if any.
3. Project Boundary — geographic boundary, GHG sources/sinks/reservoirs included and excluded, with rationale for exclusions.
4. Baseline Scenario — the counterfactual: what would have happened without the project. This is the section most likely to get challenged in validation, so it needs explicit reasoning, not assertion.
5. Additionality — regulatory surplus test, common practice analysis, barrier analysis (financial, technological, institutional) or investment analysis. Pick the test the methodology mandates, don't freelance.
6. Quantification of GHG Emission Reductions/Removals — formulas, default values vs. project-specific values, leakage accounting.
7. Monitoring Plan — parameters monitored, frequency, QA/QC procedures, data management, and (where applicable) the instrumentation/sensor architecture. This is where cryptographically-attested or hardware-verified measurement architecture gets documented if the project uses it.
8. Environmental and Social Safeguards / SDG Contributions — registry-specific (Gold Standard weights this heavily; Verra has a lighter-touch version via CCB if co-certified).
9. Stakeholder Consultation — summary of engagement, route to carbon-stakeholder-governance skill for the underlying consent documentation.
10. Risk Assessment / Non-Permanence (removals only) — buffer pool contribution, reversal risk rating.

For the exact section numbering and required appendices per registry, load references/registry-templates.md before finalizing structure — the section order and naming differ enough between Verra and Gold Standard that getting this wrong creates real rework for the user.

Drafting principles

• Write defensibly, not persuasively. A PDD is reviewed by a validation/verification body (VVB) looking for gaps to challenge. Every claim needs either a citation to the methodology, a data source, or an explicit assumption flagged as such. Don't write marketing language into a PDD — it will get flagged in review.
• Numbers over adjectives. "Significant carbon sequestration" is not defensible. "Estimated 4,200 tCO2e/year based on VM0044 default emission factors for biochar application at X t/ha" is.
• Match measurement claims to actual rigor. If the project uses estimation-tier methods, say so plainly (don't imply in-situ measurement). If it uses hardware-verified in-situ MRV, the monitoring section should be the strongest part of the document, not boilerplate — this is the "measured, not estimated" differentiator and validators increasingly reward documented rigor over assumed defaults.
• Flag every place a number is still TBD. Don't fabricate baseline data, soil carbon stocks, or default values that need a field study or lab result. Mark them clearly as [PENDING: source] so the user knows what's still open before submission.

Output format

Draft as a structured markdown or docx file (use the docx skill if the user wants a Word deliverable, since registries generally expect Word or PDF submissions). Use the registry's actual section headers, not generic ones, so the user can drop it straight into review.

Related skills in this pack

• mrv-methodology-drafting — for the underlying measurement methodology language that feeds Section 7.
• carbon-decision-memos — for documenting the registry/methodology selection decision before locking the PDD structure.
• carbon-stakeholder-governance — for the consent and benefit-sharing documentation referenced in Section 9.
• carbon-project-timeline — for the validation/verification/issuance timeline that should align with the crediting period stated in Section 1.