AgentSkillsCN

technical-planning

当您需要产出可执行的技术方案,同时细化任务分解并建立验证矩阵时,此技能将在完成背景调研之后、实施之前,为您提供有力支持。

SKILL.md
--- frontmatter
name: technical-planning
description: Use when producing implementable technical plans with task breakdown and verification matrix. After context gathering, before implementation.

Technical Planning

Produce a precise, implementable technical plan. Do NOT write implementation code.

Inputs

  • Tech vision docs ({ide-folder}/{outputFolder}/tech/vision/...)
  • PRD ({ide-folder}/{outputFolder}/product/prd/{epicNumber}-EPIC-{epicName}/US-{usName}-{usNumber}.md)
  • Technical context ({ide-folder}/{outputFolder}/task/.../technical-context.md)

Output

{ide-folder}/{outputFolder}/task/{epicNumber}-EPIC-{epicName}/US-{usName}-{usNumber}/technical-plan.md

Required Structure

Front matter

yaml
Epic ID: EPIC-{epicNumber}
User Story ID: US-{usNumber}
Document: Technical Plan
Status: Draft | Ready
Owner: AI Architect (Plan)
Last Updated: (ISO timestamp)
Inputs: (list exact paths)

Sections

#SectionContent
1Scope & Non-ScopeAC-* addressed, explicitly not done
2Proposed designComponents, boundary rules, key flows
3Contracts & interfacesTypes, signatures, APIs, error semantics
3.1Data Transformation LayerMANDATORY for calculation stories - raw→normalized mapping table
4Data & multi-tenancyTenant scoping, migration/rollback
5Security constraintsAuthN/Z, input validation, sensitive data, rate limiting
6ObservabilityLogging, metrics, failure modes, tracking events
7Task breakdownPR-sized tasks with TASK-* IDs
8Verification MatrixMANDATORY - AC-* → tests/checks mapping
9Editor BriefStep-by-step order, DoD checklist, commands
10Open questionsIf blocking, list with defaults

Task Breakdown Format

markdown
- `TASK-01` Title
  - Description
  - Files/packages impacted
  - AC covered (`AC-*`)
  - Notes/pitfalls

Verification Matrix

Every AC-* must have at least one verification:

  • Unit tests (file path)
  • Integration tests (file path)
  • E2E Playwright (file path)
  • Static checks

Guardrails

  • Do not write code
  • Do not invent requirements not in PRD
  • If story too large, recommend splitting with boundaries
  • Default to simplicity
  • All switches in domain logic must be exhaustive—use assertNever
  • Never use ambiguous field names—prefer packagePriceCents over priceCents
  • Run /sync-issue after writing