From afyapowers
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and produces a full technical design.
npx claudepluginhub iclinic/devex-marketplace --plugin afyapowersThis skill uses the workspace's default tool permissions.
Help turn ideas into fully formed technical designs through natural collaborative dialogue.
Provides Ktor server patterns for routing DSL, plugins (auth, CORS, serialization), Koin DI, WebSockets, services, and testApplication testing.
Conducts multi-source web research with firecrawl and exa MCPs: searches, scrapes pages, synthesizes cited reports. For deep dives, competitive analysis, tech evaluations, or due diligence.
Provides demand forecasting, safety stock optimization, replenishment planning, and promotional lift estimation for multi-location retailers managing 300-800 SKUs.
Help turn ideas into fully formed technical designs through natural collaborative dialogue.
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the full design — from requirements through architecture — and get user approval.
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity..afyapowers/features/active to get the active feature.afyapowers/features/<feature>/state.yaml — confirm current_phase is designEvery project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
You MUST complete these items in order:
.afyapowers/features/<feature>/artifacts/design.mddigraph design {
"Explore project context" [shape=box];
"Offer JIRA issue key" [shape=box];
"JIRA issue provided?" [shape=diamond];
"Fetch JIRA issue" [shape=box];
"Trigger keywords match?" [shape=diamond];
"Ask Figma question" [shape=box];
"Figma discovery" [shape=box];
"Confirmation-style questions" [shape=box];
"Standard clarifying questions" [shape=box];
"Propose 2-3 approaches" [shape=box];
"Present design sections" [shape=box];
"User approves design?" [shape=diamond];
"Write design doc" [shape=box];
"Spec review loop" [shape=box];
"Spec review passed?" [shape=diamond];
"User reviews spec?" [shape=diamond];
"Suggest /afyapowers:next" [shape=doublecircle];
"Explore project context" -> "Offer JIRA issue key";
"Offer JIRA issue key" -> "JIRA issue provided?";
"JIRA issue provided?" -> "Fetch JIRA issue" [label="yes"];
"JIRA issue provided?" -> "Trigger keywords match?" [label="no"];
"Fetch JIRA issue" -> "Trigger keywords match?";
"Trigger keywords match?" -> "Ask Figma question" [label="yes"];
"Trigger keywords match?" -> "Standard clarifying questions" [label="no"];
"Ask Figma question" -> "Figma discovery" [label="user provides URLs"];
"Ask Figma question" -> "Standard clarifying questions" [label="no Figma designs"];
"Figma discovery" -> "Confirmation-style questions";
"Confirmation-style questions" -> "Propose 2-3 approaches";
"Standard clarifying questions" -> "Propose 2-3 approaches";
"Propose 2-3 approaches" -> "Present design sections";
"Present design sections" -> "User approves design?";
"User approves design?" -> "Present design sections" [label="no, revise"];
"User approves design?" -> "Write design doc" [label="yes"];
"Write design doc" -> "Spec review loop";
"Spec review loop" -> "Spec review passed?";
"Spec review passed?" -> "Spec review loop" [label="issues found,\nfix and re-dispatch"];
"Spec review passed?" -> "User reviews spec?" [label="approved"];
"User reviews spec?" -> "Write design doc" [label="changes requested"];
"User reviews spec?" -> "Suggest /afyapowers:next" [label="approved"];
}
The terminal state is suggesting /afyapowers:next. Do NOT invoke any implementation skill or advance phases. The /afyapowers:next command handles phase transitions.
Understanding the idea:
JIRA discovery (offer-based):
After exploring project context, offer the user:
"Is there a JIRA issue associated with this feature? If so, share the issue key (e.g., PROJ-123)."
If the user provides a JIRA issue key:
Resolve the Atlassian cloud ID:
mcp__claude_ai_Atlassian__getAccessibleAtlassianResources (no parameters)id as the cloudIdFetch the issue:
mcp__claude_ai_Atlassian__getJiraIssue(
cloudId: "<resolved_cloud_id>",
issueIdOrKey: "<user_provided_key>",
responseContentFormat: "markdown"
)
Build the JIRA context summary from the response:
Present this summary to the user for confirmation before proceeding.
Proceed to Figma discovery (the JIRA summary and description text is now part of the context when evaluating Figma trigger keywords)
If no JIRA issue is provided, proceed directly to Figma discovery.
If the Atlassian MCP server is unavailable: Warn the user and stop the JIRA discovery flow. Do not attempt to proceed without it — the user asked for JIRA context, so a silent fallback would undermine the purpose. Suggest the user check their MCP server connection and retry.
Figma discovery (trigger-based):
After exploring project context, check the user's request for these trigger keywords (case-insensitive, word-level matching):
page, landing page, screen, view, layout, header, footer, navbar, sidebar, UI component, form, modal, dialog, card, hero, section, banner, responsive, breakpoint, mobile, desktop, dashboard, panel, widget
If any keyword matches, ask the user:
"Does this feature have Figma designs? If so, please share the Figma URL(s)."
If a keyword matches but the request is clearly not UI work (e.g., "write unit tests for the landing page API endpoint"), use judgment — when in doubt, ask.
If no keywords match, skip Figma discovery and proceed to clarifying questions.
If the user provides Figma URL(s):
Parse each URL to extract the file key and node ID
https://figma.com/design/:fileKey/:fileName?node-id=X-Y:fileKey (segment after /design/) and X-Y (value of node-id parameter)Single get_metadata call on the root node
get_metadata(fileKey=":fileKey", nodeId="X-Y")
From the response, build the Node Map using only the first 2 depth levels of the returned tree:
Ignore any nodes deeper than depth 2. Breakpoints are inferred from top-level frame names and dimensions (e.g., "Desktop" at 1440px, "Mobile" at 375px).
From the response, build the Node Map with two subsections:
a. Reusable Components: Extract all depth-2 nodes typed COMPONENT or COMPONENT_SET. List each with its node ID and type. If none exist, write (none — all components are external or pre-existing).
b. Screens: List each depth-1 FRAME with its node ID, type, and dimensions. Under each frame, list its depth-2 children (excluding COMPONENT/COMPONENT_SET nodes already listed above). Collapse repeated INSTANCE nodes sharing the same componentId with a ×N count.
Build the ## Figma Resources section for the design doc:
get_metadata: page → section → component/element)Use the template from templates/design.md for the section structure.
get_metadata returns:
Page "Landing Page"
Frame "Hero Section" (id: 1:2, type: FRAME, 1440x800)
├── "Hero Title" (id: 1:3, type: TEXT)
├── "CTA Button" (id: 1:4, type: COMPONENT)
├── "Card" (id: 1:5, type: INSTANCE, componentId: 2:10)
├── "Card" (id: 1:6, type: INSTANCE, componentId: 2:10)
└── "Card" (id: 1:7, type: INSTANCE, componentId: 2:10)
Frame "Pricing Section" (id: 2:1, type: FRAME, 1440x600)
├── "Pricing Tier" (id: 2:10, type: COMPONENT_SET)
├── "Section Title" (id: 2:11, type: TEXT)
└── "Pricing Tier" (id: 2:12, type: INSTANCE, componentId: 2:10)
Correct Node Map output:
#### Page: Landing Page
**Reusable Components:**
- CTA Button (node `1:4`, COMPONENT)
- Pricing Tier (node `2:10`, COMPONENT_SET)
**Screens:**
- **Hero Section** (node `1:2`, FRAME, 1440x800)
- Card (node `1:5`, INSTANCE, componentId: `2:10`) ×3
- Hero Title (node `1:3`, TEXT)
- **Pricing Section** (node `2:1`, FRAME, 1440x600)
- Pricing Tier (node `2:12`, INSTANCE, componentId: `2:10`) ×1
- Section Title (node `2:11`, TEXT)
Node Map validation (run before finalizing the Figma Resources section):
node \`` and its type in Reusable Components(none — all components are external or pre-existing)No get_screenshot or get_design_context calls during the design phase — these are deferred to implementation, where the subagent already calls them per-task. This keeps the design phase at exactly 1 MCP call regardless of file complexity.
If the Figma MCP server is unavailable: Warn the user and stop the Figma discovery flow. Do not attempt to proceed without it — the user provided Figma URLs, so a silent fallback would undermine the purpose. Suggest the user check their MCP server connection and retry.
If no Figma designs: Proceed normally. Do not include the Figma Resources section in the design doc.
Design tokens are NOT extracted during design phase. They are deferred to implementation time — the implementer subagent will fetch them via get_variable_defs when needed.
Clarifying questions (JIRA and/or Figma-informed):
When JIRA data and/or Figma data was gathered in previous steps, replace open-ended clarifying questions with confirmation-style:
Examples:
When neither JIRA nor Figma data is available, use the standard approach: ask questions one at a time to understand purpose, constraints, and success criteria.
Exploring approaches:
Presenting the design:
## JIRA Context section with issue key, summary, acceptance criteria, and linked issues## Figma Resources section with file info, breakpoints, and node mapDesign for isolation and clarity:
Working in existing codebases:
REQUIRED: Dispatch spec-document-reviewer subagent after writing the design artifact.
skills/design/spec-document-reviewer-prompt.mdDocumentation:
.afyapowers/features/<feature>/artifacts/design.md
templates/design.mdSpec Review Loop: After writing the spec document:
skills/design/spec-document-reviewer-prompt.md)User Review Gate: After the spec review loop passes, ask the user to review the written spec before proceeding:
"Design written to
.afyapowers/features/<feature>/artifacts/design.md. Please review it and let me know if you want to make any changes."
Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
Completion:
state.yaml to add design.md to the design phase's artifacts listartifact_created event to history.yaml/afyapowers:next to proceed to plan."