# Tech Spec Planning

> Helps Codex turn an agreed feature description into a practical build plan. Use it when the team already knows what should be built and now needs to decide how to build it, what files are involved, what risks exist, and how to test the work. Trigger on requests like: "сделай техспек", "technical spec", "implementation plan", "architecture for this feature", "разложи как делать".

- Skill: `aggel008/tech-spec-planning` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add aggel008/tech-spec-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aggel008/tech-spec-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: aggel008 (https://skillmd.com/u/aggel008)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/aggel008/tech-spec-planning

---


# Tech Spec Planning

This skill creates the technical plan that sits between idea and coding.

Use it when:

- the feature is approved but implementation is not planned yet
- you need architecture decisions before coding
- a task is too big to start coding blindly
- you want a clean breakdown of files, risks, and tests

Main benefit:

- lowers random coding
- exposes missing decisions early
- gives execution a clear technical path

## Output

Default output:

- `work/<feature>/tech-spec.md`

For the recommended structure, read [template.md](references/template.md).

## Inputs

Read:

- `work/<feature>/user-spec.md`
- relevant files from `docs/project_knowledge/`
- the code that will actually be affected

## Workflow

1. Confirm the feature scope from `user-spec.md`.
2. Research the relevant code paths, configs, and integrations.
3. Identify technical decisions and constraints.
4. Produce a technical spec that covers:
   - solution shape
   - architecture changes
   - dependencies
   - testing strategy
   - risks
   - implementation tasks by waves
5. Keep all implementation tasks brief and outcome-focused.

## Rules

- Every major decision should trace back to a user requirement or be marked as purely technical.
- Flag any deviation from user intent explicitly.
- Keep task descriptions short; detailed execution belongs later.
- Prefer real file paths and real integration points over invented abstractions.
- If the plan becomes too large, propose MVP and extension phases.

## Validation Mindset

Before presenting the tech spec, self-check:

- does it match the user spec
- does it match the actual codebase
- does the testing depth fit the feature size
- are there obvious missing dependencies or fake references