원클릭으로 Manus에서 모든 스킬 실행

bottlenote-admin-feature-builder

스타1

포크0

업데이트2026년 5월 17일 09:02

Route Bottlenote admin dashboard feature, bug, API, implementation, verification, and PR requests to the correct project-local skill workflow. Use when the user gives a vague or multi-stage admin request and Codex needs to decide whether to create a spec, design, implementation plan, implement from an existing plan, inspect API docs, or prepare a Korean PR. Trigger on "기능 개발", "버그 수정", "구체화", "어드민에 추가", "구현해줘", "PR 만들어줘", or similar admin workflow requests.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

bottle-note

bottle-note/admin-dashboard

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Bottlenote Admin Feature Router

Use this skill only to choose the correct project-local workflow. Do not use it to create feature docs or edit code directly.

Workflow

Read AGENTS.md and classify the request.
- New feature or page without docs: use bottlenote-admin-feature-spec.
- Feature with spec.md but no design.md: use bottlenote-admin-feature-design.
- Feature with spec.md and design.md but no plan.md: use bottlenote-admin-feature-plan.
- Feature with a ready plan.md: use bottlenote-admin-feature-implement.
- API docs, response shape, endpoint, or contract mismatch: use bottlenote-admin-api as a supporting skill.
- Completed work that needs a Korean PR: use bottlenote-admin-korean-pr.
Preserve the stage order for new feature work.
- Spec first: docs/features/<feature-slug>/spec.md.
- Design second: docs/features/<feature-slug>/design.md.
- Plan third: docs/features/<feature-slug>/plan.md.
- Implementation last: code changes based on plan.md.
Keep outputs in repo docs by default.
- Use .context/ only for temporary scratch notes or handoff details that should not be committed.
- Do not create feature briefs in .context.

Routing Examples

"어드민에 공지사항 관리 추가해줘" -> spec -> design -> plan -> implement.
"이 docs/features/notices/plan.md대로 구현해줘" -> implement.
"API 문서가 바뀌었는데 타입 맞춰줘" -> admin-api.
"작업 끝났으니 PR 만들어줘" -> korean-pr.

Guardrails

Do not skip directly to implementation when feature docs are missing unless the user explicitly asks for a fast one-shot change.
If multiple stage skills apply, use the earliest missing stage first.
Keep API analysis inside the relevant feature docs unless the user explicitly asks for a broad API audit.

이 저장소의 다른 Skills

같은 저장소

bottlenote-admin-feature-implement

bottle-note/admin-dashboard

Implement Bottlenote admin dashboard features strictly from an existing docs/features/{feature-slug}/plan.md. Use when spec.md, design.md, and plan.md already exist and Codex should make code changes, update tests/mocks, run verification, and hand off manual UI review points without redefining the feature. Trigger on "plan.md대로 구현", "구현해줘", "implement this plan", or requests that provide a docs/features/{feature-slug}/plan.md path.

2026-06-211

bottlenote-admin-korean-pr

bottle-note/admin-dashboard

Create Korean pull requests for Bottlenote admin dashboard changes. Use when Codex needs to prepare or create a PR after feature work, bug fixes, API contract work, tests, or documentation changes in this repository. Trigger on requests like "PR 만들어줘", "PR 생성", "pull request 만들어줘", "한글 PR", "작업 올려줘", or when implementation is complete and the user asks to open a PR.

2026-06-211

bottlenote-admin-feature-design

bottle-note/admin-dashboard

Create or update Bottlenote admin feature UI design docs in docs/features/{feature-slug}/design.md from an approved spec.md and existing shadcn/Tailwind admin dashboard patterns. Use when Codex needs to define route/sidebar placement, list/detail/form UI, states, validation copy, and manual UI review points before implementation planning. Trigger on design, UI structure, 화면 설계, 디자인 문서, or admin page layout requests.

2026-05-301

bottlenote-admin-api

bottle-note/admin-dashboard

Check Bottlenote admin API documentation and apply frontend API contract updates for this dashboard. Use when Codex needs to inspect admin API specs, compare docs with code, add or update endpoints, fix request/response type mismatches, or support feature spec/plan work with API field analysis. Trigger on requests mentioning Bottlenote API, admin API docs, endpoint updates, response shape changes, or code/API inconsistencies.

2026-05-181

bottlenote-admin-feature-plan

bottle-note/admin-dashboard

Create or update decision-complete implementation plans in docs/features/{feature-slug}/plan.md from Bottlenote admin feature spec.md and design.md. Use before code implementation so another agent can implement without reinterpreting product requirements or UI design. Trigger on implementation plan, 개발 계획, 구현 계획, plan.md, or requests to prepare a feature for implementation.

2026-05-171

bottlenote-admin-feature-spec

bottle-note/admin-dashboard

Create or update Bottlenote admin feature specifications in docs/features/{feature-slug}/spec.md from user intent, API documentation, response shapes, and existing dashboard behavior. Use before design, planning, or implementation for new admin pages, workflows, API-backed features, or substantial feature changes. Trigger on requests for feature definition, spec writing, requirements, acceptance criteria, or Korean requests like "기능 정의", "스펙 작성", "요구사항 정리".

2026-05-171

name

bottlenote-admin-feature-builder

description

Bottlenote Admin Feature Router

Use this skill only to choose the correct project-local workflow. Do not use it to create feature docs or edit code directly.

Workflow

Read AGENTS.md and classify the request.
- New feature or page without docs: use bottlenote-admin-feature-spec.
- Feature with spec.md but no design.md: use bottlenote-admin-feature-design.
- Feature with spec.md and design.md but no plan.md: use bottlenote-admin-feature-plan.
- Feature with a ready plan.md: use bottlenote-admin-feature-implement.
- API docs, response shape, endpoint, or contract mismatch: use bottlenote-admin-api as a supporting skill.
- Completed work that needs a Korean PR: use bottlenote-admin-korean-pr.
Preserve the stage order for new feature work.
- Spec first: docs/features/<feature-slug>/spec.md.
- Design second: docs/features/<feature-slug>/design.md.
- Plan third: docs/features/<feature-slug>/plan.md.
- Implementation last: code changes based on plan.md.
Keep outputs in repo docs by default.
- Use .context/ only for temporary scratch notes or handoff details that should not be committed.
- Do not create feature briefs in .context.

Routing Examples

"어드민에 공지사항 관리 추가해줘" -> spec -> design -> plan -> implement.
"이 docs/features/notices/plan.md대로 구현해줘" -> implement.
"API 문서가 바뀌었는데 타입 맞춰줘" -> admin-api.
"작업 끝났으니 PR 만들어줘" -> korean-pr.

Guardrails

Do not skip directly to implementation when feature docs are missing unless the user explicitly asks for a fast one-shot change.
If multiple stage skills apply, use the earliest missing stage first.
Keep API analysis inside the relevant feature docs unless the user explicitly asks for a broad API audit.