Skip to content

Repository files navigation

ChatGPT Personalization

Build, validate, and maintain reusable ChatGPT personalization profiles.

English · Bahasa Indonesia

Open Builder · Guide · Testing

CI MIT License Schema v2.0

Independent open-source project · not affiliated with or endorsed by OpenAI

ChatGPT Personalization workflow

ChatGPT Personalization stores product settings, durable user context, and response instructions in a structured JSON profile. Use the browser builder for the simplest setup or the repository tools for a version-controlled workflow.

Quick start

Browser builder — recommended

Open the ChatGPT Personalization Builder.

  1. Choose a preset. General is the recommended default for everyday English or Indonesian use.
  2. Customize product settings, durable context, and response behavior.
  3. Select the Custom Instructions character target for your ChatGPT plan.
  4. Validate the profile.
  5. Copy the rendered fields into ChatGPT → Settings → Personalization.
  6. Save the profile JSON if you want a reusable copy.

The builder is static, requires no sign-in, and keeps edits in the browser.

Repository / CLI

Use this path when you want version control, local profiles, repeatable rendering, or regression testing.

git clone https://github.com/man612/chatgpt-personalization.git
cd chatgpt-personalization

cp profiles/presets/general.json profiles/local/me.json
python tools/profile.py lint profiles/local/me.json --limit 5000
python tools/profile.py render profiles/local/me.json --out build/me --limit 5000

Use profiles/presets/blank.json instead if you want no behavioral defaults.

On Windows PowerShell, use Copy-Item profiles/presets/general.json profiles/local/me.json instead of cp.

The renderer creates:

build/me/
├── settings.md
├── occupation.txt
├── more-about-you.txt
└── custom-instructions.txt

settings.md is a checklist for ChatGPT product controls. The remaining files map to the closest matching Personalization fields.

Presets

Preset Intended use
general.json Recommended balanced starting point for everyday English or Indonesian use
blank.json No behavioral defaults
tech-generalist.json Technology, troubleshooting, assisted development, research, and UI/UX
knowledge-worker.json Research, planning, documentation, and practical decisions
student.json Learning and explanation without assuming expert vocabulary
product-designer.json Product thinking, interface critique, and design decisions
writer-editor.json Drafting, rewriting, editing, and tone-sensitive work

Public presets are anonymous and reusable. They must not contain maintainer-specific identity or private context.

Writing behavior

All opinionated public presets use the repository's compact natural-writing core for English and Indonesian. It preserves facts and source voice, uses user-provided writing samples when available, and performs one light audit for recurring assistant residue such as filler, rigid symmetry, fake casualness, staged rhetoric, generic endings, and unsupported drafting residue.

The core is adapted from high-value ideas in Sepia with selected Humanizer audit patterns. It is not an AI detector and is not intended to bypass detection systems. Language-specific punctuation and grammar follow the actual language and destination rather than a universal blacklist.

See docs/writing/core.md and docs/writing/indonesian-ai-tells.md. Blank intentionally does not inherit these rules.

Profile roles

profiles/
├── presets/       reusable public starting points
├── local/         private or experimental profiles; gitignored
├── maintainers/   intentionally public reference examples
└── operational/   public-safe account targets used for dogfooding/audit

Normal users should start from profiles/presets/ and save personal work under profiles/local/.

Maintainer and operational profiles are not defaults and are not shown as builder starting points. The Yasman files are retained as public examples of how the maintainer uses and audits the project; they are not profiles other users are expected to copy.

Validation and evaluation

The linter checks schema validity, field limits, possible secrets, repeated text, prompt bloat, over-constraint, and outline bias. Browser and Python renderers are checked for parity in CI.

Structural validity does not prove better model behavior. Behavioral changes should be tested with representative prompts before they become defaults. Human-readable scenarios live in tests/scenarios.md; machine-readable cases live in tests/scenarios.json.

Documentation

Contributing

Focused contributions are welcome. Keep generic tooling identity-agnostic, keep public presets reusable, and add behavioral rules only for observable requirements or repeated failure modes.

Read CONTRIBUTING.md, CODE_OF_CONDUCT.md, and SECURITY.md before contributing.

License

Released under the MIT License. Third-party adaptations and their original notices are documented in THIRD_PARTY_NOTICES.md.

Used by

Contributors

Languages