project-planning

Name: project-planning
Author: pavel-molyanov

241stars75forks

How to install project-planning?

pavel-molyanov/molyanov-ai-dev/project-planning

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill project-planning

Installs into the current project.

Summary

Plan new projects: adaptive interview, tech decisions, fill all project documentation (project-knowledge) in one session. Use when: "сделай описание проекта", "запиши описание проекта в документацию", "проведи со мной интервью для описания проекта", "заполни документацию проекта"

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Project Planning
4
5	Conduct adaptive interview → make tech decisions → fill all project documentation in one session.
6
7	## Project Documentation Autosync
8
9	Project documentation source of truth is Claude-side: `CLAUDE.md` and `.claude/**`.
10	Codex-side `AGENTS.md` and `.codex/**` are generated runtime files.
11
12	After changing any project-local `.claude/**` file, immediately run:
13
14	```bash
15	~/.claude/scripts/sync-to-codex.sh --project "$PWD" --apply
16	```
17
18	If sync reports a conflict, stop and report it. Include generated `.codex/` changes in the same commit as the `.claude/` source change.
19
20	## Output Files
21
22	Project Knowledge (`.claude/skills/project-knowledge/references/`):
23	- project.md — overview, audience, problem, key features, scope
24	- architecture.md — tech stack, project structure, dependencies, data model
25	- patterns.md — git workflow (code patterns, testing, business rules are filled later during development)
26	- deployment.md — platform, environment, CI/CD, monitoring
27	- ux-guidelines.md — only if project has significant UI
28
29	## Interview Methodology
30
31	One question at a time. Ask one question, wait for the answer, then form the next question based on the response.
32
33	Build on answers. If user mentioned a domain — ask domain-relevant follow-ups. If they said something vague — clarify that specific point.
34
35	Confirm understanding. After 3-5 questions, briefly summarize what you understood. Catches misunderstandings early.
36
37	Help when stuck. When user says "not sure" or "don't know":
38	1. Say it's OK
39	2. Offer 2-3 common approaches for their type of project
40	3. Ask which is closer
41	4. If still uncertain and optional — mark TBD, move on
42	5. If still uncertain and required — break into simpler sub-questions
43
44	Recount on scope changes. If user suddenly adds many features or reveals unexpected complexity — stop and recount total scope. Show the updated list, confirm you understood correctly.
45
46	If code exists. Scan the codebase in parallel with the interview to pre-fill technical decisions and ask more targeted questions.
47
48	## Phase 1: Project Discovery
49
50	### 1.1 Interview
51
52	Verify that project-knowledge directory and CLAUDE.md exist. If missing — tell user to run `/init-project` first.
53
54	Ask user to describe the project in free form. Let them say as much or as little as they want.
55
56	Then ask adaptive questions to cover three areas:
57
58	Project Overview:
59	- What the project does (one-line + context)
60	- Who uses it and why (target audience + use case)
61	- What problem it solves (core pain point)
62	- 3-5 key features (high-level only)
63	- Scope boundaries (explicit exclusions)
64
65	Features & MVP:
66	- Key features with descriptions
67	- What's included in MVP (launch scope)
68	- What comes later (post-launch ideas) — note these for the backlog
69	- Priority for each: Critical / Important / Nice-to-have
70
71	Development Approach:
72	- All at once or phased?
73	- If phased: how to group features, what's MVP
74	- If migration: current system, data migration, risks, rollback plan
75
76	### 1.2 Checkpoint
77
78	Move to Phase 2 when you can:
79	- Write a clear, non-vague project.md
80	- List key features with priorities and MVP scope
81	- Describe the development approach
82
83	TBD is acceptable for optional aspects.
84
85	## Phase 2: Technical Decisions
86
87	### 2.1 New Project (no code)
88
89	1. Propose tech stack based on Phase 1: frontend, backend, database, key dependencies
90	2. Verify choices against current docs (Context7 if available). Update if you find deprecations or better alternatives.
91	3. Propose deployment: platform, CI/CD approach, environments
92	4. Present proposal to user with rationale for each choice. Iterate until user approves.
93
94	### 2.2 Existing Code
95
96	1. Extract stack from the codebase: package files, configs, directory structure
97	2. Verify against current docs (Context7 if available)
98	3. Confirm with user: show what you found, ask about gaps (deployment, missing pieces)
99	4. Iterate until confirmed.
100
101	### 2.3 Checkpoint
102
103	Move to Phase 3 when:
104	- Tech stack (frontend, backend, database, key dependencies) approved by user
105	- Deployment platform and CI/CD approach agreed
106	- No open questions on technical choices
107
108	## Phase 3: Fill Documentation
109
110	Documentation goal: someone opens these files and understands the project without reading code. Describe what exists, what it does, and why. Record decisions, operational details (server addresses, deploy procedures, log locations), high-level component overview. Write in prose, link to so

People who liked this also viewed

6 picks

Type

project-planning

241stars75forks

View on GitHub

How to install project-planning?

pavel-molyanov/molyanov-ai-dev/project-planning

$npx -y skills add pavel-molyanov/molyanov-ai-dev --skill project-planning

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- Generated by sync-to-codex v1. Do not edit directly. -->
2
3	# Project Planning
4
5	Conduct adaptive interview → make tech decisions → fill all project documentation in one session.
6
7	## Project Documentation Autosync
8
9	Project documentation source of truth is Claude-side: `CLAUDE.md` and `.claude/**`.
10	Codex-side `AGENTS.md` and `.codex/**` are generated runtime files.
11
12	After changing any project-local `.claude/**` file, immediately run:
13
14	```bash
15	~/.claude/scripts/sync-to-codex.sh --project "$PWD" --apply
16	```
17
18	If sync reports a conflict, stop and report it. Include generated `.codex/` changes in the same commit as the `.claude/` source change.
19
20	## Output Files
21
22	Project Knowledge (`.claude/skills/project-knowledge/references/`):
23	- project.md — overview, audience, problem, key features, scope
24	- architecture.md — tech stack, project structure, dependencies, data model
25	- patterns.md — git workflow (code patterns, testing, business rules are filled later during development)
26	- deployment.md — platform, environment, CI/CD, monitoring
27	- ux-guidelines.md — only if project has significant UI
28
29	## Interview Methodology
30
31	One question at a time. Ask one question, wait for the answer, then form the next question based on the response.
32
33	Build on answers. If user mentioned a domain — ask domain-relevant follow-ups. If they said something vague — clarify that specific point.
34
35	Confirm understanding. After 3-5 questions, briefly summarize what you understood. Catches misunderstandings early.
36
37	Help when stuck. When user says "not sure" or "don't know":
38	1. Say it's OK
39	2. Offer 2-3 common approaches for their type of project
40	3. Ask which is closer
41	4. If still uncertain and optional — mark TBD, move on
42	5. If still uncertain and required — break into simpler sub-questions
43
44	Recount on scope changes. If user suddenly adds many features or reveals unexpected complexity — stop and recount total scope. Show the updated list, confirm you understood correctly.
45
46	If code exists. Scan the codebase in parallel with the interview to pre-fill technical decisions and ask more targeted questions.
47
48	## Phase 1: Project Discovery
49
50	### 1.1 Interview
51
52	Verify that project-knowledge directory and CLAUDE.md exist. If missing — tell user to run `/init-project` first.
53
54	Ask user to describe the project in free form. Let them say as much or as little as they want.
55
56	Then ask adaptive questions to cover three areas:
57
58	Project Overview:
59	- What the project does (one-line + context)
60	- Who uses it and why (target audience + use case)
61	- What problem it solves (core pain point)
62	- 3-5 key features (high-level only)
63	- Scope boundaries (explicit exclusions)
64
65	Features & MVP:
66	- Key features with descriptions
67	- What's included in MVP (launch scope)
68	- What comes later (post-launch ideas) — note these for the backlog
69	- Priority for each: Critical / Important / Nice-to-have
70
71	Development Approach:
72	- All at once or phased?
73	- If phased: how to group features, what's MVP
74	- If migration: current system, data migration, risks, rollback plan
75
76	### 1.2 Checkpoint
77
78	Move to Phase 2 when you can:
79	- Write a clear, non-vague project.md
80	- List key features with priorities and MVP scope
81	- Describe the development approach
82
83	TBD is acceptable for optional aspects.
84
85	## Phase 2: Technical Decisions
86
87	### 2.1 New Project (no code)
88
89	1. Propose tech stack based on Phase 1: frontend, backend, database, key dependencies
90	2. Verify choices against current docs (Context7 if available). Update if you find deprecations or better alternatives.
91	3. Propose deployment: platform, CI/CD approach, environments
92	4. Present proposal to user with rationale for each choice. Iterate until user approves.
93
94	### 2.2 Existing Code
95
96	1. Extract stack from the codebase: package files, configs, directory structure
97	2. Verify against current docs (Context7 if available)
98	3. Confirm with user: show what you found, ask about gaps (deployment, missing pieces)
99	4. Iterate until confirmed.
100
101	### 2.3 Checkpoint
102
103	Move to Phase 3 when:
104	- Tech stack (frontend, backend, database, key dependencies) approved by user
105	- Deployment platform and CI/CD approach agreed
106	- No open questions on technical choices
107
108	## Phase 3: Fill Documentation
109
110	Documentation goal: someone opens these files and understands the project without reading code. Describe what exists, what it does, and why. Record decisions, operational details (server addresses, deploy procedures, log locations), high-level component overview. Write in prose, link to so

People who liked this also viewed

6 picks

Type