name	bansos-develop-feature
description	Develop, review, or ship UI and feature changes for wauputr4/bansos / bansos.dev. Use when an AI agent needs to modify the SvelteKit static site, improve mobile UI, add pages/components/data behavior, update SEO, adjust contributor/list flows, prepare PRs, or follow bansos.dev contribution and release expectations.

Bansos Develop Feature

Goal

Ship focused bansos.dev improvements that preserve the static SvelteKit architecture, SEO quality, contributor workflow, and small open-source PR style.

Workflow

Identify the smallest files needed for the requested UI or feature change.
Follow the existing SvelteKit, component, and data conventions before introducing new abstractions.
Keep the site static-friendly for GitHub Pages. Avoid server-only state, databases, secrets in client code, and runtime-only dependencies unless the user explicitly wants an architecture change.
Preserve SEO basics for public pages: useful titles, descriptions, canonical/social metadata when the local pattern supports them, and crawlable content.
For UI changes, keep desktop clean and make mobile feel native: tight spacing, readable text, stable tap targets, and bottom navigation where the existing design uses it.
For data or contributor changes, coordinate with the bansos entry workflow instead of bypassing validation.
Run the narrowest useful validation when the user asks for testing or when the change affects shared behavior.
Prepare PRs with a clear summary, screenshots or preview notes for UI work, and explicit source/evidence notes for SEO or data behavior.
When asked to check reviews or merge, inspect thread-level PR review state and CI status. Fix unresolved, non-outdated actionable comments before merging.

Project Constraints

Repo: wauputr4/bansos.
App: static SvelteKit site deployed by GitHub Pages workflow.
Main data source: src/lib/data/bansos.json.
Public add flow: npx bansosdev add, issue URL, then automated PR.
Maintainer direct flow: BANSOSDEV_GITHUB_TOKEN plus --mode direct.
Good PRs include clear source links, contributor metadata, preview/screenshot for UI, and expected SEO/performance impact when relevant.
Data PRs should preserve source evidence links and regenerate commit contributor metadata when listings change.

UI Direction

Respect the current visual language instead of restyling the whole site.
Prefer reusable components when the same UI appears across home, list, detail, and contribute pages.
Keep list pages scannable: tag filtering, newest-first defaults, and visible active/expired/upcoming states.
Avoid hiding important contribution instructions behind interaction-only controls.
Make long CLI examples readable on mobile without forcing horizontal page overflow.

References

Read references/bansos-development-rules.md for detailed project conventions, validation commands, PR checklist, and Cloudflare/GitHub release notes.

Bansos Develop Feature

Goal

Ship focused bansos.dev improvements that preserve the static SvelteKit architecture, SEO quality, contributor workflow, and small open-source PR style.

Workflow

Identify the smallest files needed for the requested UI or feature change.

Follow the existing SvelteKit, component, and data conventions before introducing new abstractions.

Keep the site static-friendly for GitHub Pages. Avoid server-only state, databases, secrets in client code, and runtime-only dependencies unless the user explicitly wants an architecture change.

Preserve SEO basics for public pages: useful titles, descriptions, canonical/social metadata when the local pattern supports them, and crawlable content.

For UI changes, keep desktop clean and make mobile feel native: tight spacing, readable text, stable tap targets, and bottom navigation where the existing design uses it.

For data or contributor changes, coordinate with the bansos entry workflow instead of bypassing validation.

Run the narrowest useful validation when the user asks for testing or when the change affects shared behavior.

Prepare PRs with a clear summary, screenshots or preview notes for UI work, and explicit source/evidence notes for SEO or data behavior.

When asked to check reviews or merge, inspect thread-level PR review state and CI status. Fix unresolved, non-outdated actionable comments before merging.

Project Constraints

Repo: wauputr4/bansos.

App: static SvelteKit site deployed by GitHub Pages workflow.

Main data source: src/lib/data/bansos.json.

Public add flow: npx bansosdev add, issue URL, then automated PR.

Maintainer direct flow: BANSOSDEV_GITHUB_TOKEN plus --mode direct.

Good PRs include clear source links, contributor metadata, preview/screenshot for UI, and expected SEO/performance impact when relevant.

Data PRs should preserve source evidence links and regenerate commit contributor metadata when listings change.

UI Direction

Respect the current visual language instead of restyling the whole site.

Prefer reusable components when the same UI appears across home, list, detail, and contribute pages.

Keep list pages scannable: tag filtering, newest-first defaults, and visible active/expired/upcoming states.

Avoid hiding important contribution instructions behind interaction-only controls.

Make long CLI examples readable on mobile without forcing horizontal page overflow.

References

Read references/bansos-development-rules.md for detailed project conventions, validation commands, PR checklist, and Cloudflare/GitHub release notes.

bansos-develop-feature