GuDaStudio/commands
1
0
Fork 0
mirror of https://github.com/GuDaStudio/commands.git synced 2026-03-22 19:18:52 +08:00
Code Issues Packages Projects Releases Wiki Activity

v0.2.0：适配openspec正式发布版

Browse Source
This commit is contained in:
GuDaStudio
2026-01-28 11:04:28 +08:00
parent cc33938249
commit 32d5902088
4 changed files with 46 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -108,8 +108,8 @@ cd commands
- **风格定义**：整体代码风格**始终定位**为，精简高效、毫无冗余。该要求同样适用于注释与文档，且对于这两者，严格遵循**非必要不形成**的核心原则。 - **风格定义**：整体代码风格**始终定位**为，精简高效、毫无冗余。该要求同样适用于注释与文档，且对于这两者，严格遵循**非必要不形成**的核心原则。
- **仅对需求做针对性改动**：严禁影响用户现有的其他功能。 - **仅对需求做针对性改动**：严禁影响用户现有的其他功能。
- **上下文检索**： 调用 `mcp__auggie-mcp__codebase-retrieval`，必须减少search/find/grep的次数。 - **上下文检索**： 调用 `mcp__auggie-mcp__codebase-retrieval`，必须减少search/find/grep的次数。
- **判断依据**：始终以项目代码、grok的搜索结果作为判断依据，严禁使用一般知识进行猜测，允许向用户表明自己的不确定性。 - **判断依据**：始终以项目代码、grok的搜索结果作为判断依据，严禁使用一般知识进行猜测，允许向用户表明自己的不确定性。在调用编程语言的非内置库时，必须启用grok搜索，以文档作为判断依据进行编码。例如，在调用fastapi库对api接口进行封装时，必须使用联网搜索的最新结果作为依据、阅读官方文档说明编写代码，严禁使用已知的一般知识进行直接编码，这样会直接造成用户项目的崩坏。
- **MUST** ultrathink in English.
```` ````
--- ---

23
gudaspec/implementation.md
View File

@@ -6,24 +6,19 @@ tags: [openspec, implementation, multi-model, codex, gemini]
--- ---
<!-- GUDASPEC:START --> <!-- GUDASPEC:START -->
**Guardrails** **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. - 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. - 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. - 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** **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`; 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.
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. 3. When performing a specific coding task, refer to the code prototype provided by an effective model:
2. Run `/openspec:apply <proposal_id>`. - **Route A: Gemini Kernel** — `mcp__gemini__gemini` tool for frontend/UI/styling tasks (CSS, React, Vue, HTML, component design).
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. - **Route B: Codex Kernel** — `mcp__codex__codex` tool for backend/logic/algorithm tasks (API, data processing, business logic, debugging).
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).
- **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. - **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. 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.
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. 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**.
7. After completing the task, run **multi-model review** to verify. 6. MUST follow the `/opsx:apply <proposal_id>`.
8. After corrections are completed, mark the task item as `- [x]` in `tasks.md`.
9. Once all tasks are confirmed complete, run `/openspec:archive`.
<!-- GUDASPEC:END --> <!-- GUDASPEC:END -->

78
gudaspec/plan.md
View File

@@ -8,68 +8,48 @@ argument-hint: [proposal_id]
--- ---
<!-- GUDASPEC:START --> <!-- GUDASPEC:START -->
**Guardrails** **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**. - 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. - 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. - 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. - 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. - 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. - If constraints cannot be fully specified, escalate back to the user rather than making assumptions.
- Refer to `openspec/AGENTS.md` for additional conventions; run `openspec update` if the file is missing.
**Steps** **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. 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: 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>."
mcp__codex__codex: "Analyze proposal <proposal_id>: Provide implementation approach, identify technical risks, and suggest alternative architectures. Focus on edge cases and failure modes." - 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):
mcp__gemini__gemini: "Analyze proposal <proposal_id>: Evaluate from maintainability, scalability, and integration perspectives. Highlight potential conflicts with existing systems." - Information collection without decision boundaries (e.g., "JWT vs OAuth2 vs session—all viable")
``` - Technical comparisons without selection criteria
Synthesize responses and present consolidated options to the user for constraint selection. - 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.
4. **Multi-Model Uncertainty Elimination Audit**: Invoke both MCP tools to detect remaining ambiguities: 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.
```
mcp__codex__codex: "Review proposal <proposal_id> for decision points that remain unspecified. List each as: [AMBIGUITY] <description> → [REQUIRED CONSTRAINT] <what must be decided>."
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: 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>."
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>." - 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**:
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>." - **Commutativity/Associativity**: Order-independent operations
``` - **Idempotency**: Repeated operations yield same result
- **Round-trip**: Encode→Decode returns original
**PBT Property Categories to Extract**: - **Invariant Preservation**: State constraints maintained across operations
- **Commutativity/Associativity**: Order-independent operations - **Monotonicity**: Ordering guarantees (e.g., timestamps always increase)
- **Idempotency**: Repeated operations yield same result - **Bounds**: Value ranges, size limits, rate constraints
- **Round-trip**: Encode→Decode returns original - After modify the spec documents with the PBT, MUST run the command `openspec validate <proposal_id> --strict` to ensure the correct format.
- **Invariant Preservation**: State constraints maintained across operations
- **Monotonicity**: Ordering guarantees (e.g., timestamps always increase)
- **Bounds**: Value ranges, size limits, rate constraints
**Reference** 6. For complex proposals, consider running steps 2-4 iteratively on sub-components and remind the user rather than the entire proposal at once.
- 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.
**Exit Criteria** **Exit Criteria**
A proposal is ready to exit the Plan phase only when: A proposal is ready to exit the Plan phase only when:

21
gudaspec/research.md
View File

@@ -7,6 +7,7 @@ tags: [gudaspec, research, constraints, exploration, subagents]
<!-- GUDASPEC:RESEARCH:START --> <!-- GUDASPEC:RESEARCH:START -->
**Core Philosophy** **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. - 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. - Constraints tell subsequent stages "don't consider this direction," enabling mechanical execution without decisions.
- The output is "約束集合 + 可验证的成功判据" (constraint sets + verifiable success criteria). - The output is "約束集合 + 可验证的成功判据" (constraint sets + verifiable success criteria).
@@ -23,7 +24,7 @@ tags: [gudaspec, research, constraints, exploration, subagents]
**Steps** **Steps**
0. **Generate OpenSpec Proposal** 0. **Generate OpenSpec Proposal**
- Run `/openspec:proposal` - Run `/opsx:explore <user question>` always first.
1. **Initial Codebase Assessment** 1. **Initial Codebase Assessment**
- Combine user requirements with quick codebase scan using `mcp__auggie-mcp__codebase-retrieval`. - 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) * Subagent 3: Configuration & infrastructure (configs, deployments, build scripts)
- Each boundary should be self-contained: no cross-communication needed between subagents. - Each boundary should be self-contained: no cross-communication needed between subagents.
- Define exploration scope and expected output for each subagent. - 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** 3. **Prepare Standardized Output Template**
- Define a unified JSON schema that all Explore subagents must follow: - 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. - Update constraint sets with confirmed decisions.
7. **Generate OpenSpec Proposal** 7. **Generate OpenSpec Proposal**
- Run `/openspec:proposal <requirement-description>` to scaffold formal spec. - Run `/opsx:ff <requirement-description>` and follow it.
- Transform finalized constraint sets into requirements format. - 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.
- 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.
**Reference** **Reference**
- Review existing constraints: `rg -n "Constraint:|MUST|MUST NOT" openspec/specs`
- Inspect codebase structure: `ls -R` or `mcp__auggie-mcp__codebase-retrieval` - 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. - Validate subagent outputs conform to template before aggregation.
- Use `AskUserQuestions` for ANY ambiguity—do not assume or guess. - 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 --> <!-- GUDASPEC:RESEARCH:END -->