一键在 Manus 中运行任何 Skill

design

星标359

分支98

更新时间2026年6月13日 13:28

Design the solution and write a technical specification based on requirements analysis. Second step of the contribution workflow, use after /analyze.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

hardisgroupcom

hardisgroupcom/sfdx-hardis

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Process

Review analysis: Understand the requirements from the prior /analyze conversation.
Study existing patterns: Read similar commands, providers, or utilities to understand conventions. Check .claude/rules/ for coding and i18n rules.
Design the solution:
- Identify files to create, modify, or delete
- Define the approach (new command, provider method, utility function, etc.)
- For command implementations in src/commands/**, plan for command files to contain only the command class; place interfaces, types, and helper functions in separate utility modules.
- Allowed exception: keep top-level Messages.importMessagesDirectoryFromMetaUrl(import.meta.url) and const messages = Messages.loadMessages(...) in command files when needed for oclif message lookup.
- Consider the provider pattern if external integrations are involved
- Plan i18n keys if new user-visible strings are needed
- If config properties are added/modified, plan updates to config/sfdx-hardis.jsonschema.json
- Consider edge cases and error handling
Write tech spec:
- Overview: One-paragraph summary
- Files to modify: List with description of changes per file
- New files: List with purpose
- i18n keys: New translation keys needed (with English text)
- Dependencies: Any new packages or config changes
- Testing approach: How to verify the changes
- Risks: Potential issues or trade-offs

Do NOT implement anything. Produce only the design document for user review.

$ARGUMENTS

同仓库更多 Skills

同仓库

uxlog-usage

hardisgroupcom/sfdx-hardis

How to pick the correct uxLog level (action, log, warning, error, success, other), the matching chalk color, the options object (sensitive, alwaysVisible), VS Code UI suppression, and uxLogTable. Use when adding or modifying any uxLog call.

2026-07-07359

changelog

hardisgroupcom/sfdx-hardis

Style rules for updating CHANGELOG.md entries. Use whenever the user asks to update, add to, or write entries in CHANGELOG.md.

2026-06-21359

analyze

hardisgroupcom/sfdx-hardis

Gather requirements by asking clarifying questions until the problem is fully understood. First step of the contribution workflow.

2026-06-14359

fix-security-issue

hardisgroupcom/sfdx-hardis

Handle CVE/vulnerability reports from security linters (trivy, osv-scanner, etc.). Tries to upgrade first; ignores only when safe and justified.

2026-06-13359

implement

hardisgroupcom/sfdx-hardis

Implement a feature, bug fix, or code change in sfdx-hardis. Use whenever the user asks to add a feature, fix a bug, implement something, or make a code change - with or without a prior /design phase.

2026-06-13359

pr-watch-fix

hardisgroupcom/sfdx-hardis

Watch the GitHub PR for the current branch, wait for CI to finish, and autonomously fix failing jobs by reading logs, editing sources, and pushing. Stops cleanly when stuck.

2026-06-13359

name	design
description	Design the solution and write a technical specification based on requirements analysis. Second step of the contribution workflow, use after /analyze.
disable-model-invocation	true
allowed-tools	Read Glob Grep
argument-hint	[additional context]
model	opus

You are a software architect for the sfdx-hardis project.

Your goal is to design a solution and produce a technical specification.

Related agent: this skill mirrors the design subagent (same process, also on Opus - architecture and trade-off reasoning is high-complexity work). It stays inline so it can build on the prior /analyze conversation, which a forked subagent would not see.

Process

Review analysis: Understand the requirements from the prior /analyze conversation.
Study existing patterns: Read similar commands, providers, or utilities to understand conventions. Check .claude/rules/ for coding and i18n rules.
Design the solution:
- Identify files to create, modify, or delete
- Define the approach (new command, provider method, utility function, etc.)
- For command implementations in src/commands/**, plan for command files to contain only the command class; place interfaces, types, and helper functions in separate utility modules.
- Allowed exception: keep top-level Messages.importMessagesDirectoryFromMetaUrl(import.meta.url) and const messages = Messages.loadMessages(...) in command files when needed for oclif message lookup.
- Consider the provider pattern if external integrations are involved
- Plan i18n keys if new user-visible strings are needed
- If config properties are added/modified, plan updates to config/sfdx-hardis.jsonschema.json
- Consider edge cases and error handling
Write tech spec:
- Overview: One-paragraph summary
- Files to modify: List with description of changes per file
- New files: List with purpose
- i18n keys: New translation keys needed (with English text)
- Dependencies: Any new packages or config changes
- Testing approach: How to verify the changes
- Risks: Potential issues or trade-offs

Do NOT implement anything. Produce only the design document for user review.

$ARGUMENTS