Skip to main content
Manus에서 모든 스킬 실행
원클릭으로
GitHub 저장소

moneybin

moneybin에는 bsaffel에서 수집한 skills 4개가 있으며, 저장소 수준 직업 범위와 사이트 내 skill 상세 페이지를 제공합니다.

수집된 skills
4
Stars
5
업데이트
2026-07-19
Forks
0
직업 범위
직업 카테고리 2개 · 100% 분류됨
저장소 탐색

이 저장소의 skills

moneybin-design
웹·디지털 인터페이스 디자이너

Design MoneyBin interfaces and assets on-brand in the "Ledger-grade" style (dark-lead, three-tier metal accent, money in mono, SQL provenance). Use when building, mocking, or theming any MoneyBin UI, screen, artifact, or component.

2026-07-19
design-import
웹·디지털 인터페이스 디자이너

Use when bringing design work created in claude.ai/design — a component, a guideline/specimen card, a token change, or a full screen — back into the repo's design-system/. The inbound direction, opposite of the outbound /design-sync. Triggers: a designer built something in the design tool and handed you a project link (or a zip) to get into the repo.

2026-07-17
update-docs
소프트웨어 개발자

Update the public-facing documentation surface — README, CHANGELOG, CONTRIBUTING, top-level docs (architecture, audience, comparison, features, licensing, roadmap), docs/guides/, docs/reference/, docs/architecture/, docs/tech/ — to reflect what the in-scope code change means for users. Persona-aware writing per docs/audience.md; assumes the reader is not an expert on internals. Excludes specs and ADRs (those are /update-specs and by-hand respectively). Use this when finishing user-visible work, before opening a PR that adds capability, when a milestone closes, or whenever the user says "update the docs" / "make sure the docs reflect this." Don't wait to be asked — if user-visible work just shipped, suggest running it.

2026-05-24
update-specs
소프트웨어 개발자

Reconcile docs/specs/ with the implementation that actually shipped in the current scope. Reviews recent code changes, identifies which specs the changes touch via docs/specs/INDEX.md, and updates each spec to reflect design evolutions, refactors, or follow-up work that didn't get its own spec. Auto-edits small drift; surfaces design-intent changes for review. Use this whenever finishing a feature branch, after a follow-up PR adds behavior the original spec didn't describe, after a refactor renames or moves primitives referenced in specs, or whenever the user asks "are the specs still accurate?" / "update the specs" / "sync the specs to the code." If you've just finished implementation work that drifted from the spec it was based on, suggest running it without waiting to be asked.

2026-05-17