FLOWSTACK UI

View saved version →

---
name: flowstack-ui-builder
description: Build or change FLOWSTACK interfaces by selecting the correct public layer and loading exact-version package Agent Knowledge. Use for implementation work with FLOWSTACK components, themes, or colors; use the review skill for audit-only requests.
---

# FLOWSTACK UI Builder

Build from package-owned guidance, not remembered component rules.

## Resolve authority

1. Inspect the target project's dependencies and lockfile. Run `scripts/resolve-agent-knowledge.mjs` from this skill for every FLOWSTACK package and owner you use. Pass `--project`, `--package`, and, when selecting an owner, `--kind` plus `--id`. If that exact package is not installed, also pass its exact `--version`; ranges and implicit locked-version selection are rejected.
2. Read the resolved manifest, zero-failure coverage, package guides, and selected owner artifacts. Prefer the installed package. The resolver may use Agent Tools only when its locked route has the exact requested or installed version.
3. Stop with an unavailable-version report if exact guidance cannot be resolved. Never substitute current, latest, sibling-repository, or remembered guidance.

## Select the layer

- Route an ordinary finished interface to Brick. Search Brick before native replacements or application CSS, and do not import Atom directly.
- Route explicitly requested headless UI or primitive authoring to Atom. Do not add Brick appearance rules there.
- For custom design-system color work, take reviewed Colors output into Theme, compile compatible Theme artifacts, then load those artifacts with Brick.
- Treat paid Blocks as a separate authenticated product boundary. Agent Tools does not carry their registry, source, or item guidance; after an authorized CLI installation, resolve the copied code's public Brick owners here.
- Implement a supplied Blueprint or application plan only after its jobs and policy are explicit. Public skills do not invent product strategy, content, routes, business rules, persistence, analytics, art direction, or private Blueprint policy.

Read the selected package's layer-selection and composition/system guide before individual owners. Follow related exact Atom guidance only when a Brick guide routes there for behavioral understanding; keep finished implementation imports at Brick.

## Implement and verify

- Use documented composition, public APIs, semantic Theme tokens, supported recipes, parts, and responsive contracts from the resolved artifacts.
- Load Brick's documented CSS entry exactly once and apply Theme artifacts in the documented order. Confirm package and contract compatibility rather than assuming it.
- Keep application-owned semantic HTML where the package guide permits it. Do not recreate behavior, accessibility, responsiveness, or styling already owned by FLOWSTACK.
- Run the target repository's focused type, unit, browser/accessibility, build, and package checks in proportion to the change. Check keyboard/focus behavior, responsive containment, appearance modes, CSS presence, and Theme loading where relevant.

## Report gaps

Do not conceal a fallback. Record the exact package/version, intended job, guides and owners searched, missing capability, temporary native/application/CSS fallback, proposed owner (`Brick`, `Atom`, `Colors`, `Theme`, `Block`, `Blueprint`, or `application`), and verification evidence. Repeated compositions are Block or Blueprint candidates, not new component rules in this skill.

Referenced files: 2

View saved version →

---
name: flowstack-ui-compose
description: Map a supplied Blueprint or explicit application plan through finished Brick components using exact-version guidance. Use after product and creative decisions exist; do not use to invent those decisions.
---

# FLOWSTACK UI Compose

Turn an explicit plan into public implementation ownership without becoming a Blueprint or product-policy engine.

## Require a plan

Start from a supplied Blueprint or an application plan that identifies the jobs, content/route intent, and relevant state or policy decisions. If those inputs are missing, ask for them or report the handoff gap. Do not invent product strategy, information architecture, business rules, persistence, analytics, art direction, private catalog ranking, or premium Blueprint content.

## Resolve exact public guidance

Inspect the target dependencies and lockfile. Run `scripts/resolve-agent-knowledge.mjs` for Brick and every other selected public package or owner. Pass an exact `--version` whenever that package is not installed; ranges and implicit locked-version selection are rejected. Read the resolved manifest, zero-failure coverage, package guides, and selected artifacts. Use installed artifacts or an exact matching Agent Tools locked route only. Stop and report an unavailable version rather than substituting latest, current-main, or remembered guidance.

## Map the composition

1. Keep application-owned content, routes, business state, services, persistence, and analytics attached to the supplied plan.
2. Resolve every interface job through Brick's layer-selection and composition guides, then read every selected Brick component guide.
3. Use Atom directly only for an explicitly headless plan. A Brick guide may route to exact Atom behavior guidance, but finished application imports remain Brick-first.
4. For custom colors, preserve the order Colors review -> Theme definition/compilation -> compatible Theme artifacts -> Brick. Load Brick CSS and Theme artifacts as documented.
5. If the supplied plan includes an authorized paid Block already copied by the authenticated CLI, treat that code as application-owned and resolve its public Brick owners. Do not search for, infer, or reproduce paid registry metadata or source through Agent Tools.

Compose outside-in while preserving the supplied responsive and state handoffs. Use supported recipes, semantic tokens, public parts, and application-owned semantic HTML only where exact guides assign them.

## Verify and hand off gaps

Validate copied Block provenance, component anatomy, accessibility/interaction, responsive containment, CSS and Theme loading, appearance modes, types, focused tests, browser behavior, and production build.

For every unresolved job, record package/version, plan job, components searched, missing capability, temporary fallback, proposed owner (`Brick`, `Atom`, `Colors`, `Theme`, `Block`, `Blueprint`, or `application`), and required evidence. Return policy or creative gaps to the plan owner without exposing or fabricating private rules.

Referenced files: 2

View saved version →

---
name: flowstack-ui-maintainer
description: Coordinate a FLOWSTACK public-package change across authority, exact-version dependencies, Agent Knowledge, qualification, and release readiness. Use for maintaining Atom, Brick, Colors, Theme, or their public delivery adapters; use the builder skill for ordinary application UI work.
---

# FLOWSTACK UI Maintainer

Coordinate public package work without collapsing repository or release boundaries.

## Establish authority and exact evidence

Read the workspace and repository instructions that apply to the target. Identify the owner before editing: Atom owns public behavior, Brick finished presentation, Colors reviewed color candidates, Theme compiled semantic artifacts, the private Blocks registry owns paid copy-owned compositions, the public Blocks CLI owns only source-free authenticated delivery, and Agent Tools owns exact-version delivery adapters for public package guidance.

Resolve every affected public package and existing public owner with `scripts/resolve-agent-knowledge.mjs`. Pass `--project`, `--package`, and, for a selected owner, `--kind` plus `--id`; pass an exact `--version` whenever the package is not installed. When resolving a staged or locked archive, also pass its recorded `--archive-sha256`; the resolver must return that locked archive identity. Read the resolved zero-failure coverage, package guides, and selected artifacts. Never substitute a sibling checkout, current-main guidance, or a remembered API for an exact dependency boundary. Do not use Agent Tools to resolve private Blocks source, item guidance, bundles, or authenticated responses.

A new owner requires two passes. Before editing, resolve the baseline package guides and the closest existing owners rather than pretending the new ID exists. Add the public API and canonical Agent Knowledge, regenerate closed coverage, and pack a uniquely identified candidate. Then resolve the new owner from that candidate before a dependent repository adopts it. Do not let the same package version identify materially different candidates across a dependency handoff; use the repository-approved next or prerelease version, or require the exact archive digest when repository policy prevents an early version change.

Before changing an Atom or Brick component, run the owning workspace's task-context preparation when that workflow exists. Treat its output as routing, not authority.

## Plan the dependency slice

- Keep one coherent owner change per branch and record its true parent when work is stacked.
- Put behavior and accessibility prerequisites in Atom before Brick adopts them.
- Let Brick release before the private Blocks registry makes a released-dependency claim. Blocks may qualify against a uniquely versioned, digest-locked Brick candidate only when both owning repositories explicitly permit that candidate workflow; let the private release pipeline complete before a consumer claims an authenticated CLI installation.
- Treat Colors as an independently reviewed input and Theme as a compiled compatibility boundary; do not bypass their candidate and contract checks.
- Update canonical human and machine Agent Knowledge with the owned API. Derived LLM, skill, MCP, website, and archive views follow only after the source package is correct.

State the intended versions, archive identities when applicable, and dependency order before a release-sensitive change. A staged archive may qualify the next candidate only when the owning repository explicitly permits that release-candidate workflow; it is not a published dependency and cannot support a production-consumer claim.

## Implement and qualify

Make the smallest owner-correct change, preserve public export and CSS entry contracts, and add source, generated, packed, and clean-consumer evidence required by the repository. For components, verify semantics, naming, state, focus, keyboard and pointer behavior, responsive containment, appearance modes, forced colors, reduced motion, and documented customization surfaces in proportion to the change.

Regenerate derived artifacts only through repository commands. Review generated diffs for private paths, paid Blocks content, stale versions, uncovered owners, unresolved selections, and unrelated churn. Record Agent Knowledge usefulness only when it changed a decision or prevented a defect.

## Integrate without overreaching

Commit and push an owning subrepository before updating its parent revision. Preserve stacked parent relationships and report CI blockers at the repository that owns them. Do not merge, publish, deploy, create trusted-publishing configuration, or install into a personal environment without the user's authorization for that external mutation.

At handoff, report commits, branches or pull requests, exact versions, verification results, archive hashes when produced, remaining parent/release gates, and the next dependency owner. Do not call a local candidate publicly available.

Referenced files: 2

View saved version →

---
name: flowstack-ui-review
description: Audit a FLOWSTACK implementation against exact-version package Agent Knowledge, ownership, CSS, Theme, responsive, and accessibility contracts. Use for reviews and diagnostics; do not silently turn the review into implementation.
---

# FLOWSTACK UI Review

Review against package-owned evidence, not remembered component rules.

## Establish exact evidence

Inspect the target dependency graph and lockfile. Use `scripts/resolve-agent-knowledge.mjs` for each FLOWSTACK package and reviewed owner, then read its resolved manifest, zero-failure coverage, package guides, and selected artifacts. Pass an exact `--version` whenever that package is not installed; ranges and implicit locked-version selection are rejected. The resolver accepts installed artifacts or exact matching Agent Tools routes only. If the installed/requested version is unavailable, report that as a blocking finding; never review against latest or current-main guidance.

## Audit ownership

- Ordinary finished UI should use Brick. Flag direct Atom imports unless the scope is explicitly headless or the public Brick contract explicitly requires a lower-layer integration point.
- Confirm each interface job maps to the documented Brick owner before accepting native elements, framework widgets, or application CSS. Preserve legitimate application-owned landmarks and document structures.
- Confirm Colors candidates are reviewed before Theme authoring and Theme artifacts are compatible with the installed Brick contract. When authorized paid Blocks are already copied into the application, review their public Brick ownership without expecting Agent Tools to carry private registry metadata or source.
- Treat supplied Blueprint and application decisions as inputs. Do not expose, infer, or invent private policy, creative direction, content, routes, business rules, state persistence, or analytics.

## Audit implementation

Check selected-owner composition and alternatives; semantics, labels, keyboard, pointer, focus, state, portal, and positioning behavior; CSS entry loading; Theme artifact order; appearance modes; supported recipes/tokens/parts; responsive ownership and containment; and the repository's required unit, type, browser/accessibility, build, and package evidence.

Flag unsupported direct declarations on public Brick hooks when documented props, tokens, parts, or Theme ownership should be used. Flag duplicated responsive or behavioral logic. Load exact related Atom guidance to diagnose behavior without recommending a direct Atom bypass in finished Brick code.

## Findings and gaps

For every finding, cite package/version, owner or guide ID, observed code/evidence, violated public rule, impact, and a scoped correction. For a genuine gap, record the intended job, all searched owners, missing capability, current fallback, proposed owner (`Brick`, `Atom`, `Colors`, `Theme`, `Block`, `Blueprint`, or `application`), and verification needed. Distinguish defects from unavailable guidance and intentional application ownership.

Referenced files: 2