Developer Portal Basic
Use this skill when the task is to design API portals, SDK docs, developer onboarding, keys, logs, and integration pages.
Goal: produce a quick but usable draft page or interface that supports quickstart clarity, examples, credentials, and operational feedback.
Variant intent
- Use the lightweight draft version for quick prototypes, rough alternatives, or retrieval-quality comparisons. Keep it shippable, but accept simpler structure and fewer refinements.
- Optimize for fast layout, obvious labels, a minimal section set, and a short checklist.
- Prefer concrete UI decisions over generic advice.
Default workflow
- Define the primary user, task, and success action.
- Map the minimum page structure needed for the scenario.
- Establish hierarchy: what must be understood first, second, and third.
- Design responsive behavior for mobile and desktop.
- Add states: loading, empty, error, success, disabled, and permission where relevant.
- Run the final checks before delivery.
Design rules
- Use clear section names and user-facing copy.
- Make the primary action visually dominant and repeat it only when it helps.
- Keep navigation and secondary actions subordinate to the main task.
- Use spacing, typography, and alignment before adding decorative containers.
- Do not hide critical information behind hover-only interactions.
- Preserve keyboard access, readable contrast, and touch targets.
Basic guidance
- Start from a simple recognizable layout and keep the section count low.
- It is acceptable to use conventional patterns if the page remains clear.
- Add only the most important states and interactions.
- Avoid over-polishing; this version is useful for quick drafts and baseline comparisons.
- Mark any assumptions that a stronger version should revisit.
Reject these failures
- Ambiguous primary action
- Important status or pricing hidden below the fold
- Dense UI with no scan order
- Decorative visuals that compete with the task
- Missing mobile behavior
Final checks
- Can the target user understand the page purpose in under five seconds?
- Is the next action clear without reading every paragraph?
- Are edge states and responsive behavior accounted for?
1---2name: developer-portal-basic3description: Use when designing API portals, SDK docs, developer onboarding, keys, logs, and integration pages. Basic version focused on quickstart clarity, examples, credentials, and operational feedback; emphasizes fast layout, obvious labels, a minimal section set, and a short checklist.4---56# Developer Portal Basic78Use this skill when the task is to design API portals, SDK docs, developer onboarding, keys, logs, and integration pages.910Goal: produce a quick but usable draft page or interface that supports quickstart clarity, examples, credentials, and operational feedback.1112## Variant intent1314- Use the lightweight draft version for quick prototypes, rough alternatives, or retrieval-quality comparisons. Keep it shippable, but accept simpler structure and fewer refinements.15- Optimize for fast layout, obvious labels, a minimal section set, and a short checklist.16- Prefer concrete UI decisions over generic advice.1718## Default workflow19201. Define the primary user, task, and success action.212. Map the minimum page structure needed for the scenario.223. Establish hierarchy: what must be understood first, second, and third.234. Design responsive behavior for mobile and desktop.245. Add states: loading, empty, error, success, disabled, and permission where relevant.256. Run the final checks before delivery.2627## Design rules2829- Use clear section names and user-facing copy.30- Make the primary action visually dominant and repeat it only when it helps.31- Keep navigation and secondary actions subordinate to the main task.32- Use spacing, typography, and alignment before adding decorative containers.33- Do not hide critical information behind hover-only interactions.34- Preserve keyboard access, readable contrast, and touch targets.3536## Basic guidance3738- Start from a simple recognizable layout and keep the section count low.39- It is acceptable to use conventional patterns if the page remains clear.40- Add only the most important states and interactions.41- Avoid over-polishing; this version is useful for quick drafts and baseline comparisons.42- Mark any assumptions that a stronger version should revisit.4344## Reject these failures4546- Ambiguous primary action47- Important status or pricing hidden below the fold48- Dense UI with no scan order49- Decorative visuals that compete with the task50- Missing mobile behavior5152## Final checks5354- Can the target user understand the page purpose in under five seconds?55- Is the next action clear without reading every paragraph?56- Are edge states and responsive behavior accounted for?
mr-q526