45 lines
5.7 KiB
Markdown
45 lines
5.7 KiB
Markdown
---
|
|
name: feature-ideation
|
|
description: "Review possible Stickman Studio features with the Designer, compare value and risks, then help a chosen idea become a saved design brief."
|
|
---
|
|
|
|
# Feature Ideation
|
|
|
|
Use this skill when the user wants to compare, discuss, or plan one or more future Stickman Studio features. Keep the work at the product/design level. The skill has two distinct stages: review possible features and stop for the user's choice; later, after discussion and the user's readiness, have Designer create a phase brief and report its path.
|
|
|
|
## Delegate to Designer
|
|
|
|
Use the `designer` subagent for feature evaluation and design discussion. Spawn it with `agent_type: "designer"` and `model: "gpt-6-sol"`; that role is configured for GPT-6-sol. Pass the user's goal and candidate features in the first message, along with the relevant project context, so Designer can begin from the stated goal. Reuse the same designer agent during follow-up turns when available. If it is no longer available, spawn another with a concise summary of the candidates, decisions, and unresolved questions.
|
|
|
|
Have Designer inspect relevant current project docs and code before judging fit, dependencies, or likely implementation issues. Prefer maintained docs and current code; treat archived roadmap material as history, not a priority list. Do not invent certainty where details are unknown: label assumptions and open questions.
|
|
|
|
When the discussion involves a new in-stage selected-object inspector, have Designer review
|
|
`docs/specs/stage_panel_ui_system.md` and the current shared controls in
|
|
`scripts/shared/stage_ui/`. Treat them as the established panel design to extend where it fits;
|
|
do not assume they apply unchanged to dialogs or other editor workflows.
|
|
|
|
## Stage 1: Compare ideas, then stop
|
|
|
|
When the user provides one or more candidate features:
|
|
|
|
1. Identify the child-facing outcome and the project's current behavior relevant to each feature. Ask the user for more input only if there is no usable feature goal; otherwise let Designer state assumptions and uncertainties in the review.
|
|
2. Ask Designer to assess each candidate's user value, fit with the project direction, relevant dependencies, likely product/design/technical issues, and relative priority. Ask for a clear recommendation on what to discuss first, with reasons. Avoid treating priority as a release commitment.
|
|
3. Ask Designer for one to three additional feature ideas that fit the project, with a short rationale and any important dependency or risk.
|
|
4. Keep `docs/ideas/feature_backlog.md` current as ideas become clear: add or update substantive user candidates and Designer-suggested ideas, preserving existing entries, rationale, links, and priorities that remain valid. Use its existing status and entry conventions. Do not duplicate an existing idea, promote an idea to Verified without evidence, or import the archived roadmap wholesale.
|
|
5. Present a compact comparison, normally a table with feature, expected child outcome/value, fit/dependencies, likely issues, and suggested priority. Then show the recommended next feature and the additional ideas. Link the backlog if it changed.
|
|
6. End with the question **“Which feature would you like to discuss further?”** and stop. Do not start the deeper discussion, write a phase plan, invoke the architect/developer, or begin implementation in this turn.
|
|
|
|
## Stage 2: Discuss the chosen feature
|
|
|
|
After the user chooses a feature, use Designer as a product-design partner to refine the goal, intended audience, child flow and feedback, scope, success criteria, risks, and relevant project references. Keep the discussion conversational; ask only focused questions that materially affect the idea. Reflect the user's answers in the discussion and keep its backlog entry marked `Exploring` until a brief is accepted. Do not write a phase plan merely because the user chose the idea or asked to talk about it.
|
|
|
|
Treat the user's clear statement that they are ready to work on the discussed, sufficiently settled feature as acceptance to prepare a Designer handoff. If scope or a key product decision is still unresolved, ask Designer to identify it and resolve it with the user before drafting. If the user has not supplied the phase number, ask exactly **“What phase number will this be?”** and wait. If the user already supplied it, use that number without asking again.
|
|
|
|
## Stage 3: Write and hand off the brief
|
|
|
|
Once the user is ready and the phase number is known, ask whether the brief and later feature work should use a Git worktree unless the user has already stated a preference for this task. Follow the choice and the `Feature branches and worktrees` rules in `AGENTS.md`; do not create a worktree before the user answers. Use the selected checkout consistently for the brief, later specs, implementation, and verification. Pass its absolute path and current branch to Designer. Do not switch branches or write outside the selected checkout.
|
|
|
|
Have Designer create the accepted product/design brief at `docs/plans/phase_<number>_<feature_slug>.md`, following `docs/plans/README.md`. The brief should cover the goal and audience, desired child outcome, behavior/flow and feedback, story or directing value where relevant, success criteria, included and excluded scope, known risks/dependencies, project references, and remaining questions for the spec-pipeline. Keep architecture/API decisions for the architect's later technical specification in `docs/specs/`.
|
|
|
|
Do not overwrite an existing phase brief without the user's direction. Confirm the resulting file exists, update the matching backlog entry to `Planned` with a link to the brief, then tell the user where the plan is using a clickable local file link. Stop there; this skill creates the design handoff, not the technical spec or implementation.
|