Design every DocType as a human-facing form, not a flat database table.
Before adding fields, identify:
- the DocType's purpose and primary user
- the real business process or lifecycle it supports
- the relationships, status, reporting, and search needs
- whether it is master data, a transaction, a child table, or a configuration DocType
Field discipline:
- Add only fields that are required for identity, workflow, relationships, decisions, audit, reporting, or search.
- Do not add speculative, vanity, duplicate, or generic fields unless the use case clearly needs them.
- Make required fields truly required, not merely convenient.
- Use child tables only for real one-to-many repeating data.
- Prefer human-readable labels and stable snake_case fieldnames.
Form layout:
- Do not dump all fields into one tab or one section.
- Use
Tab Break for major mental models only when the form has enough fields to justify tabs.
- Use
Section Break for logical groups inside a tab.
- Use
Column Break to create balanced, scan-friendly rows.
- Put the title, status, primary links, and most common required inputs first.
- Put advanced, rare, admin, or integration fields later, and fold them when appropriate.
- Avoid empty tabs, thin sections, and layout breaks that exist only for decoration.
Useful tab patterns include:
- Overview for identity, status, and primary summary fields
- Details for the main business data
- People or Parties for owners, customers, suppliers, employees, or contacts
- Schedule for dates, timelines, reminders, or recurrence
- Finance for amounts, accounts, taxes, or pricing
- Settings for infrequent configuration
- Activity or Audit for comments, references, or system-facing traceability
When proposing or creating a DocType, present the layout grouped by tab and section, and explain why each group exists. If a requested field does not belong, call it out and omit it unless the user confirms the need.
Source: hashgraph-online/awesome-codex-plugins → plugins/Dkm0315/frappe-agent/skills/frappe-doctype-design/SKILL.md
1---2name: frappe-doctype-design3description: Frappe DocType creation and form UX guidance. Use when creating, reviewing, or redesigning DocTypes, including field choice, tabs, sections, columns, required fields, naming, child tables, and form usability.4---567Design every DocType as a human-facing form, not a flat database table.89Before adding fields, identify:10- the DocType's purpose and primary user11- the real business process or lifecycle it supports12- the relationships, status, reporting, and search needs13- whether it is master data, a transaction, a child table, or a configuration DocType1415Field discipline:16- Add only fields that are required for identity, workflow, relationships, decisions, audit, reporting, or search.17- Do not add speculative, vanity, duplicate, or generic fields unless the use case clearly needs them.18- Make required fields truly required, not merely convenient.19- Use child tables only for real one-to-many repeating data.20- Prefer human-readable labels and stable snake_case fieldnames.2122Form layout:23- Do not dump all fields into one tab or one section.24- Use `Tab Break` for major mental models only when the form has enough fields to justify tabs.25- Use `Section Break` for logical groups inside a tab.26- Use `Column Break` to create balanced, scan-friendly rows.27- Put the title, status, primary links, and most common required inputs first.28- Put advanced, rare, admin, or integration fields later, and fold them when appropriate.29- Avoid empty tabs, thin sections, and layout breaks that exist only for decoration.3031Useful tab patterns include:32- Overview for identity, status, and primary summary fields33- Details for the main business data34- People or Parties for owners, customers, suppliers, employees, or contacts35- Schedule for dates, timelines, reminders, or recurrence36- Finance for amounts, accounts, taxes, or pricing37- Settings for infrequent configuration38- Activity or Audit for comments, references, or system-facing traceability3940When proposing or creating a DocType, present the layout grouped by tab and section, and explain why each group exists. If a requested field does not belong, call it out and omit it unless the user confirms the need.4142---4344**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/Dkm0315/frappe-agent/skills/frappe-doctype-design/SKILL.md`