frappe-customizations-baker
Frappe — Bake Customizations
Move live-database Custom Fields and Property Setters into the codebase so they survive bench migrate on fresh installs, are version-controlled, and no longer depend on ad-hoc DB state.
Quick start
-
Fetch customizations:
BENCH=$(pwd) PYTHON="$BENCH/env/bin/python" SCRIPT=$(find "$BENCH" -path "*/frappe-customizations-baker/scripts/fetch_customizations.py" | head -1) "$PYTHON" "$SCRIPT" --app <app_name> -
Choose baking target based on app ownership:
- Same-app → Use
frappe-doctype-schema(native field) - Different-app → Use
frappe-customizations-writer(sync_on_migrate custom/ file)
- Same-app → Use
-
Generate cleanup patch to delete DB records after baking
Workflows
Primary workflow: Bake customizations
Context: User requests customizations from DB → code (e.g. "persist field customizations", "bake in Employee fields").
Steps:
- Fetch customizations via bundled script
- Filter/validate candidates (skip custom doctypes, handle duplicates)
- Initiate
frappe-doctype-schemaorfrappe-customizations-writerfor each DocType group - Draft cleanup patches (one per app) to delete now-redundant DB records
- Run
bench migrateto apply DB changes
Feature workflow: Ensure all necessary fields are baked in
Context: User is developing a feature and asks to ensure all required fields are baked in.
Steps:
- Build a feature field map by reading code and listing
(DocType, fieldname, usage location). - Check whether each field is already defined in code (
doctype/*.jsonorcustom/*.json). - For missing fields only, run a targeted search in dev DB customizations and continue with the bake plan.
- If missing fields exist in DB customizations, continue from the detailed workflow (analysis -> bake -> cleanup patch).
- If no matching DB customizations exist, proceed only with Step 3 of the detailed workflow (define fields in code), then continue the feature plan.
Advanced features
See REFERENCE.md for:
- Mental model:
doctype_appvscustomization_appdistinction - Detailed step-by-step workflow with edge cases
- Feature field-map workflow for feature development
- Decision tree for filtering candidates
- Common pitfalls (blank modules, Property Setter quirks,
default_print_format)
More from kehwar/skills
to-prd
Turn the current conversation context into a PRD and publish it to Beads. Use when user wants to create a PRD from the current context.
9setup-workflow-skills
Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo uses Beads for issue tracking and where to find domain docs. Run before first use of `to-issues`, `to-prd`, `tdd`, `improve-codebase-architecture`, or `zoom-out` — or if those skills appear to be missing context about the issue tracker or domain docs.
9grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
7to-tasks
Break a plan, spec, or PRD into independently-grabbable tasks/issues on Beads Issue Tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into tasks, create implementation tickets, or break down work into tasks.
7improve-codebase-architecture
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
6grill-with-docs
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
4