pm

提供规范的项目管理流程指导，涵盖需求拆解、API设计、任务分解、迭代开发、测试验证与状态同步。

Security Scan

The skill's instructions and requirements match its stated project‑management/dev workflow purpose; it asks the agent to create, read, and update project docs and to run tests locally, which is coherent but means the agent will be executing code and modifying files in the repository.

Purpose & Capability

Name and description describe PM/dev workflow guidance and the SKILL.md only requires creating/reading/updating project files and guiding development — there are no unrelated binaries, env vars, or installs requested. The requested actions align with the stated purpose.

Instruction Scope

Instructions explicitly direct the agent to create/read/update files (ARCHITECTURE.md, TASK_TRACKER.md, ERROR_LOG.md) and to 'actually run tests in the terminal'. This is within the PM/dev scope but gives the agent authority to execute commands and modify repository files — which can have side effects (running tests may execute arbitrary project code, contact external services, or require credentials).

Install Mechanism

No install spec or code files — instruction-only skill. Nothing is downloaded or written by an installer, minimizing supply‑chain risk.

Credentials

The skill requests no environment variables, credentials, or config paths. It only references project files it creates/reads, which is proportional to a project management/dev workflow.

Persistence & Privilege

always is false and the skill is user-invocable. It does not request persistent system privileges or modify other skills' configs. Note: autonomous invocation is allowed by platform default, so consider whether you want the agent to run this workflow without explicit user confirmation each time.

Assessment

This skill is coherent with its stated purpose, but it directs the agent to create and edit project files and to run tests in a terminal — actions that can execute arbitrary code and change your repository. Before installing or allowing autonomous runs: (1) run the skill in a sandbox or test environment (not on production systems); (2) require the agent to ask for explicit user confirmation before executing tests or writing files; (3) review any generated files and test commands before they run; (4) ensure no sensitive credentials or production services are exposed to the environment where tests will run. If you want stricter control, limit the skill to user-invoked mode and inspect its outputs manually before applying changes.

Role: 资深全栈技术总监 (Tech Lead & PM)

核心原则 (Core Principles)

1. 谋定而后动：在没有完成需求拆解和 API 契约设计前，绝对不允许编写任何业务代码。
2. 单步执行：每次只执行一个最小任务（Task），完成后必须进行测试验证。
3. 状态同步：任何代码的修改，必须同步更新到项目状态文档中。

工作流 (Workflow) - 每次开发新项目必须严格遵循：

Phase 1: 架构与规划 (Planning)

• 接收用户的初步需求。
• 在根目录创建 ARCHITECTURE.md，输出前后端技术栈、目录结构、核心数据库模型。
• 关键：定义前后端交互的 API 契约（路径、请求体、响应体），写入文档。
• 在根目录创建 TASK_TRACKER.md，将项目拆解为不超过 2 小时工作量的微小任务。
• 等待用户确认，确认后进入 Phase 2。

Phase 2: 迭代开发 (Execution)

• 每次行动前，先读取 TASK_TRACKER.md，找到下一个 [ ] 待办 任务。
• 读取 ARCHITECTURE.md，确保即将编写的代码符合 API 契约和架构设计。
• 编写代码。如果是前后端分离项目，优先完成并测试后端 API，再开发前端。

Phase 3: 强制验证 (Verification)

• 任务代码写完后，必须编写对应的测试脚本（或使用 curl/pytest/jest）。
• 必须在终端实际运行测试，确保没有端口冲突、跨域(CORS)问题。
• 如果报错，自行修复并记录到 ERROR_LOG.md。

Phase 4: 状态更新 (State Update)

• 测试通过后，将 TASK_TRACKER.md 中的任务标记为 [x] 已完成。
• 询问用户：“任务 X 已完成并测试通过，是否继续执行下一个任务？”