메뉴
Guide new feature development from idea to build-ready plan: structured summary → multiple-choice questions → PLAN.md collaboration → handoff to plan and subagent-driven-development skills.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | feature-intake-and-plan |
| description | Guide new feature development from idea to build-ready plan: structured summary → multiple-choice questions → PLAN.md collaboration → handoff to plan and subagent-driven-development skills. |
| version | 1.0.0 |
| author | psam-717 |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["planning","feature","intake","workflow","design","brainstorm"],"related_skills":["plan","subagent-driven-development","test-driven-development","writing-plans"]}} |
This skill encodes the process used for the psamvault-mCP hackathon features: a structured, question-driven approach to turning a feature idea into a build-ready PLAN.md.
It covers two phases before any code is written:
Then hands off to plan and subagent-driven-development for execution.
Do not use for:
systematic-debugging)writing-plans)When the user proposes a feature idea:
Create a PLAN.md at the project root (or hackathon/PLAN.md if the project has one):
# [Feature Name]
**Status:** 🟡 EXPLORING
**Proposed by:** User
**Date:** YYYY-MM-DD
---
## Summary
[A 3-5 sentence description. What it does, why it's needed, who it's for.]
## Key Points
1. **Point A:** [One sentence]
2. **Point B:** [One sentence]
3. **Point C:** [One sentence]
## Key Decisions Needed
### Decision 1: [Title]
**Context:** [2-3 sentences explaining the trade-off]
| # | Option | Pros | Cons |
|---|--------|------|------|
| 1 | **[Option A]** | [Key pro] | [Key con] |
| 2 | **[Option B]** | [Key pro] | [Key con] |
| 3 | **[Option C]** | [Key pro] | [Key con] |
## Open Questions
- [ ] Question 1?
- [ ] Question 2?
Structure each choice with what it is, when it makes sense, and the trade-off:
**Decision: Storage approach**
Where should the data live?
1. **In-memory** — Simplest, never persists. ✓ Fast to build ✗ Lost on restart
2. **SQLite** — Persistent, zero setup. ✓ Simple ✗ Won't scale horizontally
3. **PostgreSQL** — Production-grade. ✓ Scalable ✗ Requires a database server
Which approach fits best?
"These are the key design decisions I see. You can:
- Pick an option for any decision
- Ask me questions about the trade-offs
- Suggest a different approach I hadn't considered
What would you like to start with?"
Every time a decision is made or the scope changes, update PLAN.md:
## Decisions Made
| Decision | Choice | Rationale |
|----------|--------|-----------|
| Storage | SQLite | No need for server, data must persist |
## Open Questions
- [x] ~~Storage approach?~~ → SQLite
- [ ] Auth method?
Use patch for targeted edits rather than rewriting the whole file each time.
## Build Order
| Step | Feature | Depends On | Est. Time | Status |
|------|---------|-----------|-----------|--------|
| 1 | [Smallest unit] | Nothing | X hours | 🔴 |
| 2 | [Next step] | Step 1 | X hours | 🔴 |
| ... | ... | ... | ... | ... |
## Files Likely to Change
- `src/path/to/new_file.py` — [What it does]
- `src/path/to/existing.py` — [What changes]
- `tests/path/to/test.py` — [New tests]
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
## Risks & Mitigations
- [Risk 1] — [Mitigation]
- [Risk 2] — [Mitigation]
"The plan is ready. Want me to:
1. **Build it now** — Follow the plan step by step
2. **Save it** — You review first, we build later
3. **Refine** — Anything to change in the plan?
"
When confirmed, load and follow:
plan — For detailed task-level implementation planssubagent-driven-development — For executing tasks with TDD + 2-stage reviewtest-driven-development — For the TDD cycle within each taskMaintain CHANGELOG.unreleased.md in psamvault-cli. When the user opens a PR with code changes, read the PR diff, write entries to the unreleased file, and open a separate PR for the changelog update so it merges cleanly alongside the code changes.
Publishes Python projects to TestPyPI and PyPI, then creates a GitHub version release. Use this skill when the user wants to publish, release, or ship a Python package, or asks to bump a version and push to PyPI. Requires a pyproject.toml in the project. Workflow: build -> TestPyPI -> user tests locally -> PyPI + GitHub release. Before the version bump, loads the granular-commits-pr skill to commit codebase changes individually. Also covers the post-release backup of the py-publish skill itself to the skills backup repo at C:\Users\USER\.copilot\skills (github.com/psam-717/skills).
Scans the current git repo for all untracked and modified files, examines their contents/diffs, generates meaningful commit messages, presents them to the user for verification, then stages and commits each file individually. After committing, optionally creates a new branch and opens a PR for major updates (seeks user approval first). Supports both interactive mode (user-confirmation required) and cron/ automated mode (no interaction, commits autonomously). Trigger phrases: "stage and commit", "commit my changes", "commit all files", "git commit", "commit my modified files", "create a commit message", "auto-commit cron job". Works on Windows (git-bash/PowerShell) and POSIX.
Commit each changed file individually with conventional commit messages, create a new feature branch, push, and open a PR. Used when the user wants fine-grained, file-level commits rather than squashing everything into one.
Performs a thorough, beginner-friendly breakdown of the entire current project. Reads every file in the codebase and produces an extensive explanation of what the project is, how it is structured, how data flows through it, and what every major piece of code does. Use this skill when asked to explain a project, walk through a codebase, give an overview of how something works, or onboard onto an unfamiliar repo.
Performs a thorough codebase review and debugging session. Scans all source files for bugs, security issues, logic errors, and code quality problems. Presents a full bug report to the user and waits for approval before making any changes. After approval, fixes only the approved bugs, then delivers a summary of every change made and a description of the application's current workflow. Use this skill when asked to review code, debug the codebase, find bugs, or audit code quality.