菜单
Guide iterative authoring of functional specifications as Azure DevOps work item hierarchies (Epic → Feature → User Story). Use for business requirement capture, scope definition, acceptance criteria, and approval readiness.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Design ASP.NET Core minimal API request and response contracts. Use for DTO shapes, route and verb decisions, OpenAPI metadata, and compatibility planning before implementation.
Define focused tests for ASP.NET Core minimal APIs. Use for endpoint branch coverage, contract assertions, regression planning, and choosing the narrowest useful verification command.
Design EF Core schema changes, constraints, and migrations for the backend data model. Use for entity updates, indexes, uniqueness rules, cascade behavior, and migration planning.
Design and implement the delegated Graph sync pipeline from fetch through normalization, upsert, and metrics recompute. Use for user-initiated registrations or attendance sync, idempotency, and atomic recomputation.
Define deployment safeguards, environment protections, and rollback readiness for CI/CD releases. Use when adding or reviewing release jobs, promotion controls, or recovery plans.
Apply email and domain normalization plus session and series metric rules, including W1/W2 warm-account logic and internal-domain exclusion. Use for domain logic changes, recompute behavior, and mandatory unit-test coverage.
| name | functional-spec-authoring |
| description | Guide iterative authoring of functional specifications as Azure DevOps work item hierarchies (Epic → Feature → User Story). Use for business requirement capture, scope definition, acceptance criteria, and approval readiness. |
| argument-hint | Describe the business need or feature idea to explore, or provide an existing Epic ID to refine. |
The calling agent must provide the Azure DevOps organization, project, and any other target-specific values needed for MCP calls. This skill defines generic field, template, and workflow rules only; do not hardcode repository-specific Azure DevOps targets here.
| Level | Purpose | Azure DevOps type |
|---|---|---|
| Epic | WHY — business justification, strategic goal | Epic |
| Feature | WHAT — capability scope, boundaries | Feature (child of Epic) |
| User Story | WHAT — user-facing behavior, criteria | User Story (child of Feature) |
Tasks/Bugs are implementation, not functional spec.
| Type | Description field | Acceptance Criteria field |
|---|---|---|
| Epic | business justification, success criteria, scope, stakeholders, constraints | not used |
| Feature | capability, value, scope, dependencies, embedded acceptance criteria | not used |
| User Story | story statement, UI/UX notes, data rules, edge cases | Given/When/Then (Microsoft.VSTS.Common.AcceptanceCriteria) |
Description = HTML. Comments/wiki = markdown.
| Artifact | Format | Path |
|---|---|---|
| Epic Description | HTML | .github\skills\functional-spec-authoring\templates\epic-description.html |
| Feature Description | HTML | .github\skills\functional-spec-authoring\templates\feature-description.html |
| User Story Description | HTML | .github\skills\functional-spec-authoring\templates\user-story-description.html |
| User Story AC | plain text | .github\skills\functional-spec-authoring\templates\user-story-acceptance-criteria.txt |
Rules: load template before generating; preserve section headings/order; reject output with unresolved placeholders; if template conflicts with field model, STOP and ask.
State model, tags, transitions → see spec-lifecycle-management skill.
Key principle: create NO Azure DevOps items until user approves Phase 4 preview.
| Phase | Action | Create items? |
|---|---|---|
| 1 Discovery | Gather need; draft Epic in-chat per template | No |
| 2 Feature Decomposition | Identify capabilities; draft Features; confirm boundaries | No |
| 3 Story Definition | Decompose into stories + G/W/T; confirm clarity | No |
| 4 Preview + Approval | Show full hierarchy; on approval create Epic → Features → Stories in New | Yes |
| 5 Review Readiness | Verify all fields populated; add review:ready to Epic | — |
| 6 Approval | On stakeholder sign-off: remove review:ready, move Epic+children New → Active, add approval comment | — |
Preview format:
**Epic**: [Title]
[1–2 sentence summary]
**Feature 1**: [Title] — [scope]
- User Story 1.1: [Title] — G/W/T summary
Approval comment: .github\skills\spec-lifecycle-management\templates\approval-comment.md. Approval unlocks tech spec generation.
| Change | Action |
|---|---|
| Refine Story | Update Description/AC + comment reason |
| Split Story | New child Stories; mark original removed or cross-reference |
| Add Feature | Create child of Epic + its Stories |
| Remove Feature | State → Removed + comment |
| Post-approval scope change | Move affected items to New, drop review:ready, add techspec:stale if tech spec exists |
[TODO]/[TBD]/empty sectionsNew+review:ready OR Active+approval comment