lanyuanxiaoyao/DiAL
1
0
Fork 0
Code Activity

chore: 清理过时 specs，新增 schemas 目录，更新审查提示词

Browse Source
This commit is contained in:
兰缘小妖
2026-05-23 22:24:08 +08:00
parent cfca03b4d6
commit 6601ab458d
37 changed files with 439 additions and 6135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

181
openspec/schemas/fast-drive/schema.yaml Normal file
View File

@@ -0,0 +1,181 @@
name: fast-drive
version: 1
description: Fast OpenSpec workflow - design -> tasks -> apply
artifacts:
- id: design
generates: design.md
description: Self-contained solution brief and execution plan
template: design.md
instruction: |
Create design.md as the self-contained source of truth for what will
change, why it is changing, and how the work will be executed.
This workflow does not use proposal or specs artifacts. design.md MUST
preserve the important outcomes from prior exploration and user
discussion so a later apply phase can proceed correctly even after
context compression or in a new session.
Write for someone who cannot see the earlier conversation. Keep simple
changes concise, but include enough detail to make execution
unambiguous. Add more detail when any apply:
- Cross-cutting change across multiple systems, teams, workstreams, or
artifacts
- New dependency, integration, vendor, tool, policy, or external input
- Significant information model, process model, data model, or ownership
changes
- Security, privacy, compliance, performance, operational, or migration
complexity
- Ambiguity that benefits from decisions before execution
- Prior discussion settled non-obvious requirements, constraints, or
rejected alternatives
Required sections:
- **Context**: Problem, current state, relevant references, and the user
request that triggered this change
- **Discussion Notes**: Key points from exploration or prior discussion
that must not be lost. Include agreed conclusions, user preferences,
constraints, and important rejected ideas.
- **Requirements**: Expected outcomes, behavior/process/interface/content
changes, continuity expectations, and acceptance criteria.
- **Goals / Non-Goals**: What this change will achieve and what is
explicitly out of scope.
- **Execution Guardrails**: Must-follow constraints, forbidden approaches,
preserved behavior/processes, dependency limits, and project- or
workflow-specific boundaries.
- **Affected Areas**: Concrete artifacts, references, stakeholders,
systems, workstreams, documents, configurations, assets, or handoffs that
are relevant to the change.
- **Decisions**: Key choices with rationale (why X over Y?). For each
important decision, include alternatives considered and why they were not
chosen.
- **Execution Plan**: Main workstreams or artifacts to change, integration
or handoff points, sequencing, and any rollout notes.
- **Verification Plan**: Validation checks, reviews, approvals,
acceptance checks, documentation checks, communication checks, and manual
checks needed to prove the change is complete.
- **Risks / Trade-offs**: Known limitations and things that could go
wrong.
Format: [Risk] -> Mitigation
- **Open Questions**: Outstanding decisions, assumptions, or unknowns to
resolve before execution. Separate blocking questions that must pause
apply from non-blocking follow-ups. Use "None" if there are no open
questions.
Optional sections when relevant:
- **Migration / Rollout Plan**: Rollout steps, communication, ownership,
rollback, or continuity strategy.
Focus on preserving requirements, rationale, constraints, and approach.
Avoid line-by-line or step-by-step details unless a detail is a deliberate
decision from the discussion.
Prefer durable summaries over chat transcripts. Use concrete artifact
names, data/information shapes, examples, stakeholders, ownership, and
edge cases when they affect execution.
Do not use task checkboxes in design.md; checkboxes belong only in
tasks.md.
Final design.md must not contain unresolved template comments, empty
table rows, or placeholder text.
If information is missing, state assumptions and open questions instead
of inventing hidden requirements. Do not rely on unstated chat context.
requires: []
- id: tasks
generates: tasks.md
description: Trackable execution checklist derived from design.md
template: tasks.md
instruction: |
Create tasks.md by breaking design.md into executable work.
**IMPORTANT: Follow the template below exactly.** The apply phase parses
checkbox format to track progress. Tasks not using `- [ ]` will not be
tracked.
Guidelines:
- Derive tasks from design.md. Do not depend on proposal.md or specs
artifacts; any relevant prior discussion must already be captured in
design.md.
- Group related tasks under `##` numbered headings
- Each task MUST be a single-line checkbox: `- [ ] X.Y Task description`
- Tasks should be small enough to complete in one session
- Order tasks by dependency (what must be done first?)
- Start with context review tasks when execution depends on guardrails,
affected areas, or open questions
- Include validation tasks for checks, reviews, approvals, acceptance,
documentation, communication, and manual checks when required
- Do not include repository, version-control, or release operation tasks
unless they are explicitly part of the change scope
- Final tasks.md must not contain unresolved template comments, empty
table rows, or placeholder task text
Example:
```
## 1. Context Review
- [ ] 1.1 Read design.md and identify scope, requirements, decisions, guardrails, and open questions
- [ ] 1.2 Review relevant artifacts and references listed in Affected Areas
## 2. Execution
- [ ] 2.1 Execute first concrete work item from design.md
- [ ] 2.2 Execute next concrete work item from design.md
## 3. Validation
- [ ] 3.1 Run required validation from Verification Plan
- [ ] 3.2 Perform quality checks required by the project or workflow
- [ ] 3.3 Perform required manual review or acceptance checks from Verification Plan
## 4. Documentation / Communication
- [ ] 4.1 Update relevant documentation, runbooks, communication materials, or project references if behavior, process, interface, configuration, or usage changed
```
Reference design.md for scope, requirements, decisions, execution
direction, and verification expectations.
Each task should be verifiable: it must be clear when the task is done.
requires:
- design
apply:
requires:
- design
- tasks
tracks: tasks.md
instruction: |
Read design.md first, then tasks.md.
Also follow workflow context/configuration, such as openspec/config.yaml when available, and any relevant project or workflow documentation referenced by design.md.
Treat design.md as the source of truth for scope, requirements, decisions, guardrails, execution direction, and verification expectations.
Work through pending tasks in dependency order and mark complete as you go.
Mark a task complete only after its execution and required verification are done.
Pause if tasks conflict with design.md, if design.md has blocking open questions, or if clarification is needed.

77
openspec/schemas/fast-drive/templates/design.md Normal file
View File

@@ -0,0 +1,77 @@
## Context
<!-- Problem, current state, relevant references, and triggering user request -->
## Discussion Notes
<!-- Key conclusions from exploration or prior discussion that apply must preserve -->
- Agreed conclusions:
- User preferences:
- Constraints:
- Rejected ideas:
## Requirements
<!-- Expected outcomes, behavior/process/interface/content changes, continuity expectations, and acceptance criteria -->
| Requirement | Acceptance Criteria |
| ----------- | ------------------- |
| | |
## Goals / Non-Goals
**Goals:**
<!-- What this design aims to achieve -->
**Non-Goals:**
<!-- What is explicitly out of scope -->
## Execution Guardrails
<!-- Must-follow constraints, forbidden approaches, preserved behavior/processes, dependency limits, and project- or workflow-specific boundaries -->
- Dependencies:
- Constraints:
- Quality Bar:
- Stakeholders:
- Documentation / Communication:
- Compatibility / Continuity:
## Affected Areas
<!-- Concrete artifacts, references, stakeholders, systems, workstreams, documents, configurations, assets, or handoffs relevant to this change -->
| Area | Artifacts / References | Expected Change | Notes |
| ---- | ---------------------- | --------------- | ----- |
| <!-- Area --> | <!-- Artifacts / References --> | <!-- Expected Change --> | <!-- Notes --> |
## Decisions
<!-- Key decisions, rationale, and alternatives considered -->
| Decision | Rationale | Alternatives Rejected |
| -------- | --------- | --------------------- |
| | | |
## Execution Plan
<!-- Main workstreams or artifacts to change, integration or handoff points, sequencing, and rollout notes -->
## Verification Plan
<!-- Validation checks, reviews, approvals, acceptance checks, documentation checks, communication checks, and manual checks needed -->
| Requirement / Risk | Verification |
| ------------------ | ------------ |
| | |
## Risks / Trade-offs
<!-- Format: [Risk] -> Mitigation -->
## Open Questions
| Status | Question | Decision Needed |
| ------ | -------- | --------------- |
| None | No open questions. | None |

19
openspec/schemas/fast-drive/templates/tasks.md Normal file
View File

@@ -0,0 +1,19 @@
## 1. Context Review
- [ ] 1.1 Read design.md and identify scope, requirements, decisions, guardrails, and open questions
- [ ] 1.2 Review relevant artifacts and references listed in Affected Areas
## 2. Execution
- [ ] 2.1 Execute first concrete work item from design.md
- [ ] 2.2 Execute next concrete work item from design.md
## 3. Validation
- [ ] 3.1 Run required validation from Verification Plan
- [ ] 3.2 Perform quality checks required by the project or workflow
- [ ] 3.3 Perform required manual review or acceptance checks from Verification Plan
## 4. Documentation / Communication
- [ ] 4.1 Update relevant documentation, runbooks, communication materials, or project references if behavior, process, interface, configuration, or usage changed