菜单
Discovers and invokes Nexa skills. Use when starting a session or to identify which skill is appropriate for the task at hand. This is the orchestrator skill which governs how all Nexa skills are discovered and invoked.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | nexa-skills |
| description | Discovers and invokes Nexa skills. Use when starting a session or to identify which skill is appropriate for the task at hand. This is the orchestrator skill which governs how all Nexa skills are discovered and invoked. |
Nexa Skills is a set of engineering workflow skills which are intended to be used in the various phases of software development. This skill in particular helps you discover and apply the appropriate skill for the task at hand.
When a task arrives, identify the development phase and apply the corresponding skill:
nexa-claude-marketplace/
├── .claude-plugin/
│ └── marketplace.json # Marketplace metadata listing all plugins
├── nexa-claude-core/ # Stack-agnostic core methodology
│ ├── .claude-plugin/
│ │ └── plugin.json
│ ├── .mcp.json # context7
│ └── skills/ # All workflow steps as skills (slash commands)
│ ├── requirements/
│ ├── entity-model/
│ ├── use-case-diagram/
│ ├── engineer-requirements/
│ ├── use-case-spec/
│ ├── technical-task/
│ ├── sprint-prepare/
│ ├── generate-wireframe/
│ ├── design-screens/
│ ├── code-review/
│ ├── evaluate/
│ ├── report-bug/
│ └── setup-project-rules/
├── nexa-claude-nextjs/ # Next.js technology stack plugin
│ ├── .claude-plugin/
│ │ └── plugin.json
│ ├── .mcp.json # context7, Playwright
│ └── skills/ # All workflow steps as skills (slash commands)
│ ├── setup-env-profiles/
│ ├── setup-i18n/
│ ├── setup-arch-unit/
│ ├── prisma-migration/
│ ├── setup-web-middleware/
│ ├── implement/
│ ├── vitest-test/
│ ├── playwright-test/
│ ├── code-quality/
│ ├── deliver-use-case/
│ ├── resolve-bug/
│ ├── audit/
│ ├── sprint-kickoff/
│ ├── sprint-deliver/
│ ├── sprint-complete/
│ ├── setup-playwright-ci/
│ └── setup-quality-ci/
└── README.md
These behaviors apply at all times, across all skills. They are non-negotiable.
Before implementing anything non-trivial, explicitly state your assumptions:
ASSUMPTIONS I'M MAKING:
1. [assumption about requirements]
2. [assumption about architecture]
3. [assumption about scope]
→ Correct me now or I'll proceed with these.
Don't silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked. Surface uncertainty early — it's cheaper than rework.
When you encounter inconsistencies, conflicting requirements, or unclear specifications:
Bad: Silently picking one interpretation and hoping it's right. Good: "I see X in the spec but Y in the existing code. Which takes precedence?"
You are not a yes-machine. When an approach has clear problems:
Sycophancy is a failure mode. "Of course!" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.
Your natural tendency is to overcomplicate. Actively resist it.
Before finishing any implementation, ask:
If you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.
Touch only what you're asked to touch.
Do NOT:
Your job is surgical precision, not unsolicited renovation.
Every skill includes a verification step. A task is not complete until verification passes. "Seems right" is never enough — there must be evidence (passing tests, build output, runtime data).
These are the subtle errors that look like productivity but create problems:
Check for an applicable skill before starting work. Skills encode processes that prevent common mistakes.
Skills are workflows, not suggestions. Follow the steps in order. Don't skip verification steps.
Multiple skills can apply. A feature implementation might involve design-screens → deliver-use-case in sequence.
| Phase | Skill (slash command) | Description |
|---|---|---|
| Setup | /setup-project-rules | Write Nexa workflow rules into the project's CLAUDE.md |
| Inception | /requirements | Generate requirements from vision |
| Elaboration | /entity-model | Create entity model with Mermaid ER |
| Elaboration | /use-case-diagram | Generate PlantUML use case diagrams |
| Elaboration | /generate-wireframe | Generate low-fidelity wireframe from use cases |
| Elaboration | /engineer-requirements | Clustered elaboration of all use cases with interactive refinement |
| Construction | /use-case-spec | Write detailed use case specifications |
| Construction | /technical-task | Create technical task specifications |
| Construction | /sprint-prepare | Select, refine, and validate use cases for sprint delivery |
| Construction | /design-screens | Create screen design specifications |
| Verification | /code-review | Independent code review (runs in isolation) |
| Verification | /evaluate | Evaluate implementation against spec and design (runs in isolation) |
| Verification | /report-bug | Create structured bug report documents |
| Verification | /change-request | Create structured change request documents for intentional modifications to implemented use cases |
| Phase | Skill (slash command) | Description |
|---|---|---|
| Setup | /setup-env-profiles | Set up local/dev/prod environment profiles with database URLs |
| Setup | /setup-i18n | Set up server-side internationalization with next-intl |
| Setup | /setup-web-middleware | Build auth, RBAC, and security headers middleware |
| Setup | /setup-playwright-ci | Generate GitHub Actions workflow for Playwright E2E tests |
| Setup | /setup-quality-ci | Generate GitHub Actions workflow for code quality and coverage gates |
| Setup | /setup-arch-unit | Set up arch-unit-ts architecture tests with a Husky pre-commit hook |
| Construction | /prisma-migration | Create Prisma schema and migrations |
| Construction | /implement | Implement use cases or technical tasks using Next.js |
| Construction | /vitest-test | Create Vitest integration tests with Testcontainers |
| Construction | /playwright-test | Create Playwright e2e tests |
| Construction | /code-quality | Run oxlint and oxfmt checks (lint, complexity, formatting) |
| Construction | /deliver-use-case | Orchestrate full pipeline from spec to evaluation for a use case |
| Construction | /resolve-bug | Orchestrate the bugfix pipeline: reproduce, analyze, link requirements, fix |
| Verification | /audit | Deep quality audit: DoD, i18n, accessibility, visual fidelity, loading/error states |
| Construction | /sprint-kickoff | Create sprint branch and start delivery |
| Construction | /sprint-deliver | Deliver use cases in priority order from readiness report |
| Completion | /sprint-complete | Close sprint: validate, close GH issues, dashboard, archive, publish |
基于 SOC 职业分类
Orchestrates the full bugfix pipeline for a BUG-XXX or GitHub issue: an isolated tester reproduces the bug and updates the issue, a senior-dev agent writes a root-cause fix plan while a business-analyst agent links the affected requirement(s) in parallel, then the fix is implemented and gated on Definition of Done. Use when the user asks to "fix this bug", "resolve BUG-XXX", "run the bugfix pipeline", pastes a GitHub issue link and asks to fix it, or mentions an end-to-end bug resolution workflow.
Creates structured change request documents for intentional modifications to already-implemented use cases. Use when the user asks to "create a change request", "log a CR", "document a change", or describes a stakeholder-requested modification to existing behavior (e.g., renaming a field, changing validation rules, restructuring data). A change request always references exactly one use case and describes only the delta — the original use case remains immutable.
Creates structured bug report documents with reproduction steps, expected vs actual behavior, and severity classification. Use when the user asks to "report a bug", "file a bug", "document a defect", "log an issue", or mentions a bug, defect, regression, or unexpected behavior that needs to be tracked.
Runs a comprehensive implementation audit for a delivered use case. Checks Definition of Done, i18n completeness and correctness, error message i18n, accessibility, visual fidelity against the design, and loading/error states. Run after /deliver-use-case or before /sprint-complete for a quality deep-dive. Results are advisory — Critical and Major findings should be fixed; Minor findings are observations.
Lead Requirements Engineer that systematically elaborates all use cases through structured analysis, probing questions, and iterative refinement. Processes use cases in thematic clusters, applies CRUD matrix analysis, actor-goal completeness, exception path probing, MoSCoW prioritization, and traceability checks. Spawns a Product Owner sub-agent to answer clarification questions — only genuinely ambiguous decisions reach the human. Updates requirements, entity model, and use case diagram as living documents. Use when the user asks to "engineer requirements", "elaborate use cases", "analyze use cases", "validate use case completeness", "deep-dive on requirements", "prioritize requirements", or mentions requirements engineering, use case elaboration, MoSCoW, or completeness analysis.
Selects a subset of use cases for a sprint, refines requirements, evolves the entity model and use case diagram, generates specs and designs, and produces a sprint readiness report. Treats requirements, entity model, and use case diagram as living documents that evolve per sprint while protecting delivered use cases as immutable. Use when the user asks to "prepare a sprint", "scope a sprint", "refine for sprint", "get use cases ready for delivery", "sprint planning", or mentions sprint preparation, sprint scoping, or delivery readiness.
