devtools-ux-writing-refactor

name	devtools-ux-writing-refactor
description	Refactor user-facing UIStrings and localization comments in a DevTools module folder according to UX writing guidelines (child task of b/40799900). Use when simplifying wording, checking sentence case, or improving L10n comments in UIStrings for a specific folder or issue. Don’t use for general code changes or non-UIStrings files.

DevTools UX writing refactoring workflow

Use this skill when addressing a single UX writing refactoring task (one module folder or child issue under tracking bug b/40799900).

0. Environment setup (avoid PATH errors)

In DevTools Linux workspaces, depot_tools and node/npm may not be in PATH in non-interactive agent shells. Before you run Git, gclient, npm, or git cl commands, ensure that your environment is set up:

export PATH=$HOME/depot_tools:$PATH
source ~/.nvm/nvm.sh  # Or export PATH=$(pwd)/third_party/node/linux/node-linux-x64/bin:$PATH

1. Pre-flight issue check and target scope

Before you write code or modify files, check the status of the associated Buganizer issue:

$ISSUES render <issue_number>  # Or use buganizer MCP tools: render_issue / render_issue_with_external

• Why? Multiple developers and agents work on child tasks under b/40799900.
• Action required: If the issue is marked as FIXED, VERIFIED, or CLOSED, is assigned to another active developer, or has an attached Change List (CL), stop immediately and verify whether you need to address it. Ask the user for confirmation before you override existing work.
• Identify target files: If render_issue returns an external redaction notice, use render_issue_with_external to view the full bug description. The bug description typically lists the exact Target Files to refactor for this child task. Focus exclusively on those target files.

2. Create a branch

Create a branch dedicated to this issue from the latest origin/main (after you run gclient sync) using the DevTools version control tool:

git fetch origin
git checkout origin/main
gclient sync
git new-branch fix-<issue_number>

• Why? In Chrome DevTools, don’t use standard Git commands such as git checkout -b or git switch -c. Always use git new-branch so that depot_tools and Gerrit configure tracking information correctly.
• Naming: Always include the issue number in the branch name (for example, fix-531625399).

3. Refactor UIStrings and localization comments

Locate all TypeScript files in the target folder that define const UIStrings = { ... } and apply the 8-point UX writing checklist (cross-check with official DevTools documentation at https://developer.chrome.com/docs/devtools).

[!IMPORTANT] Ignore non-localized or experimental strings: Don’t modify strings in const UIStringsNotTranslate = { ... }, lockedString, or i18n.i18n.lockedString. These strings are for early-stage or experimental features that you mustn’t localize or alter during UX refactoring.

The 8-point checklist

1. Brevity and short synonyms: Replace formal or lengthy words:
   • preserve -> keep | additional -> more | prevent -> stop | receive -> get
   • submit -> send | modification -> change | create -> add | suitable -> fit
   • Check sibling references: If you change a setting name or label (for example, changing “Preserve log” to “Keep log”), search sibling files in the folder for explanatory text or status strings that reference the old name in quotes (for example, “console.clear() was prevented due to ‘Preserve log’”), and update them to match.
2. Cut unnecessary words: Eliminate politeness (please, sorry), filler (very, strongly, there is or there are), and marketing fluff (seamless, awesome, fast, quick).
3. Contractions: Use contractions (don’t, can’t, isn’t, won’t) instead of formal spellings (do not, cannot, is not, will not).
4. Curly apostrophes, quotation marks, and ellipses: Use curly apostrophes (’) in user-facing UIStrings values for contractions and possessives. Double quotes should be straight (") to avoid usability issues when users want to copy string literals, though consider not using double quotes at all where not necessary. Note that using both double quotes and backticks (for example, "Permissions-Policy") is valid and useful when a fixed term needs to be visually enclosed in quotes in the UI, as backticks are used for localization locking and are often not rendered visually. Use the ellipsis character (…) instead of three periods (...). Use prime (′) and double prime () symbols as needed for measurements like length or coordinates.

4. Chrome writing style guide

Also consult the style guides at google3/experimental/users/rachelandrew/tools/chrome_writing/knowledge/style/ for applicable guidelines.

5. Subagent critique of proposed changes

Before running tests or pausing for user review, enter an iterative critique loop with a subagent:

1. Invoke subagent: Use invoke_subagent with TypeName: "self" and Role: "UX Writing Reviewer".
2. Prompt instructions: Provide the subagent with the git diff of your changes and instruct it to critique the refactoring against the 8-point UX writing checklist:
   • Are @description comments specific, informative, and non-redundant (not restating string values)?
   • Are usage sites researched so the UI element type and location are accurately described?
   • Do @description comments and string values strictly follow the casing rule (ONLY panel names in sentence case, feature/view names in all lowercase unless starting a phrase)?
   • Are contractions, curly apostrophes, ellipses, and placeholders ({PH1}) correctly formatted?
   • Were all references in sibling code/tests properly updated?
3. Address feedback and loop:
   • If the subagent raises any feedback, concerns, or suggested fixes, apply the necessary code changes.
   • Re-invoke the subagent with the updated git diff to re-critique the changes.
   • Repeat this loop continuously as long as the subagent has feedback, until the subagent explicitly approves the diff with no remaining issues.

6. Pause for confirmation

Ask the user for a preliminary review of the proposed changes before proceeding. If the user has feedback, address feedback and pause again for confirmation.

7. Mandatory verification and testing

Don’t finish an edit without running the linter and test suite. In DevTools, i18n placeholder changes or string edits can easily break tests or linter rules.

1. Update sibling unit tests Unit test files (*.test.ts) alongside the implementation often assert exact UIString values (such as error messages or warnings). When you refactor a string, check sibling *.test.ts files for assertions that match the old string value, and update them to prevent test failures.
2. Run the linter and auto-fix errors

   npm run lint -- <folder_path>
   

3. Run unit tests You MUST run the full test suite using npm run test to verify that no cross-module regressions, e2e test failures, or snapshot regressions occurred. Do not only run a subset of tests:

   npm run test
   

   (Optionally, you may run npm run test -- <folder_path> first for rapid initial feedback during iterative development, but running npm run test for full test suite coverage is required before completing the task.)
4. Run presubmit checks Ensure that you commit or stage all changes before you run presubmit checks:

   git cl presubmit -u
   

8. Summarize changes and upload the CL

When all tests and presubmit checks pass, commit your changes and upload the CL to Gerrit. Don’t use [uxw] as a prefix.

1. Stage and commit changes

   git add <modified_files>
   git commit -m "Ensure consistent UI Strings in <folder_path>"
   

   (If you update an existing commit on this branch, use git commit --amend).

2. Upload the CL to Gerrit Upload the CL using git cl upload -f. Always pass -f (--force) to prevent git cl upload from prompting or opening an interactive text editor in background agent shells:

   git cl upload -f -d --commit-description="Ensure consistent UI Strings in <folder_path>
   
   Summary of changes:
   - <dynamically list specific words replaced, contractions adopted, or sentence case fixes>
   
   Fixed: <issue_number>"
   

   • Formatting rules:
     • Keep line length below 72 characters.
     • Include Fixed: <issue_number> on a separate line at the bottom of the description so that automation closes the issue.