feature-prompt-full
Original:🇺🇸 English
Translated
Use when the user wants a full feature-development chain: clarify a rough feature idea into a prompt, review it with the user, then hand it to grill-with-docs, to-prd, to-issues, and tdd.
2installs
Added on
NPX Install
npx skill4agent add devarfeen/agent-skills-kit feature-prompt-fullTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →Feature Prompt Full
Turn rough feature requests into an implementation-ready prompt and prepare the downstream feature chain.
This is the full variant of . It keeps the same section-by-section clarification flow, then directs the user through:
feature-prompt/grill-with-docs/to-prd/to-issues/tdd
Chain Approval
Before asking feature questions, show the chain suggestion and get user approval.
Use this exact shape:
markdown
Suggested chain:
1. `/feature-prompt-full` - clarify the feature and produce the final prompt.
2. `/grill-with-docs` - challenge the prompt against docs, domain language, ADRs, and codebase context.
3. `/to-prd` - convert the reviewed context into a PRD/spec.
4. `/to-issues` - split the PRD into independently implementable vertical slices.
5. `/tdd` - implement each issue with red-green-refactor.
Approve this chain before I start, or tell me what to change.Do not begin the section interview until the user approves the chain.
Agent Use
When the active agent runtime supports sub-agents and the user has allowed them, use read-only explorer agents where they can improve the prompt without slowing the interview.
- Use multiple explorer agents in parallel for independent codebase questions, especially multi-project mapping, integration points, existing patterns, constraints, risks, and acceptance evidence.
- Keep the main session responsible for user questions, judgment, and the final prompt.
- Do not delegate the final prompt to a sub-agent.
- Do not use worker agents or make code edits.
- Treat explorer results as supporting evidence; ask the user to confirm product intent before locking a section.
Input Sections
Ask for these sections in order.
Do not ask all questions at once.
markdown
Projects:
[Project Code], [Project Code]
Need:
[What needs to be built or changed.]
Integration:
[Where this connects: codebase, workflow, API, UI, DB, jobs, services.]
Reason:
[Why this is needed. What problem it solves.]
Constraints:
[Limits, exclusions, technical rules, compatibility needs, or "none".]
Acceptance:
[Optional. User may skip. If skipped, infer from Need + Integration + Reason.]Rules
- Ask one section at a time.
- Do not generate the final prompt until required sections are answered.
- Required sections: ,
Projects,Need,Integration,Reason.Constraints - Optional section: .
Acceptance - If the user skips , infer it and mark it as inferred.
Acceptance - If an answer is vague, ask one sharp follow-up before moving on.
- For every question, include 4 pre-made answer options plus 1 custom option.
- If codebase inspection can answer or improve a section, inspect code first, then ask the user to confirm.
- Preserve the user's section order in final output.
- Do not add extra sections unless the user asks.
- Do not implement the feature.
- Do not create the PRD, issues, or TDD implementation inside this skill.
Grilling Behavior
For each section:
- Ask one focused question.
- Explain what a strong answer includes.
- Provide exactly 4 pre-made options plus 1 custom option.
- Wait for the user response.
- Challenge vague, conflicting, or incomplete answers.
- Move to the next section only when clear enough.
Question Option Format
For each section question, show options in this exact pattern:
markdown
Options:
1. [Specific pre-made answer]
2. [Specific pre-made answer]
3. [Specific pre-made answer]
4. [Specific pre-made answer]
5. Custom: [Tell me your own answer]
Reply with a number, or write custom text.Option rules:
- The 4 pre-made options must be tailored to the current section and any known project context.
- Mark one option as when there is enough context to recommend it.
(recommended) - Keep each option short enough to select or edit quickly.
- The custom option must always be present.
- Always include the line:
Reply with a number, or write custom text. - Accept an option number, edited option text, or fully custom text as the answer.
- If codebase inspection produced likely answers, use those findings to shape the options.
Draft Review
After all sections are resolved:
- Draft the generated prompt using the resolved sections.
- Pass that draft to the user for review and feedback.
- Apply valid user feedback without adding new sections.
- Produce the revised final prompt plus the next command chain.
Final Output
After user review, produce only this:
markdown
Projects:
[Resolved project codes]
Need:
[Precise feature/change request]
Integration:
[Specific integration points]
Reason:
[Clear problem/value]
Constraints:
[Explicit limits or "none"]
Acceptance:
[User-provided or inferred acceptance criteria]
Next:
1. Pass this final prompt to `/grill-with-docs`.
2. After the grill is resolved, run `/to-prd`.
3. After the PRD is approved, run `/to-issues`.
4. Implement approved issues with `/tdd`.Keep the final prompt spartan. No preface. No filler.