feat: add frontend development guidelines and structure documentation
- Introduced API guidelines for interface contracts and request handling. - Added design tokens usage guidelines for consistent styling across the project. - Established DTO guidelines for defining request parameters and response data types. - Created frontend structure guidelines to clarify directory organization and code placement rules. - Compiled a comprehensive frontend development guideline document covering various aspects of the development process. - Implemented quality guidelines to ensure code maintainability and adherence to best practices.
This commit is contained in:
yuxuanhui
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id: SKILLS-INDEX-AI-RD-WORKFLOW
|
||||
type: skills-index
|
||||
status: draft
|
||||
created: 2026-06-29
|
||||
---
|
||||
|
||||
# Skill 草稿
|
||||
|
||||
这里维护的是 skill 源草稿，用于长期打磨。稳定后再复制或安装到 `$CODEX_HOME/skills` 或 `~/.codex/skills`，让 Codex 自动发现。
|
||||
|
||||
## 当前 skill
|
||||
|
||||
- `pm-requirement-review`：PM 用户需求评审。
|
||||
- `pm-requirement-refine`：PM 用户需求细化。
|
||||
- `se-requirement-review`：SE 研发需求评审。
|
||||
- `se-requirement-analysis`：SE 研发需求分析。
|
||||
- `rd-design-generate`：RD 详细设计生成。
|
||||
- `test-case-generate`：测试计划和测试用例生成。
|
||||
|
||||
## 调优方式
|
||||
|
||||
1. 选择一个真实 case。
|
||||
2. 使用对应 skill 生成产物。
|
||||
3. 将失败点记录到 `60-evaluations/retrospectives/`。
|
||||
4. 更新 skill、模板或规范。
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: pm-requirement-refine
|
||||
description: Refine user-facing requirements from a PM perspective. Use when Codex needs to transform reviewed intake into traceable user requirement, requirement analysis, scenario analysis, user stories, acceptance criteria, and open questions.
|
||||
---
|
||||
|
||||
# PM Requirement Refine
|
||||
|
||||
Refine a reviewed intake into PM-side requirement artifacts.
|
||||
|
||||
## Inputs
|
||||
|
||||
- INTAKE.
|
||||
- PM review note.
|
||||
- Existing business context.
|
||||
|
||||
## Process
|
||||
|
||||
1. Write the user requirement in user-goal language.
|
||||
2. Extract business value, target users, constraints, and non-goals.
|
||||
3. Produce requirement analysis with assumptions, dependencies, and risks.
|
||||
4. Produce scenario analysis for main, alternative, exception, and boundary scenarios.
|
||||
5. Define acceptance criteria that can be verified later.
|
||||
6. Create traceability metadata for all generated artifacts.
|
||||
|
||||
## Output
|
||||
|
||||
Generate or update:
|
||||
|
||||
- UR.
|
||||
- RA.
|
||||
- SA.
|
||||
- Open question list.
|
||||
|
||||
## Quality Bar
|
||||
|
||||
- Each requirement has a clear user or business value.
|
||||
- Each scenario maps to at least one requirement.
|
||||
- Each acceptance criterion is observable.
|
||||
- Unknowns are not hidden inside polished prose.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: pm-requirement-review
|
||||
description: Review raw user or business requirements from a PM perspective. Use when Codex needs to assess whether an intake or user requirement is clear, valuable, scoped, testable, and ready for refinement into requirement analysis and scenario analysis.
|
||||
---
|
||||
|
||||
# PM Requirement Review
|
||||
|
||||
Review the input as a PM before refinement.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Intake document or raw user request.
|
||||
- Existing UR, RA, or SA if available.
|
||||
|
||||
## Process
|
||||
|
||||
1. Identify the target user, business goal, and triggering problem.
|
||||
2. Check whether the requested outcome is measurable.
|
||||
3. Separate in-scope, out-of-scope, and unknown items.
|
||||
4. Identify missing context, ambiguous terms, hidden assumptions, and decision points.
|
||||
5. Check whether acceptance direction can be verified.
|
||||
|
||||
## Output
|
||||
|
||||
Produce a review note with:
|
||||
|
||||
- Summary.
|
||||
- Confirmed facts.
|
||||
- Ambiguities.
|
||||
- Missing information.
|
||||
- Scope risks.
|
||||
- Scenario gaps.
|
||||
- Recommended next questions.
|
||||
- Gate decision: `pass`, `pass-with-questions`, or `rework`.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not invent business facts.
|
||||
- Mark assumptions explicitly.
|
||||
- Prefer concrete questions over broad advice.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: rd-design-generate
|
||||
description: Generate detailed design specifications from SE-produced OR and DR. Use when Codex needs to help an RD decompose engineering requirements into modules, APIs, data changes, state flows, error handling, implementation tasks, and test points for AI-assisted development.
|
||||
---
|
||||
|
||||
# RD Design Generate
|
||||
|
||||
Generate detailed design from OR and DR.
|
||||
|
||||
## Inputs
|
||||
|
||||
- OR.
|
||||
- DR.
|
||||
- Existing architecture or code context if available.
|
||||
|
||||
## Process
|
||||
|
||||
1. Identify affected modules and boundaries.
|
||||
2. Define proposed design, alternatives considered, and tradeoffs.
|
||||
3. Specify API, data model, state flow, permissions, error handling, observability, and compatibility changes.
|
||||
4. Split the design into implementation tasks.
|
||||
5. Add test points and regression impact.
|
||||
6. Preserve traceability from DS and TASK back to OR/DR.
|
||||
|
||||
## Output
|
||||
|
||||
Generate:
|
||||
|
||||
- DS.
|
||||
- TASK list.
|
||||
- Test point list.
|
||||
- Open technical questions.
|
||||
|
||||
## Quality Bar
|
||||
|
||||
- A developer or AI agent can implement each task without reinterpreting business intent.
|
||||
- Risky areas are marked explicitly.
|
||||
- Test points are connected to design decisions.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: se-requirement-analysis
|
||||
description: Create engineering-side objective requirements and development requirements from PM-side artifacts. Use when Codex needs to transform UR, requirement analysis, and scenario analysis into OR and DR with traceable functional, non-functional, interface, data, dependency, and risk requirements.
|
||||
---
|
||||
|
||||
# SE Requirement Analysis
|
||||
|
||||
Transform PM artifacts into engineering requirements.
|
||||
|
||||
## Inputs
|
||||
|
||||
- UR.
|
||||
- RA.
|
||||
- SA.
|
||||
- SE review note.
|
||||
|
||||
## Process
|
||||
|
||||
1. Create OR with engineering objective, delivery scope, success metrics, and constraints.
|
||||
2. Create DR with functional requirements, non-functional requirements, API/interface requirements, data requirements, dependencies, compatibility, rollout, and observability.
|
||||
3. Map each OR/DR item back to source IDs.
|
||||
4. Mark open questions and assumptions.
|
||||
5. Identify DS candidates for RD breakdown.
|
||||
|
||||
## Output
|
||||
|
||||
Generate:
|
||||
|
||||
- OR.
|
||||
- DR.
|
||||
- Traceability updates.
|
||||
|
||||
## Quality Bar
|
||||
|
||||
- Every critical UR has engineering coverage or an explicit exclusion.
|
||||
- DR items are specific enough for detailed design.
|
||||
- Risks and unknowns are visible.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: se-requirement-review
|
||||
description: Review PM-side requirement artifacts from an SE perspective. Use when Codex needs to evaluate whether UR, requirement analysis, and scenario analysis are ready to become engineering objective requirements and development requirements.
|
||||
---
|
||||
|
||||
# SE Requirement Review
|
||||
|
||||
Review PM artifacts for engineering readiness.
|
||||
|
||||
## Inputs
|
||||
|
||||
- UR.
|
||||
- RA.
|
||||
- SA.
|
||||
- PM open questions and review notes.
|
||||
|
||||
## Process
|
||||
|
||||
1. Check whether business requirements can be translated into engineering outcomes.
|
||||
2. Identify missing non-functional requirements.
|
||||
3. Identify interface, data, dependency, integration, permission, migration, and compatibility concerns.
|
||||
4. Identify architectural or delivery risks.
|
||||
5. Mark unresolved questions that block OR or DR.
|
||||
|
||||
## Output
|
||||
|
||||
Produce an SE review note with:
|
||||
|
||||
- Engineering readiness decision.
|
||||
- Blocking questions.
|
||||
- Required technical clarifications.
|
||||
- Risk list.
|
||||
- Suggested OR/DR breakdown.
|
||||
|
||||
## Decision
|
||||
|
||||
Use one of:
|
||||
|
||||
- `ready-for-or-dr`
|
||||
- `ready-with-risks`
|
||||
- `blocked`
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: test-case-generate
|
||||
description: Generate test plans and test cases from user requirements, engineering requirements, detailed design, and implementation tasks. Use when Codex needs to produce traceable positive, negative, boundary, regression, and risk-based tests.
|
||||
---
|
||||
|
||||
# Test Case Generate
|
||||
|
||||
Generate test artifacts from requirements and design.
|
||||
|
||||
## Inputs
|
||||
|
||||
- UR, RA, SA.
|
||||
- OR, DR.
|
||||
- DS and TASK.
|
||||
- Existing test conventions if available.
|
||||
|
||||
## Process
|
||||
|
||||
1. Identify test scope and non-scope.
|
||||
2. Build a test plan with strategy, environment, data, entry criteria, and exit criteria.
|
||||
3. Generate test cases for main, exception, boundary, permission, compatibility, and regression paths.
|
||||
4. Map each test case to source requirement or design IDs.
|
||||
5. Mark untestable or unclear requirements.
|
||||
|
||||
## Output
|
||||
|
||||
Generate:
|
||||
|
||||
- TP.
|
||||
- TC list.
|
||||
- Coverage gaps.
|
||||
- Risk-based regression suggestions.
|
||||
|
||||
## Quality Bar
|
||||
|
||||
- Each critical requirement has coverage.
|
||||
- Expected results are concrete.
|
||||
- Test data and preconditions are explicit.
|
||||
Reference in New Issue
Block a user