mirror of
https://github.com/GuDaStudio/commands.git
synced 2026-03-22 19:18:52 +08:00
v0.2.0：适配openspec正式发布版
This commit is contained in:
GuDaStudio
@@ -108,8 +108,8 @@ cd commands
|
||||
- **风格定义**：整体代码风格**始终定位**为，精简高效、毫无冗余。该要求同样适用于注释与文档，且对于这两者，严格遵循**非必要不形成**的核心原则。
|
||||
- **仅对需求做针对性改动**：严禁影响用户现有的其他功能。
|
||||
- **上下文检索**： 调用 `mcp__auggie-mcp__codebase-retrieval`，必须减少search/find/grep的次数。
|
||||
- **判断依据**：始终以项目代码、grok的搜索结果作为判断依据，严禁使用一般知识进行猜测，允许向用户表明自己的不确定性。
|
||||
|
||||
- **判断依据**：始终以项目代码、grok的搜索结果作为判断依据，严禁使用一般知识进行猜测，允许向用户表明自己的不确定性。在调用编程语言的非内置库时，必须启用grok搜索，以文档作为判断依据进行编码。例如，在调用fastapi库对api接口进行封装时，必须使用联网搜索的最新结果作为依据、阅读官方文档说明编写代码，严禁使用已知的一般知识进行直接编码，这样会直接造成用户项目的崩坏。
|
||||
- **MUST** ultrathink in English.
|
||||
````
|
||||
|
||||
---
|
||||
|
||||
@@ -6,24 +6,19 @@ tags: [openspec, implementation, multi-model, codex, gemini]
|
||||
---
|
||||
<!-- GUDASPEC:START -->
|
||||
**Guardrails**
|
||||
- If the project is detected to lack `./openspec/` dir, prompt the user to initialize the project using `/gudaspec:init`.
|
||||
- Never apply external model prototypes directly—all Codex/Gemini outputs serve as reference only and must be rewritten into readable, maintainable, production-grade code.
|
||||
- Keep changes tightly scoped to the requested outcome; enforce side-effect review before applying any modification.
|
||||
- Minimize documentation—avoid unnecessary comments; prefer self-explanatory code.
|
||||
- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) for additional OpenSpec conventions or clarifications.
|
||||
|
||||
**Steps**
|
||||
Track these steps as TODOs and complete them one by one.
|
||||
|
||||
1. Run `openspec view` to inspect current project status and review `Active Changes`; ask the user to confirm which proposal ID they want to implement and wait for explicit confirmation before proceeding.
|
||||
2. Run `/openspec:apply <proposal_id>`.
|
||||
3. Work through tasks sequentially as defined in `tasks.md`; but Don't complete all tasks in `tasks.md` at once. Just identify **the smallest verifiable phase** that can be quickly accomplished this time, and strictly control the context window for a single implementation.
|
||||
4. Analyze each task in `tasks.md` and route to the appropriate model kernel:
|
||||
- **Route A: Gemini Kernel** — for frontend/UI/styling tasks (CSS, React, Vue, HTML, component design).
|
||||
- **Route B: Codex Kernel** — for backend/logic/algorithm tasks (API, data processing, business logic, debugging).
|
||||
1. Run `openspec view` to inspect current project status and review `Active Changes`; Use `AskUserQuestions` tool ask the user to confirm which proposal ID they want to implement and wait for explicit confirmation before proceeding.
|
||||
2. Run `/opsx:apply <proposal_id>` and then follow it.
|
||||
3. When performing a specific coding task, refer to the code prototype provided by an effective model:
|
||||
- **Route A: Gemini Kernel** — `mcp__gemini__gemini` tool for frontend/UI/styling tasks (CSS, React, Vue, HTML, component design).
|
||||
- **Route B: Codex Kernel** — `mcp__codex__codex` tool for backend/logic/algorithm tasks (API, data processing, business logic, debugging).
|
||||
- **Mandatory constraint**: When communicating with Codex/Gemini, the prompt **must explicitly require** returning a `Unified Diff Patch` only; external models are strictly forbidden from making any real file modifications.
|
||||
5. Upon receiving the diff patch from Codex/Gemini, **never apply it directly**; rewrite the prototype by removing redundancy, ensuring clear naming and simple structure, aligning with project style, and eliminating unnecessary comments.
|
||||
6. Before applying any change, perform a mandatory side-effect review: verify the change does not exceed `tasks.md` scope, does not affect unrelated modules, and does not introduce new dependencies or break existing interfaces; make targeted corrections if issues are found.
|
||||
7. After completing the task, run **multi-model review** to verify.
|
||||
8. After corrections are completed, mark the task item as `- [x]` in `tasks.md`.
|
||||
9. Once all tasks are confirmed complete, run `/openspec:archive`.
|
||||
4. Upon receiving the diff patch from Codex/Gemini, **NEVER apply it directly**; rewrite the prototype by removing redundancy, ensuring clear naming and simple structure, aligning with project style, and eliminating unnecessary comments.
|
||||
5. For each completed task, conduct multi-model reviews using Codex`mcp__codex__codex` / Gemini`mcp__gemini__gemini`, requiring iterative reviews until receiving dual-model **LGTM approval**.
|
||||
6. MUST follow the `/opsx:apply <proposal_id>`.
|
||||
<!-- GUDASPEC:END -->
|
||||
|
||||
@@ -8,68 +8,48 @@ argument-hint: [proposal_id]
|
||||
---
|
||||
<!-- GUDASPEC:START -->
|
||||
**Guardrails**
|
||||
- If the project is detected to lack `./openspec/` dir, prompt the user to initialize the project using `/gudaspec:init`.
|
||||
- Strictly adhere to **OpenSpec** rules when writing **standardized spec-structured projects**.
|
||||
- The goal of this phase is to eliminate ALL decision points from the task flow—implementation should be pure mechanical execution.
|
||||
- Do not proceed to implementation until every ambiguity is resolved and every constraint is explicitly documented.
|
||||
- Multi-model collaboration is mandatory: use both `mcp__codex__codex` and `mcp__gemini__gemini` to surface blind spots and conflicting assumptions.
|
||||
- Every requirement must have Property-Based Testing (PBT) properties defined—focus on invariants, not just example-based tests.
|
||||
- If constraints cannot be fully specified, escalate back to the user or return to the research phase rather than making assumptions.
|
||||
- Refer to `openspec/AGENTS.md` for additional conventions; run `openspec update` if the file is missing.
|
||||
- If constraints cannot be fully specified, escalate back to the user rather than making assumptions.
|
||||
|
||||
**Steps**
|
||||
1. Run `openspec view` to display all **Active Changes**, then confirm with the user which proposal ID (`<proposal_id>`) they wish to refine into a zero-decision plan.
|
||||
|
||||
2. Run `/openspec:proposal <proposal_id>`.
|
||||
2. Run `/opsx:continue <proposal_id>` then follow it to review the current specs and improve quality of specs.
|
||||
|
||||
3. **Multi-Model Implementation Analysis**: Invoke both MCP tools to provide diverse implementation perspectives:
|
||||
```
|
||||
mcp__codex__codex: "Analyze proposal <proposal_id>: Provide implementation approach, identify technical risks, and suggest alternative architectures. Focus on edge cases and failure modes."
|
||||
3. During the review progress, invoke both MCP tools to detect remaining ambiguities:
|
||||
- Use `mcp__codex__codex` tool, e.g. "Review proposal <proposal_id> for decision points that remain unspecified. List each as: [AMBIGUITY] <description> → [REQUIRED CONSTRAINT] <what must be decided>."
|
||||
- Use `mcp__gemini__gemini` tool, e.g. "Identify implicit assumptions in proposal <proposal_id>. For each assumption, specify: [ASSUMPTION] <description> → [EXPLICIT CONSTRAINT NEEDED] <concrete specification>."
|
||||
- **Anti-Pattern Detection** (flag and reject):
|
||||
- Information collection without decision boundaries (e.g., "JWT vs OAuth2 vs session—all viable")
|
||||
- Technical comparisons without selection criteria
|
||||
- Deferred decisions marked as "to be determined during implementation"
|
||||
- **Target Pattern** (required for approval):
|
||||
- Explicit technology choices with parameters (e.g., "JWT with accessToken TTL=15min, refreshToken TTL=7days")
|
||||
- Concrete algorithm selections with configurations (e.g., "bcrypt with cost factor=12")
|
||||
- Precise behavioral rules (e.g., "Lock account for 30min after 5 failed login attempts")
|
||||
- Use `AskUserQuestions` tool for ANY ambiguity, NEVER assume or guess.
|
||||
- **Iterate** with user until ALL ambiguities are resolved into explicit constraints.
|
||||
|
||||
mcp__gemini__gemini: "Analyze proposal <proposal_id>: Evaluate from maintainability, scalability, and integration perspectives. Highlight potential conflicts with existing systems."
|
||||
```
|
||||
Synthesize responses and present consolidated options to the user for constraint selection.
|
||||
4. After clarifying requirements, modify the spec documents. For each change, you MUST run the command `openspec validate <proposal_id> --strict` to ensure the correct format.
|
||||
|
||||
4. **Multi-Model Uncertainty Elimination Audit**: Invoke both MCP tools to detect remaining ambiguities:
|
||||
```
|
||||
mcp__codex__codex: "Review proposal <proposal_id> for decision points that remain unspecified. List each as: [AMBIGUITY] <description> → [REQUIRED CONSTRAINT] <what must be decided>."
|
||||
5. When backend logic modification requirements are identified, Invoke both MCP tools to derive testable invariants:
|
||||
- Use `mcp__codex__codex` tool, e.g. "Extract Property-Based Testing properties from proposal <proposal_id>. For each requirement, identify: [INVARIANT] <mathematical property that must always hold> → [FALSIFICATION STRATEGY] <how to generate test cases that attempt to break it>."
|
||||
- Use `mcp__codex__codex` tool, e.g. "Analyze proposal <proposal_id> for system properties. Define: [PROPERTY] <name> | [DEFINITION] <formal description> | [BOUNDARY CONDITIONS] <edge cases to test> | [COUNTEREXAMPLE GENERATION] <approach>."
|
||||
- **PBT Property Categories to Extract**:
|
||||
- **Commutativity/Associativity**: Order-independent operations
|
||||
- **Idempotency**: Repeated operations yield same result
|
||||
- **Round-trip**: Encode→Decode returns original
|
||||
- **Invariant Preservation**: State constraints maintained across operations
|
||||
- **Monotonicity**: Ordering guarantees (e.g., timestamps always increase)
|
||||
- **Bounds**: Value ranges, size limits, rate constraints
|
||||
- After modify the spec documents with the PBT, MUST run the command `openspec validate <proposal_id> --strict` to ensure the correct format.
|
||||
|
||||
mcp__gemini__gemini: "Identify implicit assumptions in proposal <proposal_id>. For each assumption, specify: [ASSUMPTION] <description> → [EXPLICIT CONSTRAINT NEEDED] <concrete specification>."
|
||||
```
|
||||
|
||||
**Anti-Pattern Detection** (flag and reject):
|
||||
- Information collection without decision boundaries (e.g., "JWT vs OAuth2 vs session—all viable")
|
||||
- Technical comparisons without selection criteria
|
||||
- Deferred decisions marked as "to be determined during implementation"
|
||||
|
||||
**Target Pattern** (required for approval):
|
||||
- Explicit technology choices with parameters (e.g., "JWT with accessToken TTL=15min, refreshToken TTL=7days")
|
||||
- Concrete algorithm selections with configurations (e.g., "bcrypt with cost factor=12")
|
||||
- Precise behavioral rules (e.g., "Lock account for 30min after 5 failed login attempts")
|
||||
|
||||
Iterate with user until ALL ambiguities are resolved into explicit constraints.
|
||||
|
||||
5. **Multi-Model PBT Property Extraction**: Invoke both MCP tools to derive testable invariants:
|
||||
```
|
||||
mcp__codex__codex: "Extract Property-Based Testing properties from proposal <proposal_id>. For each requirement, identify: [INVARIANT] <mathematical property that must always hold> → [FALSIFICATION STRATEGY] <how to generate test cases that attempt to break it>."
|
||||
|
||||
mcp__gemini__gemini: "Analyze proposal <proposal_id> for system properties. Define: [PROPERTY] <name> | [DEFINITION] <formal description> | [BOUNDARY CONDITIONS] <edge cases to test> | [COUNTEREXAMPLE GENERATION] <approach>."
|
||||
```
|
||||
|
||||
**PBT Property Categories to Extract**:
|
||||
- **Commutativity/Associativity**: Order-independent operations
|
||||
- **Idempotency**: Repeated operations yield same result
|
||||
- **Round-trip**: Encode→Decode returns original
|
||||
- **Invariant Preservation**: State constraints maintained across operations
|
||||
- **Monotonicity**: Ordering guarantees (e.g., timestamps always increase)
|
||||
- **Bounds**: Value ranges, size limits, rate constraints
|
||||
|
||||
**Reference**
|
||||
- Use `openspec show <id> --json --deltas-only` to inspect proposal structure when validation fails.
|
||||
- Use `openspec list --specs` to check for conflicts with existing specifications.
|
||||
- Search existing patterns with `rg -n "INVARIANT:|PROPERTY:|Constraint:" openspec/` before defining new ones.
|
||||
- If MCP tools are unavailable, run `/mcp` to check connection status and authenticate if needed.
|
||||
- For complex proposals, consider running steps 2-4 iteratively on sub-components rather than the entire proposal at once.
|
||||
- Use `AskUserQuestions` for ANY ambiguity—do not assume or guess.
|
||||
6. For complex proposals, consider running steps 2-4 iteratively on sub-components and remind the user rather than the entire proposal at once.
|
||||
|
||||
**Exit Criteria**
|
||||
A proposal is ready to exit the Plan phase only when:
|
||||
|
||||
@@ -7,6 +7,7 @@ tags: [gudaspec, research, constraints, exploration, subagents]
|
||||
|
||||
<!-- GUDASPEC:RESEARCH:START -->
|
||||
**Core Philosophy**
|
||||
- If the project is detected to lack `./openspec/` dir, prompt the user to initialize the project using `/gudaspec:init`.
|
||||
- Research produces **constraint sets**, not information dumps. Each constraint narrows the solution space.
|
||||
- Constraints tell subsequent stages "don't consider this direction," enabling mechanical execution without decisions.
|
||||
- The output is "約束集合 + 可验证的成功判据" (constraint sets + verifiable success criteria).
|
||||
@@ -23,7 +24,7 @@ tags: [gudaspec, research, constraints, exploration, subagents]
|
||||
|
||||
**Steps**
|
||||
0. **Generate OpenSpec Proposal**
|
||||
- Run `/openspec:proposal`
|
||||
- Run `/opsx:explore <user question>` always first.
|
||||
|
||||
1. **Initial Codebase Assessment**
|
||||
- Combine user requirements with quick codebase scan using `mcp__auggie-mcp__codebase-retrieval`.
|
||||
@@ -39,6 +40,7 @@ tags: [gudaspec, research, constraints, exploration, subagents]
|
||||
* Subagent 3: Configuration & infrastructure (configs, deployments, build scripts)
|
||||
- Each boundary should be self-contained: no cross-communication needed between subagents.
|
||||
- Define exploration scope and expected output for each subagent.
|
||||
- The subagent takes forever to run, forcing you to wait—absolutely nothing else can be done until the subagent's results are fully obtained.
|
||||
|
||||
3. **Prepare Standardized Output Template**
|
||||
- Define a unified JSON schema that all Explore subagents must follow:
|
||||
@@ -84,23 +86,12 @@ tags: [gudaspec, research, constraints, exploration, subagents]
|
||||
- Update constraint sets with confirmed decisions.
|
||||
|
||||
7. **Generate OpenSpec Proposal**
|
||||
- Run `/openspec:proposal <requirement-description>` to scaffold formal spec.
|
||||
- Transform finalized constraint sets into requirements format.
|
||||
- Structure as:
|
||||
* **Context**: User need + discovered constraints
|
||||
* **Requirements**: Each constraint becomes a requirement with scenario
|
||||
* **Success Criteria**: Derived from aggregated hints and user confirmations
|
||||
- Ensure proposal includes:
|
||||
* All discovered constraints as requirements.
|
||||
* Verifiable scenarios for each requirement.
|
||||
* Clear dependencies and sequencing.
|
||||
* Risk mitigation strategies.
|
||||
- Run `/opsx:ff <requirement-description>` and follow it.
|
||||
- When generate `proposal.md`, strictly prohibit abbreviating user requirements; only expansion is allowed. The generated document MUST NOT contain any ambiguous content. For example, specific project files mentioned by the user must be accurately referenced down to the file path, and should not be abbreviated in a way that misleads document readers into thinking it refers to an online-searched project rather than a local one.
|
||||
|
||||
**Reference**
|
||||
- Review existing constraints: `rg -n "Constraint:|MUST|MUST NOT" openspec/specs`
|
||||
- Inspect codebase structure: `ls -R` or `mcp__auggie-mcp__codebase-retrieval`
|
||||
- Check prior research outputs: `ls openspec/changes/*/research-output.md`
|
||||
- Validate subagent outputs conform to template before aggregation.
|
||||
- Use `AskUserQuestions` for ANY ambiguity—do not assume or guess.
|
||||
|
||||
- Always base judgments on project codes, strictly prohibiting the use of general knowledge for speculation. It is permissible to indicate uncertainty to users.
|
||||
<!-- GUDASPEC:RESEARCH:END -->
|
||||
|
||||
Reference in New Issue
Block a user