agile-proto
Interactive UI Prototyping
Build standalone interactive prototypes to validate UI flows before implementation. Zero build tools — everything runs from CDN. Visual and API should mirror the target project's component system. Use an existing local prototype as reference only when the project already has one.
When the prototype is part of an agile planning initiative, keep it with the planning artifacts: planning/<initiative>/proto/. This makes proto/ a sibling of intake.md, roadmap.md, notes, and future epic folders. Use client-proto/ only when the project already follows that convention or when prototyping inside an application package.
When product behavior or domain rules emerge during prototype work, document them beside the planning artifacts in planning/<initiative>/business/*.md with stable rule IDs. Keep the prototype close to the real product surface: do not add visible explanatory copy for internal architecture, business rules, testing strategy, provider details, or implementation notes unless that text would exist in the shipped UI.
Stack
- z-proto — web component shell from the public GitHub repo https://github.com/djalmajr/z-proto (responsive presets, zoom, resize handles, Figma export button)
- Tailwind CSS v4 —
@tailwindcss/browser+@theme inlinemapping shadcn CSS variables - shadcn components (55) — one file per component in
components/ui/, class strings copied verbatim from the original shadcn. Behavior delegated to native HTML5 (<dialog>,<details>, popover API, scroll-snap) - Preact + htm + preact-iso — rendering and client-side scene routing via importmap + esm.sh
- iconify-icon — web component, wrapped by
<Icon>incomponents/ui/icon.js
No daisyUI, no Radix. The 55 components in
components/ui/cover the shadcn catalog — always import from there, never recreate.
Structure
More from djalmajr/essential-skills
agile-metrics
Consolidates objective metrics of a sprint. Use when you need quantitative data about deliveries, blockers, deviations, and velocity to feed retro, sprint review, or capacity decisions.
17agile-retro
Conducts retrospective with learnings and improvement actions. Use when a cycle, sprint, or delivery has ended and the team needs to reflect on what worked and what needs to change. Also absorbs post-implementation reflection aspects.
16agile-intake
Structures new and vague problems into clear intake documents. Use when the problem is not yet mature enough for the backlog, when someone brings an idea or need without defined scope, or when you need to decide what the next artifact in the flow should be.
16agile-roadmap
Maps multi-phase trajectories with dependencies into clear, sequenced roadmaps. Use when work has multiple phases that need sequencing, when decisions today affect future decisions, when stakeholders need to see the whole journey, or when external dependencies exist. Applicable regardless of total duration — a 4-week multi-phase initiative benefits as much as a quarterly roadmap.
16agile-epic
Structures large initiatives into a decomposed backlog with roadmap, dependencies, and verification. Generates an overview file plus individual story files with tasks. Use when work requires several coordinated stories, has dependencies between deliveries, or needs a roadmap.
16agile-story
Creates execution plan with tasks for a single story or a localized standalone change. Use when the work fits in one cycle — either a story already scoped by an epic, or a small/localized change that doesn't need decomposition.
16