| name | personal-operating-profile |
| description | Apply Amine's cross-domain working preferences and rule precedence. Use when starting substantial work, resolving ambiguous implementation choices, deciding autonomy or communication style, or composing other skills in this repository. |
Personal Operating Profile
Purpose
Use the personal profile as a decision layer without replacing project rules or professional judgment.
Confirmed North Star
- UI should look product-specific and directed by a skilled human, not assembled from interchangeable AI templates.
- Prose should read as natural expert communication without formulaic AI-style filler or structure.
- AI-assisted research papers should meet a serious human-expert standard for contribution, evidence, method, citations, limitations, and writing.
Unspecified workflow preferences use repository evidence, professional safeguards, and reversible defaults. Do not interrupt the task for additional personalization unless the decision materially changes the result.
Inputs
- The current request and authorization boundary.
- Repository-local instructions and established patterns.
- The confirmed north star above and any repository-local project context.
- Whether a preference is confirmed, observed, inferred, or an objective safeguard.
Process
- Read the current request and the repository's own instructions first.
- Apply only the confirmed priority relevant to the task; avoid loading unrelated preference material.
- Separate personal taste from objective correctness, safety, accessibility, security, and evidence requirements.
- Apply the precedence order in the profile when rules conflict.
- Prefer reversible, scoped action when the profile leaves a choice open.
- State a consequential inferred assumption; do not narrate routine choices.
- Challenge a weak instruction with concrete reasoning, then continue if an in-scope professional interpretation exists.
Constraints
- Never use a personal preference to weaken safety, evidence, compatibility, or repository contracts.
- Do not load the entire profile for a trivial task.
- Do not describe an inferred preference as confirmed.
- Do not imitate incidental code style from one project as a universal preference.
Verification
- The result follows the current request and repository rules before personal defaults.
- Any consequential assumption is visible and reversible.
- The response style and implementation choices match the relevant profile sections.
- No objective quality requirement was reclassified as taste.
Failure Modes
- Over-personalization: applying UI preferences to a project with an established design system.
- Under-personalization: producing generic marketing copy or speculative abstractions despite profile evidence.
- False certainty: treating unanswered interview items as direct instructions.
- Rule flooding: loading every preference into every task.
Examples
Feature request with no architecture direction: inspect existing patterns, choose the smallest compatible implementation, and record a material assumption instead of offering ten options.
Existing branded UI: follow the product's design system even if it differs from the profile's default palette or radius preferences.
Sources
See ../../sources/personal-operating-profile.sources.md.
