菜单
This skill should be used when the user asks to "add new behavior", "create a new block", "add a feature", "implement editor controls", "add frontend output", or describes new functionality for UCSC block plugins (ucsc-blocks, ucsc-gutenberg-blocks) that is not a defect fix.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill should be used when the user asks to "run the WordPress app", "start wp-dev.ucsc", "launch and drive the plugin", "open the editor", "interact with the block", or "demonstrate this change" in the UCSC block plugins (ucsc-blocks, ucsc-gutenberg-blocks) Docker environment. Use verify for a specific acceptance criterion and validate for PHP, Jest, or e2e tests.
This skill should be used when the user asks to "fix a block", "debug an issue", "something is broken", "block not showing", "wrong output", or reports any defect in a block, GUI, or app under UCSC block plugins (ucsc-blocks, ucsc-gutenberg-blocks). Require the target and a plain-language problem description before investigating.
This skill should be used when the user asks to "add a block", "create a Gutenberg block", "implement a feature", "modify block code", "extend a block", or when feature/fix scope is already defined and implementation is ready to begin on UCSC block plugins (ucsc-blocks, ucsc-gutenberg-blocks).
This skill should be used when the user asks to "submit feedback", "send feedback", "give feedback about a skill", "report a bug in the plugin", "report a problem with run/validate/verify", "file a suggestion for ucsc-wp-block-dev", or invokes `:feedback` (plugin-related only; not for the WordPress feedback block).
This skill should be used when the user asks to "list skills", "what can you do", "show available commands", "what WordPress block skills are available", or invokes `:hub` (lists plugin inventory and handles session block target resolution).
This skill should be used when the user asks to "maintain the plugin", "validate the plugin structure", "run the plugin self-tests", "review or promote a skill", "check ADR consistency", "study upstream plugin patterns", "publish the maintainer docs", or prepare ucsc-wp-block-dev for release.
| name | feature |
| description | This skill should be used when the user asks to "add new behavior", "create a new block", "add a feature", "implement editor controls", "add frontend output", or describes new functionality for UCSC block plugins (ucsc-blocks, ucsc-gutenberg-blocks) that is not a defect fix. |
| version | 0.1.0 |
| argument-hint | [block] [feature description] [Jira or GitHub URL/ID] |
implements: ADR-009-FEATURE-INTAKE, ADR-036-FEATURE-WORKFLOW, ADR-083-FEATURE-RETROSPECTIVE, ADR-093-FEATURE-BLOCK-TARGET
Use this as the preferred workflow for new behavior. Use fix when existing
behavior is incorrect.
Resolve the target block/app, natural-language request, and optional Jira/GitHub issue from the context. Always ask one concise question only and wait for the answer before using tools if information is missing.
Determine the block target in this order:
bash scripts/session-target.sh get.bash "${CLAUDE_PLUGIN_ROOT}/skills/develop/scripts/resolve-target.sh".Once resolved, persist it:
bash "${CLAUDE_PLUGIN_ROOT}/skills/develop/scripts/session-target.sh" set <slug> <repo> <abs-path>
Before editing, check the current Git branch. Per ADR-047, if it is main,
master, or develop, warn that changes should normally happen on a feature
branch named dev/developer_name/ISSUE-1234_short_desc. Do not create or
switch branches unless the user explicitly asks.
Delegate implementation to the develop skill after the feature is defined. Invoke the develop skill explicitly with the resolved target, desired outcome, and acceptance criteria (for example: develop <target> "Implement X" --jira ISSUE-1234). Preserve the target, requirements, acceptance criteria, and Jira context during that handoff.
For ucsc-gutenberg-blocks domain guidance, read
../references/domain-blocks.md
inside the selected workflow. Resolve block-specific context through
../references/targets.md
rather than a top-level target skill.
Run focused tests, use run for the Docker build and launch workflow, and use
verify for user-facing acceptance evidence. Summarize changed behavior and
offer to generate Conventional Commit syntax. Generate message text only if the
user accepts. Manual check-in is the default; do not run git add, git commit, or equivalent staging/commit operations unless the user explicitly
asks. Never run git push, git push --force, git push --force-with-lease,
or equivalent remote-write operations; provide the command or PR URL for the
user to run instead.