Token导航 LogoToken导航

Agent Skill · 开发

javascript-refactoring(JavaScript refactoring 测试)

用于辅助 Java 项目开发、面向对象设计、Spring 生态、Maven 或 Gradle 依赖和后端工程实践。它适合让 Agent 分析类结构、设计接口、整理服务分层、生成测试或检查常见代码坏味道。使用时需要结合项目已有架构、包结构和依赖版本,不应只按通用教程改代码;涉及数据库、事务、并发或框架配置时,应先确认运行环境和回归测试范围。

javascript-refactoring 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,第三方扫描已通过,按安装量在开发类的 21,746 个 Skill 里排第 14,893。

总安装 652周安装 28GitHub Stars 4,382下载 228核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:javascript-refactoring(JavaScript refactoring 测试)
来源仓库:https://github.com/github/gh-aw
仓库路径:skills/javascript-refactoring
安装命令:
npx skills add https://github.com/github/gh-aw --skill javascript-refactoring
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/github/gh-aw --skill javascript-refactoring

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

提供 JavaScript 代码重构指导,改善结构与可读性。适用于遗留代码清理与技术债务偿还。javascript-refactoring 属于开发类 Skill,可作为该场景下的辅助能力补充。使用时应小步快跑,每次只改一小部分并充分测试。建议配合类型系统(如 TypeScript)提升重构安全性。

安装方式:通过官方工具集安装,支持 AST 级别分析。

来源仓库内路径:skills/javascript-refactoring

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/github/gh-aw --skill javascript-refactoring;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

javascript-refactoring 怎么安装?

在终端执行 npx skills add https://github.com/github/gh-aw --skill javascript-refactoring。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

javascript-refactoring 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

javascript-refactoring 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

javascript-refactoring 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

javascript-refactoring 用的人多吗?

公开数据是累计安装 652 次,近一周安装 28 次,下载 228 次,GitHub 4,382 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

javascript-refactoring 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 来源仓库有 4,382 星,维护活跃度相对可查。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
javascript-refactoring

JavaScript refactoring 测试 · 本页

6524,382只读未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

JavaScript Code Refactoring Guide

This guide explains how to refactor JavaScript code into a separate .cjs file in the gh-aw repository. Follow these steps when extracting shared functionality or creating new JavaScript modules.

Overview

The gh-aw project uses CommonJS modules (.cjs files) for JavaScript code that runs in GitHub Actions workflows. These files are:

  • Embedded in the Go binary using //go:embed directives
  • Bundled using a custom JavaScript bundler that inlines local require() calls
  • Executed in GitHub Actions using actions/github-script@v8

Top-Level Script Pattern

Top-level .cjs scripts (those that are executed directly in workflows) follow a specific pattern:

✅ Correct Pattern - Export main, but don't call it:

async function main() {
  // Script logic here
  core.info("Running the script");
}

module.exports = { main };

❌ Incorrect Pattern - Don't call main in the file:

async function main() {
  // Script logic here
  core.info("Running the script");
}

await main(); // ❌ Don't do this!

module.exports = { main };

Why this pattern?

  • The bundler automatically injects await main() during inline execution in GitHub Actions
  • This allows the script to be both imported (for testing) and executed (in workflows)
  • It provides a clean separation between module definition and execution
  • It enables better testing by allowing tests to import and call main() with mocks

Examples of top-level scripts:

  • create_issue.cjs - Creates GitHub issues
  • add_comment.cjs - Adds comments to issues/PRs
  • add_labels.cjs - Adds labels to issues/PRs
  • update_project.cjs - Updates GitHub Projects

All of these files export main but do not call it directly.

Step 1: Create the New.cjs File

Create your new file in /home/runner/work/gh-aw/gh-aw/pkg/workflow/js/ with a descriptive name:

File naming convention:

  • Use snake_case for filenames (e.g., sanitize_content.cjs, load_agent_output.cjs)
  • Use .cjs extension (CommonJS module)
  • Choose names that clearly describe the module's purpose

Example file structure:

// @ts-check
/// <reference types="@actions/github-script" />

/**
 * Brief description of what this module does
 */

/**
 * Function documentation
 * @param {string} input - Description of parameter
 * @returns {string} Description of return value
 */
function myFunction(input) {
  // Implementation
  return input;
}

// Export the function(s)
module.exports = {
  myFunction,
};

Key points:

  • Include // @ts-check for TypeScript checking
  • Include /// <reference types="@actions/github-script" /> for GitHub Actions types
  • Use JSDoc comments for documentation
  • Export functions using module.exports = {...}
  • Do NOT import @actions/core or @actions/github - these are available globally in GitHub Actions

Step 2: Add Tests

Create a test file with the same base name plus .test.cjs:

Example: pkg/workflow/js/my_module.test.cjs

import { describe, it, expect, beforeEach, vi } from "vitest";

// Mock the global objects that GitHub Actions provides
const mockCore = {
  debug: vi.fn(),
  info: vi.fn(),
  warning: vi.fn(),
  error: vi.fn(),
  setFailed: vi.fn(),
  setOutput: vi.fn(),
  summary: {
    addRaw: vi.fn().mockReturnThis(),
    write: vi.fn().mockResolvedValue(),
  },
};

// Set up global mocks before importing the module
global.core = mockCore;

describe("myFunction", () => {
  beforeEach(() => {
    // Reset mocks before each test
    vi.clearAllMocks();
  });

  it("should handle basic input", async () => {
    // Import the module to test
    const { myFunction } = await import("./my_module.cjs");

    const result = myFunction("test input");

    expect(result).toBe("expected output");
  });

  it("should handle edge cases", async () => {
    const { myFunction } = await import("./my_module.cjs");

    const result = myFunction("");

    expect(result).toBe("");
  });
});

Testing guidelines:

  • Use vitest for testing framework
  • Mock core and github globals as needed
  • Use dynamic imports (await import()) to allow mocking before module load
  • Clear mocks in beforeEach to ensure test isolation
  • Test both success cases and error handling
  • Follow existing test patterns in pkg/workflow/js/*.test.cjs files

Run tests:

make test-js

Step 3: Add Embedded Variable in Go

Add an //go:embed directive and variable in the appropriate Go file:

For shared utility functions (used by multiple scripts):

Add to pkg/workflow/js.go:

//go:embed js/my_module.cjs
var myModuleScript string

Then add to the GetJavaScriptSources() function:

func GetJavaScriptSources() map[string]string {
	return map[string]string{
		"sanitize_content.cjs":       sanitizeContentScript,
		"sanitize_label_content.cjs": sanitizeLabelContentScript,
		"sanitize_workflow_name.cjs": sanitizeWorkflowNameScript,
		"load_agent_output.cjs":      loadAgentOutputScript,
		"staged_preview.cjs":         stagedPreviewScript,
		"is_truthy.cjs":              isTruthyScript,
		"my_module.cjs":              myModuleScript,  // Add this line
	}
}

For main scripts (top-level scripts that use bundling):

Add to pkg/workflow/scripts.go:

//go:embed js/my_script.cjs
var myScriptSource string

Then create a getter function with bundling:

var (
	myScript     string
	myScriptOnce sync.Once
)

// getMyScript returns the bundled my_script script
// Bundling is performed on first access and cached for subsequent calls
func getMyScript() string {
	myScriptOnce.Do(func() {
		sources := GetJavaScriptSources()
		bundled, err := BundleJavaScriptFromSources(myScriptSource, sources, "")
		if err != nil {
			scriptsLog.Printf("Bundling failed for my_script, using source as-is: %v", err)
			// If bundling fails, use the source as-is
			myScript = myScriptSource
		} else {
			myScript = bundled
		}
	})
	return myScript
}

Important:

  • Variables in js.go are for shared utilities that get bundled into other scripts
  • Variables in scripts.go are for main scripts that use the bundler to inline dependencies
  • Use sync.Once pattern for lazy bundling in scripts.go
  • The bundler will inline all local require() calls at runtime

Step 4: Register in the Bundler (if creating a shared utility)

If you're creating a shared utility that will be used by other scripts via require(), it's automatically available through the GetJavaScriptSources() map (Step 3).

The bundler will:

  1. Detect require('./my_module.cjs') in any script
  2. Look up the file in the GetJavaScriptSources() map
  3. Inline the required module's content
  4. Remove the require() statement
  5. Deduplicate if the same module is required multiple times

No additional bundler registration needed - just ensure the file is in the GetJavaScriptSources() map.

Step 5: Use Local Require in Other JavaScript Files

To use your new module in other JavaScript files, use CommonJS require():

Example usage in another .cjs file:

// @ts-check
/// <reference types="@actions/github-script" />

const { myFunction } = require("./my_module.cjs");

async function main() {
  const result = myFunction("some input");
  core.info(`Result: ${result}`);
}

module.exports = { main };

Important: Top-level scripts should export main but NOT call it directly. The bundler injects await main() during inline execution in GitHub Actions.

Require guidelines:

  • Use relative paths starting with ./
  • Include the .cjs extension
  • Use destructuring to import specific functions
  • The bundler will inline the required module at compile time

Multiple requires example:

const { sanitizeContent } = require("./sanitize_content.cjs");
const { loadAgentOutput } = require("./load_agent_output.cjs");
const { generateStagedPreview } = require("./staged_preview.cjs");

Complete Example: Creating a New Utility Module

Let's walk through creating a new format_timestamp.cjs utility:

1. Create the file: pkg/workflow/js/format_timestamp.cjs

// @ts-check
/// <reference types="@actions/github-script" />

/**
 * Formats a timestamp to ISO 8601 format
 * @param {Date|string|number} timestamp - Timestamp to format
 * @returns {string} ISO 8601 formatted timestamp
 */
function formatTimestamp(timestamp) {
  const date = timestamp instanceof Date ? timestamp : new Date(timestamp);
  return date.toISOString();
}

/**
 * Formats a timestamp to a human-readable string
 * @param {Date|string|number} timestamp - Timestamp to format
 * @returns {string} Human-readable timestamp
 */
function formatTimestampHuman(timestamp) {
  const date = timestamp instanceof Date ? timestamp : new Date(timestamp);
  return date.toLocaleString('en-US', {
    dateStyle: 'medium',
    timeStyle: 'short'
  });
}

module.exports = {
  formatTimestamp,
  formatTimestampHuman,
};

2. Create tests: pkg/workflow/js/format_timestamp.test.cjs

import { describe, it, expect } from "vitest";

describe("formatTimestamp", () => {
  it("should format Date object to ISO 8601", async () => {
    const { formatTimestamp } = await import("./format_timestamp.cjs");
    const date = new Date('2024-01-15T12:30:00Z');

    const result = formatTimestamp(date);

    expect(result).toBe('2024-01-15T12:30:00.000Z');
  });

  it("should format timestamp number to ISO 8601", async () => {
    const { formatTimestamp } = await import("./format_timestamp.cjs");
    const timestamp = 1705323000000; // Jan 15, 2024 12:30:00 UTC

    const result = formatTimestamp(timestamp);

    expect(result).toBe('2024-01-15T12:30:00.000Z');
  });
});

describe("formatTimestampHuman", () => {
  it("should format Date object to human-readable string", async () => {
    const { formatTimestampHuman } = await import("./format_timestamp.cjs");
    const date = new Date('2024-01-15T12:30:00Z');

    const result = formatTimestampHuman(date);

    expect(result).toContain('Jan');
    expect(result).toContain('15');
    expect(result).toContain('2024');
  });
});

3. Add to pkg/workflow/js.go:

//go:embed js/format_timestamp.cjs
var formatTimestampScript string

func GetJavaScriptSources() map[string]string {
	return map[string]string{
		// ... existing entries ...
		"format_timestamp.cjs": formatTimestampScript,
	}
}

4. Use in another script:

// @ts-check
/// <reference types="@actions/github-script" />

const { formatTimestamp } = require("./format_timestamp.cjs");

async function main() {
  const now = new Date();
  core.info(`Current time: ${formatTimestamp(now)}`);
}

module.exports = { main };

Note: The script exports main but does not call it. The bundler will inject await main() when the script is executed inline in GitHub Actions.

5. Build and test:

# Format the code
make fmt-cjs

# Run JavaScript tests
make test-js

# Run Go tests (includes bundler tests)
make test-unit

# Build the binary (embeds JavaScript files)
make build

Verification Checklist

Before committing your refactored code:

  • New .cjs file created in pkg/workflow/js/
  • Tests created in corresponding .test.cjs file
  • Tests pass with make test-js
  • Embedded variable added in pkg/workflow/js.go or pkg/workflow/scripts.go
  • If utility: Added to GetJavaScriptSources() map
  • If main script: Created bundling getter function with sync.Once
  • Local require() statements work correctly in other files
  • Code formatted with make fmt-cjs
  • Code linted with make lint-cjs
  • All Go tests pass with make test-unit
  • Build succeeds with make build

Common Patterns

Pattern 1: Shared Utility Function

Files like sanitize_content.cjs, load_agent_output.cjs that provide reusable functions:

  • Add to js.go with //go:embed
  • Add to GetJavaScriptSources() map
  • Use via require() in other scripts

Pattern 2: Main Workflow Script

Files like create_issue.cjs, add_labels.cjs that are top-level scripts:

  • Add to scripts.go with //go:embed as xxxSource variable
  • Create bundling getter function with sync.Once pattern
  • These scripts can require() utilities from GetJavaScriptSources()
  • Must export main function but NOT call it - the bundler injects await main() during execution

Pattern 3: Log Parser

Files like parse_claude_log.cjs that parse AI engine logs:

  • Add to js.go with //go:embed
  • Add case in GetLogParserScript() function
  • Used by workflow compilation system

Troubleshooting

Issue: "required file not found in sources"

Cause: File not added to GetJavaScriptSources() map

Solution: Add the file to the map in pkg/workflow/js.go

Issue: Tests fail with "core is not defined"

Cause: Missing global mocks

Solution: Add proper mocks before importing the module:

global.core = mockCore;
global.github = mockGithub;

Issue: Bundler fails with circular dependency

Cause: File A requires File B which requires File A

Solution: Restructure to break the circular dependency, or combine the modules

Issue: Changes not reflected after rebuild

Cause: Go build cache not recognizing embedded file changes

Solution:

make clean
make build

References

  • Bundler implementation: pkg/workflow/bundler.go
  • JavaScript sources registry: pkg/workflow/js.go
  • Script bundling: pkg/workflow/scripts.go
  • Existing test examples: pkg/workflow/js/*.test.cjs
  • GitHub Actions script documentation: actions/toolkit

平台分布

Codex

38%
按下载量换算87

Claude

29.63%
按下载量换算68

Cursor

19.67%
按下载量换算45

Gemini CLI

9.37%
按下载量换算21

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills