메뉴
Use this skill to create a GitHub pull request for completed EweserDB work. Summarizes commits since main, writes a clear title and body, and opens the PR. Use after QA has passed.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this skill to run a focused browser feedback checkpoint for completed EweserDB UI work. It verifies the specific user-visible behavior from one run or handoff, captures concise evidence, and reports pass/fail without turning into a full exploratory manual test sweep.
Use this skill to implement a feature in the EweserDB monorepo from a plan file. Also use it when the user invokes $eweser-coder, asks Codex to code an approved EweserDB plan, continue a run from docs/ai/plans, fix a bug, or make repo changes while preserving quality gates. Reads the approved plan at docs/ai/plans/, treats it as the approval boundary, implements all runs, verifies, performs internal QA, fixes issues found inside scope, updates the plan, and ends with self-reflection. Tell Codex which plan file and optionally which run number to start from.
Use this skill for standalone re-QA or audit of completed EweserDB work. Also use it when the user invokes $eweser-qa, asks for QA, review, quality assurance, regression checks, test coverage review, or pre-PR verification for EweserDB. Runs relevant verification, reviews code for correctness and security, and verifies Yjs patterns and monorepo consistency. In the canonical Codex Planner -> Coder workflow, Coder owns internal QA; this skill is optional independent review only.
Use this skill in the EweserDB repo when the user wants to stress-test a feature, plan, product decision, or naming choice against EweserDB domain language before implementation. It uses GLOSSARY-MAP.md, package GLOSSARY.md glossaries, INDEX.md navigation, AGENTS.md, and ADRs to challenge fuzzy terms, resolve DDD-style language, update glossary docs, and identify sparse ADR candidates. It ends with self-reflection and skill-improvement suggestions when the session reveals workflow gaps. Planner-style only: do not edit product code.
Use this skill to create a scoped implementation plan for a feature in the EweserDB monorepo. Also use it when the user invokes $eweser-planner or the legacy personal $eweser-plan name, asks to plan a feature or bug fix, asks for planner/plan-mode behavior, or requests research before implementation for EweserDB. Handles internal research, validation experiments, architecture review, and produces an implementation-ready plan in docs/ai/plans/. Use before starting substantial or ambiguous coding work. Planner stops for user approval and does not implement product code.
Use this skill to manually test completed EweserDB work from a plan file or coder handoff. Verifies local behavior through browser/MCP/API flows, records evidence, reports bugs with reproduction steps, and does not implement fixes.
| name | eweser-create-pr |
| description | Use this skill to create a GitHub pull request for completed EweserDB work. Summarizes commits since main, writes a clear title and body, and opens the PR. Use after QA has passed. |
You create a GitHub pull request summarizing completed work on the EweserDB monorepo.
git status.git --no-pager log --oneline main..HEAD
main.docs/ai/plans/.main using the available GitHub workflow.## What
<One-paragraph summary of the feature/fix>
## Changes
- `packages/...` - <what changed>
- `packages/...` - <what changed>
## Review Evidence
- Screenshots: <links/paths for UI-visible changes, or Not applicable>
- Visual assessment: <pass/fail notes from inspecting UI screenshots>
- Diagrams: <Mermaid diagram or Not applicable>
## Testing
- [ ] Unit tests pass (`npm test`)
- [ ] Types clean (`npm run type-check` or relevant equivalent)
- [ ] Build succeeds (`npm run build`)
## Checklist
- [ ] Changeset added if a published package API changed
- [ ] No secrets committed
- [ ] No direct Yjs mutations introduced
- [ ] Database migrations added, not modified, if schema changed
- [ ] UI-visible changes include screenshots, or the PR explains why not
- [ ] UI screenshots have been inspected for spacing, alignment, balance, wrapping, overflow, density, and responsive fit
- [ ] Backend/data-flow changes include a concise diagram, or the PR explains why not
main.main.