Ediky Tools Overview

ediky_tools is the authoring factory: everything that generates, verifies, and ships content into the website lives here. It runs locally, has no deployment, and its output is exactly one thing — validated markdown landing in the website's src/content/.

The one integration rule

The tools repo does not host content and does not keep its own copy of the lint rules. Both pipelines validate against, and write directly into, the real website checkout, resolved by a single module:

tools/site_config.py   ← the ONE place that answers "where is the website repo"

Default assumption: siblings (code/ediky_tools/ next to code/ediky-website/ediky/). Override with EDIKY_WEBSITE_ROOT. Verify any time with python3 tools/site_config.py.

Why that rule exists — the 34-duplicate incident

Originally the pipelines assumed they lived inside the website repo and computed paths relative to themselves. Split into a separate repo, they kept working — against a local, nearly empty src/content/ and a local, drifting copy of lint-content.mjs. The duplicate-title check therefore only ever knew about the tools repo's own handful of files, never the website's live set. Result: a 75-question batch shipped with 34 accidental duplicates.

The fix is the architecture: site_config.py resolves the real website root, LINT_SCRIPT points at the website's real lint-content.mjs, and every duplicate/validity check runs against live content. There is nothing local to drift.

The pipelines

Pipeline	Section	Page
tools/qgen/qgen.py	DSA / coding questions	qgen
tools/cs_pipeline.py	CS fundamentals (OS/CN/DBMS/OOP/System Design)	CS Pipeline
tools/aptitude_pipeline.py	Aptitude	Aptitude Pipeline
tools/sql_pipeline.py	SQL practice	SQL Pipeline

Each follows the same shape: draft in drafts/ → generate/verify → lint against the website → move into src/content/<section>/ → audit. Prompt templates per section live beside each pipeline (prompts/, cs_pompt/, aptitude_prompt/, sql_prompt/, cp_prompts/).

Shared plumbing

• tools/content_utils.py — frontmatter/section parsing shared by the Python pipelines (the Python mirror of the website's contentParse.js contract).
• tools/cs_eval/ai_service.py — the Python AIService abstraction mirroring functions/_ai-providers.js, so authoring-time grading and runtime grading share one provider contract (AI Pipeline).
• commands.txt — the working crib sheet of real invocations.
• docs/ — the original architecture notes this section is distilled from.

What lives here vs the website's tools/

Easy to confuse: the website repo also has a tools/ directory — but that one holds build-time scripts (build-content.mjs, lint-content.mjs, copy-sql-wasm.mjs, sheet converters) that run inside npm run build. This repo holds authoring-time pipelines that run on a laptop before anything is committed. Rule of thumb: if it needs an AI key or a compiler, it's here; if it runs in CI, it's in the website.