Feature Prompt
Turn a rough feature or change request into a minimal grill-with-docs prompt before any implementation spec exists.
Overview
Feature Prompt is an agent skill most often used in Validate (also Build planning handoffs) that turns a rough feature request into a minimal grill-with-docs prompt.
Install
npx skills add https://github.com/devarfeen/agent-skills-kit --skill feature-promptWhat is this skill?
- Fixed output contract with Project, What/Why/Expected end result plus optional Known limits and Open questions
- Explicitly not an implementation spec—smallest handoff for grill-with-docs to challenge and sharpen
- Cheap repo exploration can surface stale or missing CONTEXT.md domain terms for user approval first
- grill-with-docs next step handles ADRs, code/docs inspection, and CONTEXT.md updates
- 6 prompt sections in the output contract (4 required, 2 conditional)
Adoption & trust: 1 installs on skills.sh; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You have a feature idea or change request but no crisp, repo-aware brief for the agent that will challenge the plan next.
Who is it for?
Solo builders starting a feature who already use grill-with-docs or CONTEXT.md-driven workflows in the repo.
Skip if: Teams that already have an approved implementation spec or want the skill to write code, tasks, or ADRs directly.
When should I use this skill?
User wants to turn a feature idea, change request, or rough requirement into a small prompt for grill-with-docs, or when repo exploration reveals stale CONTEXT.md terms.
What do I get? / Deliverables
You get a small structured prompt ready for grill-with-docs, with optional domain-term candidates flagged for approval before CONTEXT.md changes.
- Markdown prompt block for grill-with-docs
- Candidate domain terms list for user approval when exploration finds gaps
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the skill’s job is shaping scope and handoff before build—not shipping code. Scope fits turning ideas into structured requirements, pain, done-state, and open questions without writing the spec itself.
Where it fits
Convert a slack-style feature note into What/Why/Expected end result before grill-with-docs tears apart assumptions.
Define observable demo flow and open questions before a spike without writing tasks.
Hand a mid-sprint change request to grill-with-docs with known limits already captured.
How it compares
Use instead of pasting a vague feature ask into chat when your next step is structured doc grilling, not immediate implementation.
Common Questions / FAQ
Who is feature-prompt for?
Solo and indie builders using agent skills kits who need a consistent, minimal feature brief before grill-with-docs runs.
When should I use feature-prompt?
In Validate when scoping a change, before Build when you need a handoff artifact, or whenever a rough requirement should become a grill-with-docs prompt with optional CONTEXT.md term cleanup.
Is feature-prompt safe to install?
Review the Security Audits panel on this Prism page before installing; the skill may suggest repo exploration—approve context updates yourself.
Workflow Chain
Then invoke: grill with docs
SKILL.md
READMESKILL.md - Feature Prompt
# Feature Prompt Turn a rough feature request into a minimal, drop-in prompt for `grill-with-docs`. This skill does not create an implementation spec. It creates the smallest useful handoff for the next step. `grill-with-docs` will challenge the plan, inspect code/docs when needed, sharpen domain terms, update `CONTEXT.md`, and offer ADRs only for hard decisions. ## Output Contract Final prompts use this shape: ```markdown Project: [Full Project Matrix code, repo, path, or context. Use one line.] What is needed: [The change to make. One short paragraph or 2-4 bullets.] Why it is needed: [The problem, user pain, business reason, or workflow gap.] Expected end result: [Observable done state. Prefer user-visible behavior, passing checks, or demo flow.] Known limits: [Conditional. Hard constraints, non-goals, compatibility needs, or exclusions already known.] Open questions: [Conditional. Real unresolved questions for grill-with-docs to attack. Keep this short and high-leverage.] ``` Only `Project`, `What is needed`, `Why it is needed`, and `Expected end result` are normal sections. Emit `Known limits` and `Open questions` only when useful. ## Why These Sections - **Project:** Routes the next skill to the right repo, context, or project code. When a Project Matrix code exists, use the full code exactly as written. - **What is needed:** Defines the requested change. - **Why it is needed:** Gives motivation so `grill-with-docs` can challenge tradeoffs instead of only wording. - **Expected end result:** Defines success in observable terms. This becomes the seed for later acceptance criteria. - **Known limits:** Preserves hard boundaries without forcing a full constraints section. - **Open questions:** Hands uncertainty to `grill-with-docs` instead of pretending the prompt is complete. ## Grilling Lenses Use these lenses when turning rough intake into a `grill-with-docs` handoff: - **Question fidelity:** low-fidelity questions are grillable; high-fidelity "feel" questions are often ungrillable without a prototype. - **Scope:** smaller slices reduce hidden high-fidelity risk and keep the grilling session practical. - **Context budget:** preserve room so grilling can stay in the model's smart zone; large prompts that force very long grilling sessions degrade quality. Use ~120K tokens as a caution threshold for many frontier models, not a hard rule. - **Active steering:** the user should guide tradeoffs, not passively absorb endless low-value questions. - **Decision preservation:** the session output is valuable; shape the prompt so decisions can be carried forward into implementation or handoff artifacts. ## Agentic Engineering Add-Ons Apply these defaults when drafting prompts for coding agents: - **Code-first context:** prefer concrete code references over generic docs. If relevant, point to existing modules, symbols, routes, or tests. - **Reuse before rewrite:** steer toward extending existing seams/functions/services before adding parallel implementations. - **PR-sized slices:** draft one small, reviewable, mergeable slice. If intake is broad, split and draft slice 1 only. - **Non-obvious context only:** include constraints, architecture quirks, and domain rules the model cannot infer cheaply from repo scans. - **Convergence signals:** define observable completion so review loops can stop (behavior visible, checks passing, or demo path complete). - **Parallel-safe slicing (optional):** if the user intends parallel agent threads, split slices so they minimize shared-file coupling. ## Rules ### Intake and inference - Start from free-form intake. Accept a sentence, paragraph, bullet list, o