kedro-build-demo

Build a Kedro demo

Scope

Every demo you build or prepare includes a self-contained DEMO.html walkthrough in the project root. The working project saves a result that answers the user's question and can be explored in Kedro-Viz. Slides, separate architecture diagrams, Markdown walkthroughs and technical overviews are extras, made only when asked.

• Build in a new folder, or in a fresh blank project the user created for the demo (template files only, no pipelines yet). If the current folder is a project with real pipelines, leave it untouched and ask where the demo should go.
• For a question only about whether Kedro fits, answer it (step 1) and offer to build. Create nothing yet.
• Out of scope: changing or explaining an existing project (explain-project covers explaining), deployment, production hardening and serving live requests.

CRITICAL:

• Say plainly where Kedro helps and where it does not.
• A demo "works" only for the exact command you ran and whose result you inspected. If something blocked the run, hand it over as prepared but unverified.
• Keep real secret values out of code, docs, outputs and shareable configuration. Reference them by name; ignored local credential files are fine. Never open, print or grep a credential file such as conf/local/credentials.yml or .env (step 4), and exclude them from bulk reads and searches. Never print environment variable values or the whole environment; check only whether a required key is set.
• Before writing any file, show a short plan, even if you continue straight away.
• Always create DEMO.html for a demo you build or prepare, and link it from README.md.
• Label every simulated component wherever it appears.
• Get the user's OK before installing packages or making paid or external calls, unless they already gave it.

1. Understand the request and Kedro's role

Take what the request already says, then establish:

• the use case and the result they want to see. That may be a cleaned table, an aggregate, a report, a score or an evaluation;
• the data: theirs, or a generated sample;
• the stack or framework they use or prefer;
• who will watch the demo, when that changes what you deliver;
• constraints such as no API key, no network or limited time;
• how they will judge that it works.