# Chapter 18: Role Locking: Give AI a 'Thinking Hat' in One Sentence

## Lesson objectives

- **O1** Can assign owners and interfaces to role, task boundary and output standard (artifact: role-lock instruction card)
  - Evidence: The role-lock instruction card names an owner for each of role, task boundary and output standard
- **O2** Can construct a role-lock instruction card showing how information, authority and evidence cross interfaces (artifact: role-lock instruction card)
  - Evidence: The role-lock instruction card defines at least two interfaces with inputs, outputs and authority limits
- **O3** Can write an instruction that locks role, task boundary and output standard (artifact: role-lock instruction card)
  - Evidence: The artifact contains one testable role instruction and one out-of-bound counterexample

## Learning paths

- **Novice**: Chapter transfer task: Can write an instruction that locks role, task boundary and output standard. Use the diagram's network relationship to complete the first evidence item in the role-lock instruction card, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can write an instruction that locks role, task boundary and output standard. Submit the role-lock instruction card, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: role-lock instruction card
- **Diagram kind**: role-instruction
- **Relationship semantics**: The side roles collaborate through a central interface, while the lower band constrains owners, interfaces and evidence; a connection does not transfer authority by itself.
- **Core concepts**: role · task boundary · output standard

![Chapter 18 teaching diagram for the role-lock instruction card](/learning/diagrams/en/chapter-18.svg)

Use the role-lock instruction card to trace cross-role interfaces and make responsibility, authority and evidence transfers explicit.

The diagram places role and output standard on opposite sides with task boundary at the central interface. Arrows show information or work handoffs. The lower band requires an owner, interface and evidence for each link; connectivity alone does not transfer authority.

> **Adapted public course.** Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

## Lesson explanation

### 18.1 Role prompts specify tasks; they do not switch weights

A role label may specify a review perspective and presentation style. It does not modify model weights during inference or guarantee expertise or accuracy. Evaluate its effect on the actual model, inputs and review criteria.

Instead of inventing fifteen years of experience, specify readable sources, review dimensions, output format and unknowns. Require file evidence and distinguish verified defects from hypotheses; do not invent performance gains without measurements. Humans and executable checks must still verify the review.

Switching perspectives preserves project facts, authorization and safety constraints. Do not ask the assistant to forget facts or assume one prompt reliably isolates context. The following library is an editable teaching example, not certified expert capability.

### 18.2 A Common Role Library: Architect, Performance Expert, QA Auditor, Security Consultant, UX Designer, Technical Writer

Below is a high-impact role library honed through practice, covering the six most commonly used domains in AI coding:

1. Architect -- used for architecture review, solution design, and code structure analysis.

> You are now a senior software architect with 15 years of experience, skilled in distributed system design and Domain-Driven Design (DDD). Please review this proposal along the following three dimensions: 1) architectural soundness (module partitioning, dependency direction, coupling); 2) extensibility (whether it supports future requirement evolution); 3) technology selection (whether it conforms to project constraints). Point out problems and give revision suggestions. Do not offer praise; point out defects directly.

2. Performance Expert -- used for performance bottleneck analysis and optimization design.

> You are now a performance optimization expert, proficient in database query optimization, caching strategies, and frontend rendering performance. Please analyze the performance bottlenecks in this code, focusing on: 1) N+1 query issues; 2) unnecessary re-renders; 3) operations that block the main thread. For each bottleneck, provide a concrete optimization plan and the expected order of magnitude of performance improvement.

3. QA Auditor -- used for test plan design and coverage review.

> You are now a QA audit expert. Please review the completeness of this test plan: 1) whether the coverage at each level of the test pyramid is balanced; 2) whether critical business paths are missing; 3) whether boundary conditions and error paths are covered; 4) whether the test coverage targets are reasonable. List all omission points and give supplementation suggestions.

4. Security Consultant -- used for security review and vulnerability scanning.

> You are now an application security consultant, proficient in the OWASP Top 10. Please perform a security review of the following code: 1) SQL injection and XSS risks; 2) whether access control is complete; 3) whether sensitive data is exposed (hardcoded keys, overly detailed error messages); 4) security hazards in third-party dependencies. For each finding, mark its severity (high/medium/low) and provide a remediation plan.

5. UX Designer -- used for interaction design review and user experience optimization.

> You are now a UX designer. Please review the user experience of this interface: 1) whether the information architecture is clear; 2) whether the operation path is the shortest; 3) whether the feedback mechanisms are complete (loading, success, failure, empty states); 4) whether accessibility is up to standard. Give concrete improvement suggestions with reasons.

6. Technical Writer -- used for documentation writing and comment standards.

> You are now a technical documentation engineer. Please write technical documentation for this code, including: 1) function responsibilities and calling conventions; 2) parameter and return value descriptions; 3) usage examples; 4) caveats and edge cases. Requirements: concise, accurate, unambiguous, and covering all the information a reader might need.

### 18.3 Switching Roles Seamlessly in the Same Session

Question: In the same session, I first have the AI act as an "architect" and then as a "security consultant." Will it get confused?

Answer: It will -- unless you use the correct switching method. The effect of a role prompt carries "inertia": once the AI enters a role, it tends to answer all questions from that role's perspective. Switching roles requires three steps:

1. Explicitly exit the current role: "Okay, the architecture review is complete. Now please forget your identity as an architect."
2. Explicitly enter the new role: "Now please switch to being a security consultant and review this proposal from the OWASP Top 10 perspective."
3. Provide task context for the new role: "Focus on the authentication mechanisms and data exposure risks."

A more disciplined practice is to attach a "role label" to every role switch:

<!-- code-example:chapter-18-E1 mode:reference -->
> **Example type: reference.** Reference fragment; it is not guaranteed to run alone. Adapt it to the lesson context, project versions and real interfaces, then validate with observed output.
```text
[Role: Architect]
Please review the module partitioning of this API design...
(The AI responds from the architect's perspective)

[Role: Security Consultant]
Now review the same API design from a security perspective, focusing on:
1. Whether authentication and authorization are complete; 2. Whether sensitive data is exposed; 3. Whether input validation is adequate.
```

Practical tip: In complex projects, it is best to lock in only one primary role per session and explicitly switch to other roles as "subtasks." Mixing multiple roles without explicit switching is a common cause of the AI producing answers that are "neither fish nor fowl."

### [Ready to Use] 10 High-Frequency Role Prompts

> The full version is in Appendix G, "The High-Impact Role Prompt Library." Below is a summary of the 10 most frequently used role prompts:

1. Architecture Audit: "Acting as a senior architect, review the module partitioning, dependency direction, and extensibility of the following design, and point out defects directly."
2. Code Audit: "Acting as a strict code auditor, review this code for correctness, edge case handling, performance hazards, and security issues, and report them ranked by severity."
3. Performance Optimization Expert: "Acting as a performance expert, locate the performance bottlenecks in this code (N+1, re-renders, synchronous blocking) and give quantified optimization suggestions."
4. Security Auditor: "Acting as a security auditor, review this code against the OWASP Top 10, mark each issue as high/medium/low severity, and provide remediation plans."
5. Test Strategist: "Acting as a QA strategist, design a test pyramid (unit/integration/end-to-end) and coverage targets for this feature."
6. Devil's Advocate: "Acting as a devil's advocate, rebut the proposal you just produced and list the scenarios in which it would fail."
7. Domain Expert: "Acting as a domain expert in XX, explain the core concepts and common pitfalls of this business scenario to help me understand the essence of the requirements."
8. Simplifier: "Acting as a simplification expert, review this code, identify the parts that can be significantly simplified without losing functionality, and provide refactoring suggestions."
9. Newcomer Onboarding Guide: "Acting as a long-time project member, introduce the project's architecture, conventions, and common terminology to a developer who has just joined."
10. Decision Advisor: "Acting as a decision advisor, list all the options for this decision, the trade-offs of each, and your recommendation, but leave the final decision to me."

---

> Part Five complete. You have now built a complete map of 14 skills: from fully automated building (Job) to project orchestration (Orchestrator) to core execution (Requirements/Workflow/Inspector) to foundational support (Architect/Coach/Frontend/QA), plus 5 supporting skills (Advisor/Cloner/POC/Legacy/Next). You have learned to use role locking to put a "thinking hat" on the AI with a single sentence.

> Now, let us move on to Part Six: Process Constraints -- Turning a Session into a Controllable Pipeline. There, you will learn how to strip away the AI's "direct execution rights" and force it to "think slowly" like a senior engineer; and how to use telemetry-driven approaches to help the AI grow "far-seeing eyes."

## Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save `chapter-18.md` with versions, decisions, evidence and gaps.

Write architecture and security review prompts with sources, dimensions, output format and unknowns. Compare outputs with and without role labels using one checklist.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: role-lock instruction card

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

- O1: The role-lock instruction card names an owner for each of role, task boundary and output standard
- O2: The role-lock instruction card defines at least two interfaces with inputs, outputs and authority limits
- O3: The artifact contains one testable role instruction and one out-of-bound counterexample

<details>
<summary>Reveal reference feedback (answer first)</summary>

## Reference feedback

Require file evidence and separate confirmed defects from risk hypotheses. Do not invent credentials or performance gains. Role labels do not change model weights or guarantee accuracy; preserve facts and permissions when switching perspective. Record actual comparison results rather than assuming a winner.

### Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.

</details>

## Sources and boundaries

Registered sources support only the external claims used here. The role-lock instruction card, example numbers and exercise scenario are internal instructional design and require project-specific validation.

- [Transformers generation strategies](https://huggingface.co/docs/transformers/generation_strategies) — Hugging Face, 2026-09-17. Greedy, sampling and beam search use different next-token selection strategies, and decoding choices affect output.