Development Task Planning

VerifiedSafe

Skill for planning development tasks using a checklist and template. It guides impact tier assessment, decomposes work into independently testable units, and formats the plan output. Helpful for structuring work before coding.

Sby Skills Guide Bot
DevelopmentIntermediate
606/2/2026
Claude CodeCursorWindsurfCopilotCodex
#planning#tier-judgment#task-decomposition#checklist

Recommended for

Our review

This skill provides a structured framework for planning development tasks by assessing complexity tier and decomposing work into testable units.

Strengths

  • Step-by-step guidance with questions to evaluate impact and tier (S/M/L).
  • Template for decomposing work into independent, testable tasks.
  • Clear output format for presenting the plan to the user.

Limitations

  • Requires the user to provide sufficient information about the task.
  • Can be too generic for very specific projects.
  • Does not handle complex dependencies across teams or services.
When to use it

Use this skill at the beginning of a new feature or refactoring to get a structured plan.

When not to use it

Avoid for trivial changes (single file, no impact) where detailed planning is unnecessary.

Security analysis

Safe
Quality score80/100

This skill is a planning template with no executable instructions, dangerous commands, or data exfiltration risks. It only provides a checklist and output format for task decomposition.

No concerns found

Examples

Plan a new feature
I need to add a search feature to our product catalog. Please use the planning skill to assess the tier, decompose the work, and provide a plan.
Refactoring plan
We need to refactor the user authentication module to use OAuth2. Plan the work using the tier judgment and task decomposition templates.

Planning Skill

작업 계획 수립 시 참조하는 체크리스트와 템플릿.


1. 티어 판단

다음 질문에 순서대로 답하라:

  1. 변경 영향도: 핵심 도메인 로직이 바뀌는가? → Yes면 L
  2. 레이어 횡단: FE + BE 동시 변경인가? → 영향도에 따라 M 또는 L
  3. 설계 결정: 새로운 아키텍처/패턴 도입이 필요한가? → Yes면 L
  4. 위 모두 No: 파일 수와 변경 단순성으로 S/M 판단

2. 작업 분해 템플릿

요구사항 정리

  • [ ] 사용자가 원하는 최종 결과물은?
  • [ ] 변경되는 레이어는? (UI / API / Domain / DB)
  • [ ] 기존 코드에 영향을 주는 범위는?

작업 단위 분해

각 작업 단위는 독립적으로 테스트 가능한 단위로 나눈다:

1. [작업명] - [대상 파일/모듈] - [티어]
2. [작업명] - [대상 파일/모듈] - [티어]

의존성 확인

  • [ ] 작업 간 순서 의존성이 있는가? (예: BE API 먼저 → FE 연동)
  • [ ] 외부 의존성이 있는가? (패키지 설치, DB 마이그레이션 등)

3. 계획 출력 형식

사용자에게 계획을 제시할 때 다음 형식을 따른다:

**티어**: S / M / L
**변경 범위**: [레이어 목록]
**작업 목록**:
1. [작업] → [담당 에이전트]
2. [작업] → [담당 에이전트]
Related skills