@simplysm/sd-claude 13.0.71 → 13.0.74

package/claude/skills/sd-review/SKILL.md

@@ -9,104 +9,100 @@ description: "Comprehensive multi-perspective code review (explicit invocation o
 
 Perform a multi-perspective code review of a package or specified path, producing a comprehensive report. **Analysis only — no code modifications.**
 
-Analyzes code via the built-in Explore agent, then runs up to 4 subagents in parallel for specialized review. Collects subagent results, verifies each finding against actual code, and writes the final report.
+Dispatches up to 3 reviewer agents in parallel using prompt templates. Each agent independently explores the codebase from its own perspective. Collects results, verifies findings against actual code, and compiles the final report.
 
 ## Usage
 
-- `/sd-review packages/solid` — review source code at the given path
+- `/sd-review packages/solid` — full review (all 3 perspectives)
+- `/sd-review packages/solid focus on bugs` — selective review based on request
 - `/sd-review` — if no argument, ask the user for the target path
 
-## When to Use
-
-- Before merging major features or after significant refactoring
-- When assessing overall code quality of a package
-- When onboarding to unfamiliar code and want a quality overview
-
-**When NOT to use:**
-
-- Single-file or trivial changes (typo, config tweak)
-- When you need code modifications (sd-review is analysis-only)
-
 ## Target Selection
 
-- With argument: `/sd-review packages/solid` — review source code at the given path
+- With argument: review source code at the given path
 - Without argument: ask the user for the target path
 
 **Important:** Review ALL source files under the target path. Do not use git status or git diff to limit scope.
 
-## Reviewer Agents
+## Reviewer Perspectives
 
-Run subagents in parallel via the Task tool:
+| Reviewer | Prompt Template | Perspective |
+|----------|----------------|-------------|
+| **Code Reviewer** | `code-reviewer-prompt.md` | Correctness & Safety — bugs, security, logic errors |
+| **API Reviewer** | `api-reviewer-prompt.md` | Usability & DX — naming, types, consistency |
+| **Code Simplifier** | `code-simplifier-prompt.md` | Maintainability — complexity, duplication, structure |
 
-| Agent Type             | Role                                                | Condition                                                  |
-| ---------------------- | --------------------------------------------------- | ---------------------------------------------------------- |
-| `sd-code-reviewer`     | Bugs, security, logic errors, convention issues     | Always                                                     |
-| `sd-code-simplifier`   | Complexity, duplication, readability issues         | Always                                                     |
-| `sd-api-reviewer`      | DX/usability, naming, type hints                    | Always                                                     |
-| `sd-security-reviewer` | ORM SQL injection, input validation vulnerabilities | When target path contains ORM queries or service endpoints |
+## Reviewer Selection
 
-## Workflow
+By default, run **all 3 reviewers**. If the user specifies a focus in natural language, select only the relevant reviewer(s):
 
-### Step 1: Code Analysis via Explore Agent
+| User says | Run |
+|-----------|-----|
+| "bugs", "security", "safety" | Code Reviewer only |
+| "API", "naming", "types", "DX" | API Reviewer only |
+| "complexity", "duplication", "structure", "maintainability" | Code Simplifier only |
+| "bugs and API" | Code Reviewer + API Reviewer |
+| (no specific focus) | All 3 |
 
-Invoke the built-in Explore agent via the Task tool to analyze the target path:
+Use judgment for ambiguous requests. When in doubt, run all 3.
 
-```
-Task(subagent_type=Explore)
-Prompt: "very thorough" analysis of <target-path>:
-- Entry points, core files, module boundaries
-- Call chains, data transformations, state changes
-- Abstraction layers, design patterns, dependency graph
-- Error handling, public API surface
-```
+## Workflow
 
-This runs in a **separate context**, so it does not consume the main context window.
+### Step 1: Dispatch Reviewers
 
-### Step 2: Dispatch Analysis to Reviewers
+Read the prompt template files from this skill's directory. Replace `[TARGET_PATH]` with the actual target path. Then dispatch using `Agent(general-purpose)`:
 
-Run subagents **in parallel** via the Task tool. Include the Explore analysis results in each subagent's prompt:
+```
+Agent(subagent_type=general-purpose, prompt=<filled template>)
+```
 
-- **sd-code-reviewer**: Based on the analysis, find bugs, security vulnerabilities, logic errors, and convention issues. Each finding must include **file:line** and **evidence**.
-- **sd-code-simplifier**: Based on the analysis, find unnecessary complexity, code duplication, and readability issues. Each finding must include **file:line** and **evidence**. **No code modifications.**
-- **sd-api-reviewer**: Based on the analysis, review API intuitiveness, naming consistency, type hints, error messages, and configuration complexity. Each finding must include **file:line** and **evidence**.
-- **sd-security-reviewer** _(conditional)_: If the Explore analysis reveals ORM queries (`orm-common`, `orm-node`, query builders, `expr.eq`, `.where()`, `.result()`) or service endpoints (`ServiceServer`, RPC handlers), also dispatch this agent. Based on the analysis, find SQL injection risks, missing input validation, and unvalidated user input reaching ORM queries. Each finding must include **file:line** and **evidence**.
+Run selected reviewers **in parallel** (multiple Agent calls in a single message).
 
-### Step 3: Verify Issues
+### Step 2: Verify Findings
 
-After collecting results from all 3 subagents, verify each issue against the actual code:
+After collecting results from all reviewers, **Read the actual code** for each finding and verify:
 
-- **Valid**: the issue is real → include in the report
+- **Valid**: the issue is real AND within scope → include in the report
+- **Invalid — self-contradicted**: the reviewer's own analysis shows the issue is mitigated (e.g., "exploitability is limited because..."). Drop it.
+- **Invalid — type-only**: reports a type definition as a runtime issue without showing actual runtime code that triggers it. Drop it.
+- **Invalid — out of scope**: the issue is about code outside the target path (e.g., how other packages use this code). Drop it.
+- **Invalid — duplicate**: another reviewer already reported the same issue. Keep only the one from the correct domain (bugs→Code, API→API, structure→Simplifier).
+- **Invalid — bikeshedding**: minor style preference on stable, well-commented code (magic numbers with clear comments, small interface field duplication, naming when used consistently). Drop it.
+- **Invalid — severity inflated**: downgrade or drop findings where the stated severity doesn't match the actual impact.
 - **Invalid — already handled**: handled elsewhere in the codebase (provide evidence)
 - **Invalid — intentional pattern**: by-design architectural decision
 - **Invalid — misread**: the reviewer misinterpreted the code
 
-### Step 4: Final Report
+### Step 3: Final Report
 
-Compile only **verified findings** into a comprehensive report.
+Compile only **verified findings** grouped by severity (not by reviewer):
 
-### Report Structure
+```
+## Review Report: <target-path>
 
-| Section                          | Priority | Source                                                          |
-| -------------------------------- | -------- | --------------------------------------------------------------- |
-| **Architecture Summary**         | —        | Explore analysis                                                |
-| **Critical Issues**              | P0       | Bugs, security vulnerabilities                                  |
-| **Security Issues**              | P0       | SQL injection, input validation (when sd-security-reviewer ran) |
-| **Quality Issues**               | P1       | Logic errors, missing error handling, performance               |
-| **DX/Usability Issues**          | P2       | API intuitiveness, naming, type hints                           |
-| **Simplification Opportunities** | P3       | Complexity removal, duplicate code, abstractions                |
-| **Convention Issues**            | P4       | Project convention mismatches                                   |
+### CRITICAL
+[verified critical findings from all reviewers]
 
-Each issue includes **file:line**, **description**, and **suggestion**.
+### WARNING
+[verified warning findings from all reviewers]
+
+### INFO
+[verified info findings from all reviewers]
+
+### Invalid Findings Summary (optional)
+[findings filtered out and why]
+```
 
-Optionally include an **Invalid Findings Summary** appendix showing which findings were filtered out and why.
+Each finding includes: **source reviewer**, **file:line**, **evidence**, **issue**, and **suggestion**.
 
 ## Common Mistakes
 
-| Mistake                              | Fix                                                 |
-| ------------------------------------ | --------------------------------------------------- |
-| Using git diff to limit review scope | Review ALL source files under target path           |
-| Skipping verification step           | Always verify subagent findings against actual code |
-| Reporting unverified issues          | Only include verified findings in final report      |
+| Mistake | Fix |
+|---------|-----|
+| Using git diff to limit review scope | Review ALL source files under target path |
+| Skipping verification step | Always verify reviewer findings against actual code |
+| Reporting unverified issues | Only include verified findings in final report |
+| Running all reviewers for focused requests | Match reviewer selection to user's request |
 
 ## Completion Criteria
 

package/claude/skills/sd-review/api-reviewer-prompt.md

@@ -0,0 +1,90 @@
+# API Reviewer Prompt
+
+Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
+
+```
+You are reviewing a library's public API for developer experience (DX).
+Your question: "Would a first-time developer be confused or make mistakes using this API?"
+
+## Target
+
+Review ALL source files at [TARGET_PATH].
+
+## Step 1: List all source files
+
+Use Glob to list all .ts files under the target path (exclude node_modules, dist).
+
+## Step 2: Map the public API surface
+
+- Read index.ts to list all exports (types, functions, constants)
+- Read each exported type/interface/function definition
+- Read test files and consumer code to see actual usage patterns
+
+## Step 3: Find issues
+
+Look for:
+- Naming consistency: same concept with different names, inconsistent prefix/suffix
+- Intuitiveness: behavior can't be predicted from the name alone
+- Type design: insufficient types for autocompletion, `any` in public interfaces, generic inference failures
+- Defaults: basic use cases requiring excessive configuration
+- Pattern consistency: similar tasks requiring different patterns
+
+Important: Internal consistency takes priority over external standards.
+Before suggesting a naming change, verify the existing pattern across ALL similar
+components in the library. Do NOT suggest external conventions that break internal consistency.
+
+Do NOT report:
+- Bugs, security, logic errors, race conditions
+- Code complexity, duplication, readability
+- Do NOT use WebSearch to compare with external libraries
+- TypeScript type system limitations that require workarounds (e.g., discriminated unions not narrowing due to template literals) — these are language constraints, not API design flaws
+- Naming preferences where the current name is used consistently across the codebase — consistency > personal preference
+- Minor field duplication in small interfaces (< 10 fields) where extraction adds indirection without real benefit
+
+## Step 4: Self-verify before reporting
+
+Before including ANY finding, verify:
+
+1. **Severity check**: CRITICAL = developers WILL write wrong code because of this API. Not "could theoretically be confusing."
+2. **Consistency check**: Before suggesting a rename, search ALL usages. If the name is used consistently everywhere, it's NOT a finding.
+3. **Scope check**: Only report on the PUBLIC API of the target package. Do not report on how consumers should use it differently.
+
+**Quality over quantity: 3 verified findings > 10 maybe-findings.**
+
+## Constraints
+
+- Analysis only. Do NOT modify any files.
+- Only report issues with real evidence from the code.
+- CRITICAL severity requires proof that the current API actively misleads — not just "could be better."
+
+## Output Format
+
+Use this exact format for every finding:
+
+### [CRITICAL|WARNING|INFO] title
+
+- **File**: path/to/file.ts:42
+- **Evidence**: what you observed (include code snippet)
+- **Issue**: what the problem is
+- **Suggestion**: how to improve it
+
+Severity:
+- CRITICAL: API misleads developers or types are insufficient for correct usage
+- WARNING: Significant DX friction — unnecessary complexity or inconsistency
+- INFO: Minor improvement — better naming or defaults exist
+
+Start your report with:
+
+## API Review Results
+
+### Summary
+- Files reviewed: N
+- Public API surface: brief description
+- Findings: X CRITICAL, Y WARNING, Z INFO
+
+### Findings
+[findings here]
+
+### Positive Observations
+[what's already well-designed — keep these]
+```

package/claude/skills/sd-review/code-reviewer-prompt.md

@@ -0,0 +1,85 @@
+# Code Reviewer Prompt
+
+Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
+
+```
+You are reviewing code for correctness and safety.
+Your question: "Does this code produce wrong results or pose risks?"
+
+## Target
+
+Review ALL source files at [TARGET_PATH].
+
+## Step 1: List all source files
+
+Use Glob to list all .ts files under the target path (exclude node_modules, dist).
+This is your review scope — every file in this list must be examined.
+
+## Step 2: Understand the codebase
+
+Read the project's CLAUDE.md for conventions. Then:
+- Read index.ts to map the module structure
+- Read each source file to understand logic flows, data transformations, error paths
+
+## Step 3: Find issues
+
+Look for:
+- Bugs: null/undefined risks, off-by-one, wrong conditions, missing return values
+- Security: injection, XSS, auth/authz gaps, sensitive data exposure, input validation
+- Race conditions: async ordering, shared state without synchronization
+- Resource leaks: uncleared subscriptions/listeners, unclosed handles
+- Error handling: swallowed exceptions, wrong fallbacks, missing propagation
+
+Do NOT report:
+- Naming consistency, API design, type quality (including `any` types)
+- Code complexity, duplication, readability improvements
+- Style preferences unless they cause actual bugs
+- Type definitions alone — a type allowing `stack?: string` is NOT a security issue unless the runtime code actually sends it unsanitized
+- Speculative future risks — "if config were changed to X, this would break" is not a finding
+- Issues in code OUTSIDE the target path (e.g., how other packages consume these types)
+
+## Step 4: Self-verify before reporting
+
+Before including ANY finding, ask yourself:
+
+1. **Is there runtime code here that actually triggers this?** (Not just a type definition)
+2. **Does the evidence contradict my conclusion?** (If you find a bound/limit that prevents the issue, drop it)
+3. **Is this within the target scope?** (Not about how other packages use this code)
+
+If you write "in practice this is unlikely because..." or "exploitability is limited because..." — that means it's NOT a real finding. Drop it.
+
+**Quality over quantity: 3 verified findings > 10 maybe-findings.**
+
+## Constraints
+
+- Analysis only. Do NOT modify any files.
+- Only report issues where the runtime behavior is demonstrably wrong or risky.
+- If your own analysis shows the issue is mitigated, do NOT report it.
+
+## Output Format
+
+Use this exact format for every finding:
+
+### [CRITICAL|WARNING|INFO] title
+
+- **File**: path/to/file.ts:42
+- **Evidence**: what you observed (include code snippet)
+- **Issue**: what the problem is
+- **Suggestion**: how to fix it
+
+Severity:
+- CRITICAL: Will cause bugs, outages, or security breaches
+- WARNING: Real problem that can occur in practice
+- INFO: Defensive improvement, low risk
+
+Start your report with:
+
+## Code Review Results
+
+### Summary
+- Files reviewed: N
+- Findings: X CRITICAL, Y WARNING, Z INFO
+
+### Findings
+[findings here]
+```

package/claude/skills/sd-review/code-simplifier-prompt.md

@@ -0,0 +1,88 @@
+# Code Simplifier Prompt
+
+Template for `Agent(general-purpose)`. Fill in `[TARGET_PATH]`.
+
+```
+You are a maintainability analyst reviewing code structure.
+Your question: "Would a developer struggle to understand or modify this code?"
+
+## Target
+
+Review ALL source files at [TARGET_PATH].
+
+## Step 1: List all source files
+
+Use Glob to list all .ts files under the target path (exclude node_modules, dist).
+
+## Step 2: Understand the structure
+
+- Map module dependencies and abstraction layers
+- Compare whether similar-role files use consistent patterns
+- Identify complexity hotspots: deep nesting, long functions, complex conditionals
+
+## Step 3: Find issues
+
+Look for:
+- Unnecessary complexity: over-abstraction, needless indirection, complex generics
+- Duplication: same logic repeated, similar functions that could be unified
+- Readability: hard-to-follow control flow, unclear variable names, implicit behavior
+- Structure: too many files for simple concepts, or too many responsibilities in one file
+- Maintainability risk: changes that cascade widely, tightly coupled modules
+
+Do NOT report:
+- Bugs, security, logic errors → that's the code reviewer's job
+- Naming consistency, API design, type quality (including `any` types) → that's the API reviewer's job
+- Property shorthand (`uuid: uuid` vs `uuid`)
+- `else` after `return`
+- Comment style or JSDoc presence/absence
+- Import ordering or formatting preferences
+- Magic numbers that are well-explained by adjacent comments
+- Small interface duplication (< 10 fields) where extracting a base adds indirection without real benefit
+- Type placement across packages unless it causes concrete import/dependency issues
+- Issues in code OUTSIDE the target path (e.g., how other packages implement or consume these types)
+
+## Step 4: Self-verify before reporting
+
+Before including ANY finding:
+
+1. **Impact test**: Would a developer actually struggle with this? Or is it just "could be slightly cleaner"?
+2. **Scope check**: Is the issue IN the target code, or in how other code uses it?
+3. **Overlap check**: Is this already in the code reviewer's or API reviewer's domain? If yes, skip it.
+
+**Quality over quantity: 3 verified findings > 10 maybe-findings.**
+
+## Constraints
+
+- Analysis only. Do NOT modify any files.
+- Do NOT provide corrected code blocks. Describe issues and suggestions in words only.
+- Only report issues with real evidence from the code.
+- Focus on substance: structural issues that genuinely make the code hard to understand or modify.
+- Do NOT report findings that belong to other reviewers' scope.
+
+## Output Format
+
+Use this exact format for every finding:
+
+### [CRITICAL|WARNING|INFO] title
+
+- **File**: path/to/file.ts:42
+- **Evidence**: what you observed (include code snippet)
+- **Issue**: what the problem is
+- **Suggestion**: how to improve it (in words, not code)
+
+Severity:
+- CRITICAL: Major structural problem. Very hard to understand or modify safely.
+- WARNING: Significant maintainability concern. Unnecessary complexity or duplication.
+- INFO: Improvement opportunity. Cleaner approach exists but current code is workable.
+
+Start your report with:
+
+## Maintainability Review Results
+
+### Summary
+- Files reviewed: N
+- Findings: X CRITICAL, Y WARNING, Z INFO
+
+### Findings
+[findings here]
+```

package/claude/skills/sd-worktree/SKILL.md

@@ -16,10 +16,11 @@ model: haiku
 
 2. **If `merge` fails or produces conflicts → STOP IMMEDIATELY and show this message:**
    ```
-   ⚠️ merge 중 문제가 발생했습니다.
-   직접 수동으로 merge를 진행해 주세요.
-   (에러 내용: <에러/충돌 정보 그대로 출력>)
+   ⚠️ A problem occurred during merge.
+   Please proceed with the merge manually.
+   (Error details: <print error/conflict info as-is>)
    ```
+   - Show this message in the system's configured language.
    - Do NOT attempt to resolve conflicts yourself.
    - Do NOT run `git merge --abort` without asking.
    - Do NOT proceed to `clean` after a failed merge.
@@ -28,10 +29,11 @@ model: haiku
 
 3. **If `rebase` fails or produces conflicts → STOP IMMEDIATELY and show this message:**
    ```
-   ⚠️ rebase 중 문제가 발생했습니다.
-   직접 수동으로 rebase를 진행해 주세요.
-   (에러 내용: <에러/충돌 정보 그대로 출력>)
+   ⚠️ A problem occurred during rebase.
+   Please proceed with the rebase manually.
+   (Error details: <print error/conflict info as-is>)
    ```
+   - Show this message in the system's configured language.
    - Same rules as merge. Do NOT auto-resolve. Just show the message and STOP.
 
 4. **NEVER run destructive git commands during worktree workflows:**
@@ -102,9 +104,9 @@ node .claude/skills/sd-worktree/sd-worktree.mjs merge [name]
 
 **MERGE SAFETY PROTOCOL:**
 1. Before merge: check BOTH main and worktree for uncommitted changes
-2. If the script exits with non-zero → show "직접 수동으로 merge해 주세요" message and STOP.
+2. If the script exits with non-zero → show "Please proceed with the merge manually." message (in system language) and STOP.
 3. After merge: run `git status` in main to confirm no conflicts
-4. If conflicts or errors → show "직접 수동으로 merge해 주세요" message and STOP.
+4. If conflicts or errors → show "Please proceed with the merge manually." message (in system language) and STOP.
 5. Only proceed to `clean` after confirming merge was fully successful
 
 ### clean — Remove worktree and delete branch

package/claude/skills/sd-worktree/sd-worktree.mjs

@@ -13,7 +13,7 @@ function getOutput(command) {
   return execSync(command, { encoding: "utf-8" }).trim();
 }
 
-// 메인 working tree 경로 (worktree 안에서 실행해도 정확)
+// Main working tree path (accurate even when run inside a worktree)
 const mainWorktree = getOutput("git worktree list --porcelain")
   .split("\n")[0]
   .replace("worktree ", "");
@@ -71,7 +71,7 @@ switch (cmd) {
       console.error("Usage: sd-worktree.mjs merge [name]  (or run inside .worktrees/<name>)");
       process.exit(1);
     }
-    // uncommitted 변경 확인
+    // Check for uncommitted changes
     const worktreePath_m = resolve(mainWorktree, ".worktrees", name);
     if (existsSync(worktreePath_m)) {
       const status = getOutput(`git -C "${worktreePath_m}" status --porcelain`);
@@ -99,7 +99,7 @@ switch (cmd) {
       console.error(`Error: worktree '${name}' does not exist.`);
       process.exit(1);
     }
-    // uncommitted 변경 확인
+    // Check for uncommitted changes
     const statusR = getOutput(`git -C "${worktreePath_r}" status --porcelain`);
     if (statusR) {
       console.error(`Error: worktree '${name}' has uncommitted changes:\n${statusR}`);
@@ -119,7 +119,7 @@ switch (cmd) {
       console.error("Usage: sd-worktree.mjs clean [name]  (or run inside .worktrees/<name>)");
       process.exit(1);
     }
-    // worktree 안에서 실행 시 차단
+    // Block execution from inside the worktree
     const worktreePath = resolve(mainWorktree, ".worktrees", name);
     const cwd = process.cwd();
     if (cwd === worktreePath || cwd.startsWith(worktreePath + "/")) {
@@ -134,7 +134,7 @@ switch (cmd) {
       try {
         run(`git worktree remove --force "${worktreePath}"`, { cwd: mainWorktree });
       } catch {
-        // node_modules 등으로 git worktree remove 실패 시 수동 정리
+        // Manual cleanup when git worktree remove fails (e.g., due to node_modules)
         console.log("git worktree remove failed, cleaning up manually...");
         rmSync(worktreePath, { recursive: true, force: true });
         run("git worktree prune", { cwd: mainWorktree });

package/dist/commands/auth-list.d.ts

@@ -1,2 +1,2 @@
-export declare function runAuthList(homeDir?: string): void;
+export declare function runAuthList(homeDir?: string): Promise<void>;
 //# sourceMappingURL=auth-list.d.ts.map

package/dist/commands/auth-list.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"auth-list.d.ts","sourceRoot":"","sources":["../../src/commands/auth-list.ts"],"names":[],"mappings":"AAIA,wBAAgB,WAAW,CAAC,OAAO,CAAC,EAAE,MAAM,GAAG,IAAI,CAuClD"}
+{"version":3,"file":"auth-list.d.ts","sourceRoot":"","sources":["../../src/commands/auth-list.ts"],"names":[],"mappings":"AAwEA,wBAAsB,WAAW,CAAC,OAAO,CAAC,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC,CAyDjE"}

package/dist/commands/auth-list.js

@@ -1,7 +1,53 @@
 import fs from "fs";
 import path from "path";
 import { listProfiles, getCurrentUserID, getProfileDir } from "./auth-utils.js";
-function runAuthList(homeDir) {
+const FETCH_TIMEOUT_MS = 5e3;
+async function fetchUsage(accessToken) {
+  try {
+    const controller = new AbortController();
+    const timeout = setTimeout(() => controller.abort(), FETCH_TIMEOUT_MS);
+    const response = await fetch("https://api.anthropic.com/api/oauth/usage", {
+      headers: {
+        Authorization: `Bearer ${accessToken}`,
+        "anthropic-beta": "oauth-2025-04-20"
+      },
+      signal: controller.signal
+    });
+    clearTimeout(timeout);
+    if (!response.ok) {
+      return void 0;
+    }
+    return await response.json();
+  } catch {
+    return void 0;
+  }
+}
+function formatTimeRemaining(isoDate) {
+  if (isoDate == null) return "";
+  try {
+    const resetTime = new Date(isoDate).getTime();
+    if (Number.isNaN(resetTime)) return "";
+    const diffMs = resetTime - Date.now();
+    if (diffMs <= 0) return "";
+    const diffMinutes = Math.floor(diffMs / (1e3 * 60));
+    const diffHours = Math.floor(diffMinutes / 60);
+    const days = Math.floor(diffHours / 24);
+    const hours = diffHours % 24;
+    const minutes = diffMinutes % 60;
+    if (days > 0) return `${String(days)}d${String(hours)}h`;
+    if (hours > 0) return `${String(hours)}h${String(minutes)}m`;
+    return `${String(minutes)}m`;
+  } catch {
+    return "";
+  }
+}
+function formatUsage(label, data) {
+  if (data == null) return `${label}: ?`;
+  const pct = data.utilization != null ? `${String(Math.round(data.utilization))}%` : "?";
+  const remaining = formatTimeRemaining(data.resets_at);
+  return remaining ? `${label}: ${pct}(${remaining})` : `${label}: ${pct}`;
+}
+async function runAuthList(homeDir) {
   const profiles = listProfiles(homeDir);
   if (profiles.length === 0) {
     console.log("No saved profiles.");
@@ -9,26 +55,38 @@ function runAuthList(homeDir) {
   }
   const currentUserID = getCurrentUserID(homeDir);
   const sorted = [...profiles].sort((a, b) => a.localeCompare(b));
-  for (const name of sorted) {
-    const profileDir = getProfileDir(name, homeDir);
-    const authData = JSON.parse(
-      fs.readFileSync(path.join(profileDir, "auth.json"), "utf-8")
-    );
-    const credData = JSON.parse(
-      fs.readFileSync(path.join(profileDir, "credentials.json"), "utf-8")
-    );
-    const oauthAccount = authData["oauthAccount"];
-    const email = oauthAccount?.["emailAddress"] ?? "";
-    const userID = authData["userID"];
-    const oauth = credData["claudeAiOauth"];
-    let expiresStr = "unknown";
-    if (oauth != null && typeof oauth["expiresAt"] === "number") {
-      const d = new Date(oauth["expiresAt"]);
-      expiresStr = `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}-${String(d.getDate()).padStart(2, "0")}`;
-    }
-    const isActive = currentUserID != null && userID === currentUserID;
-    const prefix = isActive ? "*" : " ";
-    console.log(`${prefix} ${name} (${email}) expires: ${expiresStr}`);
+  const results = await Promise.all(
+    sorted.map(async (name) => {
+      const profileDir = getProfileDir(name, homeDir);
+      const authData = JSON.parse(
+        fs.readFileSync(path.join(profileDir, "auth.json"), "utf-8")
+      );
+      const credData = JSON.parse(
+        fs.readFileSync(path.join(profileDir, "credentials.json"), "utf-8")
+      );
+      const oauthAccount = authData["oauthAccount"];
+      const email = oauthAccount?.["emailAddress"] ?? "";
+      const userID = authData["userID"];
+      const oauth = credData["claudeAiOauth"];
+      let expiresStr = "unknown";
+      if (oauth != null && typeof oauth["expiresAt"] === "number") {
+        const d = new Date(oauth["expiresAt"]);
+        expiresStr = `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, "0")}-${String(d.getDate()).padStart(2, "0")}`;
+      }
+      const isActive = currentUserID != null && userID === currentUserID;
+      const prefix = isActive ? "*" : " ";
+      const accessToken = oauth?.["accessToken"];
+      const expiresAt = oauth?.["expiresAt"];
+      const tokenExpired = typeof expiresAt === "number" && Date.now() > expiresAt;
+      const usage = accessToken != null && !tokenExpired ? await fetchUsage(accessToken) : void 0;
+      const dailyData = usage?.daily ?? usage?.five_hour;
+      const fiveHourStr = formatUsage("5h", dailyData);
+      const weekStr = formatUsage("7d", usage?.seven_day);
+      return `${prefix} ${name} (${email}) expires: ${expiresStr} \u2502 ${fiveHourStr} \u2502 ${weekStr}`;
+    })
+  );
+  for (const line of results) {
+    console.log(line);
   }
 }
 export {