nimis

基础设施技能——维护项目 docs/ 目录的模块化组织和进度追踪。由编排器在 Plan 末尾和 Deliver 阶段强制调用，禁止跳过。模块文档按业务维度分目录存放详细内容，进度记录按日期/会话hash存放摘要。支持多人协作和跨会话任务追溯，文件头部标识 Git 账号。 务必在以下场景使用本 skill：创建文档、文档目录管理、docs 目录、产出物管理、输出文档、document output、docs management、模块文档、文档分类、多人协作文档、跨会话文档、进度记录、任务摘要、progress、会话记录、开发日志。

Infrastructure skill — maintains modular organization and progress tracking for the project docs/ directory. Mandatory invocation by orchestrator at end of Plan and during Deliver stages; must not be skipped. Module documents are organized by business dimension in subdirectories with detailed content; progress records are stored as summaries by date/session hash. Supports multi-person collaboration and cross-session task tracing with Git account identification in file headers. Use this skill when: creating documents, document directory management, docs directory, deliverable management, output documentation, document output, docs management, module documentation, document classification, multi-person collaborative documentation, cross-session documentation, progress records, task summaries, progress, session records, development logs.

Full-lifecycle flow orchestrator for project development. Upon receiving user input, it first classifies the input (4 tiers), then adaptively senses project context, scores task difficulty, selects the optimal route, and orchestrates the Plan→Execute→Validate→Deliver four-phase pipeline with quality gates and failure reflow. Use this skill when: the user wants to start a new project, receives a new requirement, needs a full development iteration, wants to go through the complete flow from requirements to delivery, or says things like "start building", "launch the project", "how to implement this requirement", "help me plan this", "do it end-to-end". When the user's intent is to complete an end-to-end development task (rather than just one step), use this skill to orchestrate the entire flow. If the user only needs a specific step (e.g., just write requirement docs), use the corresponding specialized skill directly.

Infrastructure skill — maintains project file tree snapshots and code structure summaries in a SQLite database (.cache/context.db) at the project root, solving the problem of models forgetting project structure across sessions. Mandatory invocation by orchestrator during context awareness stage (before route selection) and Deliver stage; must not be skipped. Scans all project files (source, config, docs, tests, assets), never modifies files. Use this skill when: understanding overall project structure, querying a module's file list and exported symbols, restoring project structure understanding across sessions, project awareness, context sync, project memory, code summary indexing, viewing project structure. This skill does not modify source code or manage document outputs.

项目开发全生命周期的流程编排器。接收用户输入后，先做输入分类（4 档），自适应感知项目上下文、评估任务难度、选择最优路径，编排 Plan→Execute→Validate→Deliver 四阶段并管理质量卡点和失败回流。 务必在以下场景使用本 skill：用户要开始一个新项目、接到一个新需求、要做一次完整的开发迭代、要从需求到交付走一遍完整流程，或者用户说"开始做"、"启动项目"、"这个需求怎么落地"、"帮我规划一下"、"从头到尾做一遍"。 当用户的意图是完成一个端到端的开发任务（而不是只做其中某一步），使用本 skill 来编排整个流程。如果用户只需要其中某一步（如只写需求文档），直接使用对应的专项 skill。

基础设施技能——在项目根目录 .cache/context.db（SQLite）中维护项目文件树快照与代码结构摘要，解决模型跨会话遗忘项目结构的问题。由编排器在上下文感知阶段和 Deliver 阶段强制调用，禁止跳过。扫描项目中所有文件（源码、配置、文档、测试、资源），不修改任何文件。 务必在以下场景使用本 skill：需要了解项目全局结构、查询某模块的文件列表和导出符号、跨会话恢复项目结构理解、项目感知、context sync、项目记忆、project memory、代码摘要索引、查看项目结构。本 skill 不修改源码，不管理文档产出。

API 接口契约与类型系统的详细设计工具。从领域模型和需求文档出发，生成 RESTful/GraphQL API 端点定义、Request/Response DTO 结构、错误响应标准、OpenAPI 规范以及类型代码骨架。产出输出到 specs/{module}/api-contract.md（按业务模块分目录）。 务必在以下场景使用本 skill：用户需要设计 API 接口、定义数据传输对象(DTO)、编写接口文档、制定错误码规范，或者用户说"设计接口"、"定义 API"、"写接口契约"、"DTO 设计"、"接口规范"、"错误码"、"OpenAPI"、"Swagger"。 当用户的任务涉及从业务模型到技术接口的转化时使用本 skill。

从设计文档生成项目代码骨架——包括目录结构、分层架构、Entity/Repository/Service 骨架、配置文件和测试框架初始化。执行阶段的核心工具，将 Plan 阶段产出的领域模型、时序设计、组件设计转化为可编译运行的项目框架。 务必在以下场景使用本 skill：用户要求初始化项目、生成代码骨架、搭建项目结构、创建 Entity、创建 Repository、创建 Service、项目脚手架、scaffold、项目初始化、从设计到代码、组件结构生成、代码生成、模块注册，或将 spec-writing 的交互流描述和 api-contract-design 的端点契约以及 engineering-principles 的架构模式转化为实际代码。

A detailed design tool for API interface contracts and type systems. Starting from domain models and requirement documents, it generates RESTful/GraphQL API endpoint definitions, Request/Response DTO structures, error response standards, OpenAPI specifications, and type code scaffolds. Output to specs/{module}/api-contract.md (organized by business module). Use this skill in the following scenarios: when users need to design API interfaces, define Data Transfer Objects (DTOs), write interface documentation, establish error code standards, or when users say "design API", "define API", "write API contract", "DTO design", "API specification", "error codes", "OpenAPI", "Swagger". Use this skill when the user's task involves transforming business models into technical interfaces.

Generate project code scaffolding from design documents — including directory structure, layered architecture, Entity/Repository/Service skeletons, configuration files, and test framework initialization. Core tool for the execution phase, transforming Plan phase outputs (domain models, sequence designs, component designs) into a compilable and runnable project framework. Use this skill when: the user requests project initialization, code scaffolding generation, project structure setup, creating Entities, Repositories, Services, project scaffolds, initialization, design-to-code transformation, component structure generation, code generation, module registration, or involves converting spec-writing interaction flows, api-contract-design endpoint contracts, and engineering-principles architecture patterns into actual code.

Engineering principles matcher — based on current task and project context, filters applicable development principles and constraints from the principles library, outputting actionable guidance checklists to specs/engineering-principles.md. Does not force inapplicable principles (e.g., won't push TDD on legacy projects without test dependencies). Only outputs principles verified as applicable after context validation. Passively invoked, never auto-triggers. Use this skill when: coding standards, design principles, architecture guidance, code quality, maintainability, extensibility, TDD, DDD, SOLID, design patterns, engineering practices, code review, engineering principles, code quality, best practices, ddd, tdd, bdd, solid, clean code, refactoring suggestions.

Error handling and resilience design — starting from boundary scenarios, design unified exception hierarchies, error code standards, retry strategies, circuit breakers, fallback degradation, and global error interception. Transforms exception scenarios from spec-writing and boundary conditions from api-contract-design into an implementable error handling architecture. Output to specs/{module}/error-handling.md (organized by business module). Use this skill when: the user mentions exception handling, error handling, error codes, exception classification, retry strategies, circuit breakers, degradation, fault tolerance, global exception handling, error handling, circuit breaker, retry, fallback, graceful degradation, bulkhead pattern, timeout strategies, defensive programming, or involves fault tolerance logic from spec-writing exception scenarios and api-contract-design boundary conditions.

Implementation complexity analysis — evaluates implementation difficulty of design proposals, identifies technical risk points, and provides algorithm selection, data structure trade-offs, and complex problem decomposition strategies. Upgrades task-difficulty's "is it hard?" to "what to do when it's complex", producing actionable technical breakthrough plans. Use this skill when: the user mentions technical challenges, algorithm selection, data structure selection, complexity analysis, technical risks, prototype validation, POC, spike, technical research, performance trade-offs, space trade-offs, time complexity, implementation complexity, technical breakthroughs, decomposition strategies, or involves complexity assessment and technical risk identification from Plan phase outputs (spec-writing, api-contract-design, engineering-principles, etc.).

Integration test design — starting from sequence designs and boundary scenarios, generates inter-module integration test strategies, test environment configurations, and test case skeletons. Covers TestContainers, Mock vs real dependency trade-offs, contract testing, API testing, and more. Use this skill when: the user mentions integration tests, TestContainers, API testing, contract tests, E2E tests, inter-module testing, mock databases, test environments, test isolation, test strategies, end-to-end tests, regression tests, interface integration tests, or involves multi-module interaction testing based on spec-writing interaction flows and api-contract-design boundary conditions.

Performance-first design — identifies performance bottlenecks at the architecture level before coding, and designs caching layers, async processing, database indexing, rate limiting, and partitioning strategies. Embeds performance thinking into the system architecture phase to avoid costly post-hoc optimization. Use this skill when: the user mentions performance optimization, cache design, cache strategy, Redis, async processing, message queues, database indexes, index design, rate limiting, circuit breakers, sharding, partitioning, N+1 queries, slow queries, high concurrency, performance bottlenecks, QPS, TPS, response time, throughput, performance baselines, load testing targets, hot data, read-write separation, or involves performance-related decisions from engineering-principles and tech-stack architecture outputs.

Write and revise modular requirement/feature documents, output to the specs/ directory. Each feature document contains a six-section structure: Feature Overview, User Stories, Requirement Description, Technical Requirements, Constraints, and Test Criteria. All structural diagrams (logic, module, flow, sequence, architecture, ER) must use Mermaid code; directory trees use plain text tree format. Monorepo defaults to apps/ + packages/ layout. Use this skill when: the user mentions requirement documents, PRD, product requirements, feature documents, specs, user stories, acceptance criteria, feature requirements, requirement analysis, business requirements, functional requirements, requirement specifications, requirement review, requirement changes, feature decomposition, or asks to write/revise/review detailed feature descriptions, even without explicitly saying "requirement document". Not applicable for pure tech stack selection documents.

Write and maintain tech stack selection documents (output to specs/tech-stack/ directory, split by category), covering frontend, backend, databases, ops, and engineering standards — full-stack technical decisions. Reference tech tables are for selection reference only — users can freely choose any technology, including those not listed in the tables. All architecture and ER diagrams use Mermaid. Use this skill when: the user mentions tech selection, tech stack, technology architecture, technical proposal, architecture design, database design, stack decisions, framework selection, technology roadmap, dependency selection, toolchain selection, frontend/backend selection, infrastructure selection, or asks to write/revise/review technical architecture documents or discuss which frameworks/libraries/tools to use, even without explicitly saying "tech stack". Not applicable for specific feature requirement documents.

工程原则匹配器——根据当前任务和项目上下文，从原则库中筛选出适用的开发原则和约束，输出可执行的指导清单到 specs/engineering-principles.md。不强推不适用的原则（如无测试依赖的旧项目不推TDD），只输出经上下文验证后确实适用的原则。被动调用，不会主动触发。 务必在以下场景使用本 skill：编码规范、设计原则、架构指导、代码质量、可维护性、可扩展性、TDD、DDD、SOLID、设计模式、工程实践、代码审查、engineering principles、code quality、best practices、ddd、tdd、bdd、solid、clean code、重构建议。

错误处理与容错设计——从边界场景出发，设计统一异常体系、错误码规范、重试策略、熔断降级和全局错误拦截方案。将 spec-writing 的异常场景和 api-contract-design 的边界条件转化为可实现的错误处理架构。产出输出到 specs/{module}/error-handling.md（按业务模块分目录）。 务必在以下场景使用本 skill：用户提到异常处理、错误处理、错误码、异常分级、重试策略、熔断、降级、容错、全局异常处理、error handling、circuit breaker、retry、fallback、graceful degradation、隔舱模式、超时策略、防御式编程，或涉及 spec-writing 产出的异常场景和 api-contract-design 产出的边界条件中的容错逻辑。

实现复杂度分析——评估设计方案的实现难度，识别技术风险点，提供算法选择、数据结构权衡和复杂问题分解策略。将 task-difficulty 的"难不难"升级为"复杂怎么办"，产出可行的技术攻关方案。 务必在以下场景使用本 skill：用户提到技术难点、算法选择、数据结构选型、复杂度分析、技术风险、原型验证、POC、spike、技术预研、性能权衡、空间权衡、时间复杂度、实现复杂度、技术攻关、分解策略，或涉及 Plan 阶段综合产出（spec-writing、api-contract-design、engineering-principles 等）中的复杂度评估和技术风险识别。

集成测试方案设计——从时序设计和边界场景出发，生成模块间集成测试策略、测试环境配置和测试用例骨架。覆盖 TestContainers、Mock vs 真实依赖的权衡、契约测试、API 测试等。 务必在以下场景使用本 skill：用户提到集成测试、integration test、TestContainers、API 测试、契约测试、contract test、E2E 测试、模块间测试、Mock 数据库、测试环境、测试隔离、测试策略、端到端测试、回归测试、接口联调测试，或者涉及 spec-writing 的交互流描述和 api-contract-design 的边界条件中多模块交互的测试验证。

性能前置设计——在编码前从架构层面识别性能瓶颈并设计缓存分层、异步处理、数据库索引、限流和分区策略。将性能思维融入系统架构设计阶段，避免事后优化的高成本。 务必在以下场景使用本 skill：用户提到性能优化、缓存设计、缓存策略、Redis、异步处理、消息队列、数据库索引、索引设计、限流、熔断、分库分表、分区、N+1 查询、慢查询、高并发、性能瓶颈、QPS、TPS、响应时间、吞吐量、性能基线、压测目标、热点数据、读写分离，或涉及 engineering-principles 和 tech-stack 产出的架构设计中的性能相关决策。

撰写和修订模块化需求功能文档，输出到 specs/ 目录。每篇功能文档包含六段结构：功能概述、用户故事、需求描述、技术要求、约束条件、测试标准。所有结构图（逻辑、模块、流程、时序、架构、ER）严格使用 Mermaid 代码，目录树使用纯文本树格式。Monorepo 默认 apps/ + packages/ 布局。 务必在以下场景使用本 skill：用户提到需求文档、PRD、产品需求、功能文档、specs、用户故事、user stories、验收标准、acceptance criteria、feature requirements、需求分析、业务需求、功能需求、需求规格、需求评审、需求变更、功能点拆分，或者用户要求撰写 / 修订 / 评审某个功能的详细描述，即使没有明确说“需求文档”。不适用于纯技术选型文档。

撰写和维护技术选型文档（输出到 specs/tech-stack/ 目录，按分类拆分文件），覆盖前端、后端、数据库、运维、工程规范等全栈技术决策。参考技术表仅供选型参考，用户可自由选择任何技术方案——包括表中未列出的技术。所有架构图和 ER 图使用 Mermaid。 务必在以下场景使用本 skill：用户提到技术选型、tech stack、技术架构、技术方案、架构设计、数据库设计、database design、stack decisions、框架选择、技术栈、技术路线、依赖选择、工具链选型、前后端选型、基础设施选型，或者用户要求编写/修订/评审技术架构文档、讨论该用什么框架/库/工具，即使没有明确说“技术选型”。不适用于具体功能需求文档。

Task difficulty assessment throttle — performs multi-dimensional difficulty analysis and scoring on user tasks/requirements to prevent underestimation of complexity. First traces context involved in the task (code structure, dependency chains, impact scope), then produces a composite score with level classification and execution recommendations. Built-in "upward bias": unless the task is obviously simple, proactively bump the difficulty level up. Can be used standalone for pure difficulty assessment, or as a prerequisite judgment before task execution when combined with other tools. Use this skill when: difficulty analysis, task assessment, complexity scoring, difficulty analysis, task scoring, throttle valve, task classification, risk assessment, impact scope analysis, effort estimation, scope analysis, prerequisite judgment.

任务难度评估节流阀——对用户输入的任务/需求进行多维度难度分析和评分，防止低估复杂度。先追溯任务涉及的上下文（代码结构、依赖关系、影响范围），再综合评分并给出分级和执行建议。内置"上浮偏差"：除非任务明显简单，否则主动提升一个难度等级。独立使用时做纯难度评估，结合其他工具时可作为任务执行的前置判断。 务必在以下场景使用本 skill：难度分析、任务评估、复杂度评分、difficulty analysis、task scoring、节流阀、任务分级、风险评估、影响范围分析、工作量评估、scope analysis、前置判断。

Guides users from vague ideas to complete requirements through a "Set Direction → Incremental Output → User Review → Confirm/Correct" loop. Unlike pure Q&A mode, this skill produces reviewable document fragments to docs/01-requirement/ each round — users only need to judge "is this right?" rather than articulate requirements from scratch. Use this skill when: user's requirements are vague or incomplete (e.g., "I want to build a XX system"), user is unsure about technical choices, user requests requirement analysis/review/interview/brainstorming/architecture discussion, or says "help me think about what's missing", "help me sort out the requirements", "let's talk about this project". When input is insufficient for a complete document, enter this skill's QA flow rather than delivering guesswork.

通过"方向定调 → 增量产出 → 用户 Review → 确认修正"的循环，帮助用户从模糊想法走向完整需求。不同于纯问答模式，本 skill 每轮都产出可 Review 的文档片段到 docs/01-requirement/，用户只需判断"对不对"而非从零表达需求。 务必在以下场景使用本 skill：用户的需求描述模糊或不完整（如"我想做一个 XX 系统"）、用户不确定技术方案该怎么选、用户要求进行需求分析、需求调研、需求访谈、需求梳理、需求沟通、技术方案讨论、架构讨论，或者用户说"帮我想想还缺什么"、"帮我理一下需求"、"我们聊聊这个项目"。当输入信息不足以直接输出完整文档时，应先进入本 skill 的 QA 流程，而不是凭猜测交付半成品。

Multi-perspective brainstorming: dispatches multiple SubAgents playing different expert roles (architect, pragmatist, challenger, domain expert) to independently analyze and debate the same design problem. The moderator synthesizes all perspectives to form a consensus solution. Use this skill when: the user wants to brainstorm, discuss designs, compare solutions, conduct architecture reviews, make technical decisions, explore ideas, conduct feasibility analysis, argue for solutions, or when the user says "help me think about how to do this", "what are the options", "let's discuss", "brainstorm", "compare solutions", "which do you think is better". Prefer this skill over giving a single suggestion when the user's question involves multiple possible solutions without an obvious single answer. Not suitable for requirement detail gathering (use requirement-qa) or documentation writing (use spec-writing).

Observability design — plans distributed tracing, structured logging, metrics collection, and alerting strategies during the system architecture phase, ensuring the system is monitorable, debuggable, and measurable after going live. Integrates the three pillars of observability (Traces, Logs, Metrics) into code skeletons. Use this skill when: the user mentions log design, log standards, monitoring, alerting, metrics collection, tracing, OpenTelemetry, Prometheus, Grafana, ELK, structured logging, APM, SLO, SLI, SLA, observability, health check, or involves building operational monitoring capabilities for production systems.

多视角头脑风暴：通过派遣多个 SubAgent 扮演不同专家角色（架构师、务实派、挑战者、领域专家），对同一设计问题进行独立分析和辩论，主持人综合各方观点后形成共识方案。 务必在以下场景使用本 skill：用户要进行头脑风暴、设计讨论、方案对比、架构评审、技术决策、创意探索、可行性分析、方案论证，或者用户说"帮我想想怎么做"、"有什么方案"、"我们讨论一下"、"brainstorm"、"比较一下方案"、"你觉得哪个好"。 当用户的问题涉及多种可能方案且没有明显唯一解时，优先使用本 skill 而不是直接给出单一建议。不适用于需求细节采集（使用 requirement-qa）或文档撰写（使用 spec-writing）。

可观测性设计——在系统架构阶段规划分布式链路追踪、结构化日志、指标收集和告警策略，确保系统上线后可监控、可排查、可度量。将可观测三支柱（Traces、Logs、Metrics）融入代码骨架。 务必在以下场景使用本 skill：用户提到日志设计、日志规范、监控、告警、指标采集、metrics、链路追踪、tracing、OpenTelemetry、Prometheus、Grafana、ELK、结构化日志、structured logging、APM、SLO、SLI、SLA、可观测性、observability、健康检查、health check，或涉及系统上线后的运维监控能力建设。