design-identity

name	design-identity
description	Define the user context model — identity axes, context files, persona variants, and privacy rules for the target OS.

/design-identity - User Identity Model Design

When to Use

• After /discover-domain has captured initial user understanding
• When designing the context-library/ structure for the target OS
• When domain-input/identity-model.md needs completion

Inputs

• Auto-loaded: domain-input/identity-model.md (partial, from /discover-domain)
• Auto-loaded: domain-input/domain-workflow.md (what the user does — informs what identity data is needed)
• Auto-loaded: domain-input/audiences.md (what audiences evaluate — informs what identity data drives output)

Process

Step 1: Identity Axes

The context-library in the target OS will contain files that capture "who the user is." These are the identity axes.

Ask the designer to identify 4-7 axes. Guide with these universal patterns:

Pattern	Description	Job-Search-OS Equivalent
Capability inventory	What the user can do, with evidence	experience-library.md
Goals and preferences	What they want, what they'll accept	career-plan.md
Pre-built responses	Answers to common recurring questions	qa-master.md
Target list	Ranked opportunities/targets to pursue	target-companies.md
Relationship map	People, contacts, network state	connection-tracker.md
Performance history	Log of past actions and outcomes	interview-history.md

For each axis:

1. What does this file contain? Describe the data, not the format.
2. Which skills read from it? (Helps determine if the axis is load-bearing or optional)
3. Which skills write to it? (Determines if it accumulates over time)
4. What happens if it's empty? HARD STOP (too critical) or WARN (degraded but usable)?
5. Is it set once or continuously updated?

Step 2: Foundation Identification

One axis is the foundation — the single file that, if empty, makes the entire OS produce garbage. In a production reference OS, this is experience-library.md.

Ask the designer: "If the user fills in only ONE file, which file makes the biggest difference in output quality?"

That file becomes:

• The one that triggers HARD STOP when empty
• The one that gets filled first in onboarding
• The one that every skill references

Step 3: Persona Variants

Ask the designer to describe the 3-7 distinct user types who would use this OS. For each:

1. Name: A short label (e.g., "career-returner," "senior-employed," "early-career")
2. Detection: How does the OS know this is the user's type? What field in which context file indicates it?
3. Workflow adjustments: How does the daily rhythm change? (volume, cadence, tone)
4. Scoring adjustments: Do rubric weights shift? Are there override conditions?
5. Specific failure modes: What goes wrong for this user type that doesn't affect others?
6. Conditional sections: What extra content appears in briefings/output for this type?

Structure into:

## Persona: [Name]

**Detection:** [field] in [file] shows [value]

### Workflow Adjustments
- [what changes]

### Scoring Adjustments
- [weight shifts, overrides]

### Failure Modes
- [what goes wrong uniquely for this persona]

### Conditional Briefing Sections
- [what extra content appears]

Step 4: Privacy Model

Ask the designer:

1. What information is private? What does the user enter that must NEVER appear in any external-facing output? (equivalent to: reasons for career gaps, health conditions, financial constraints)
2. How does private info influence output? It informs INTERNAL analysis (scoring weights, strategy selection, coaching tone) but never appears in generated artifacts.
3. What's the privacy rule? State it as a universal guardrail that every skill must follow.

Structure into:

## Privacy Rules

### Private Fields (NEVER in external output)
- [field]: [why it's private] → [how it's used internally]
- [field]: [why it's private] → [how it's used internally]

### Universal Privacy Guardrail
[One paragraph rule that every skill includes]

Step 5: Context File Schemas

For each identity axis, design the file structure:

## File: context-library/[name].md

### Purpose
[one sentence]

### Schema
[structured template showing sections, fields, and example content]

### Empty State Behavior
- If empty: [HARD STOP / WARN / PROCEED]
- Message to user: "[exact message]"

### Ownership (for DATA_CONTRACT.md)
- **Classification:** [USER-OWNED / SYSTEM-MANAGED / HYBRID]
- **If hybrid:** [what system can do — append-only / merge via script]

### Skills That Read This File
- [list]

### Skills That Write to This File
- [list]

Output

Write the complete identity model to domain-input/identity-model.md.

Tell the designer:

Identity model designed:
- [N] context files: [list with one-line purpose each]
- Foundation file: [X] (HARD STOP when empty)
- [N] persona variants: [list]
- Privacy rules: [N] private fields identified

Key design decision: [the most consequential choice, e.g., "experience-inventory is the foundation because every output depends on real evidence"]

Next: Run /write-quality-contract to define verification rules and anti-patterns.

Quality Checks

Good identity model:

• Foundation file is clearly identified and justified
• Each context file has a clear purpose that's distinct from every other file
• Persona variants have detection logic, not just descriptions
• Privacy rules are specific and actionable
• Empty-state behavior is defined for every file

Bad identity model:

• Too many context files (7+ suggests some should be merged)
• No foundation file identified (everything is "optional")
• Persona variants described but no detection logic
• Privacy section is generic ("be careful with personal info")
• No empty-state handling