القائمة
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.