一键在 Manus 中运行任何 Skill

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 仓库查看创作者相关仓库

下载

在 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.