القائمة
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Implement technical plans from docs/plans/ with verification
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | ezra-implement-plan |
| description | [NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Implement technical plans from docs/plans/ with verification |
You are tasked with implementing an approved technical plan from docs/plans/. These plans contain phases with specific changes and success criteria.
When given a plan path:
If no plan path provided, ask for one.
Plans are carefully designed, but reality can be messy. Your job is to:
When things don't match the plan exactly, think about why and communicate clearly. The plan is your guide, but your judgment matters too.
If you encounter a mismatch:
STOP and think deeply about why the plan can't be followed
Present the issue clearly:
Issue in Phase [N]:
Expected: [what the plan says]
Found: [actual situation]
Why this matters: [explanation]
How should I proceed?
After implementing a phase:
Run the success criteria checks (usually make check test covers everything)
Test generation: If the plan's Testing Strategy includes test plans for source files implemented in this phase, run /ezra-generate-<backend/frontend>-tests <source-file> for each. Enter healing loop if tests fail.
Fix any issues before proceeding
Update your progress in both the plan and your todos
Check off completed items in the plan file itself using Edit
Pause for human verification: After completing all automated verification for a phase, pause and inform the human that the phase is ready for manual testing. Use this format:
Phase [N] Complete - Ready for Manual Verification
Automated verification passed:
- [List automated checks that passed]
Please perform the manual verification steps listed in the plan:
- [List manual verification items from the plan]
Let me know when manual testing is complete so I can proceed to Phase [N+1].
If instructed to execute multiple phases consecutively, skip the pause until the last phase. Otherwise, assume you are just doing one phase.
do not check off items in the manual testing steps until confirmed by the user.
When something isn't working as expected:
Use sub-tasks sparingly - mainly for targeted debugging or exploring unfamiliar territory.
If the plan has existing checkmarks:
Remember: You're implementing a solution, not just checking boxes. Keep the end goal in mind and maintain forward momentum.
Alembic migration workflow for SQLAlchemy model changes, emphasizing autogeneration only, date-prefixed migration filenames, env.py model imports, review of generated revisions, and validation with upgrade commands and integration tests.
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Backend architecture patterns, API design, database optimization, and server-side best practices for Node.js, Express, and Next.js API routes.
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Clerk authentication patterns for the Ezra Next.js monorepo — server vs client auth, middleware strategies, Server Actions, API route protection, caching with auth, and token injection via authTokenProvider for Orval-generated hooks. Use when adding Clerk auth to a new app, protecting routes or actions, wiring auth tokens into API calls, debugging "unauthorized" or 401/403 errors, asking "how does auth work in this app", checking why an API call returns 401, protecting a page or Server Action, or implementing role/permission checks. Also use when touching middleware.ts, ClerkProvider, ClerkTokenSync, authTokenProvider, or any import from @clerk/nextjs. Do NOT use for Clerk SDK installation or initial project setup (see Clerk docs quickstart).
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Universal coding standards, best practices, and patterns for TypeScript, JavaScript, React, and Node.js development.
Advisory skill for evaluating and organizing backend domain packages according to DDD best practices and capability-oriented design. Use when creating new domains, reviewing existing domain boundaries, refactoring packages, or deciding where new business logic should live.
[NOT APPLICABLE — Ezra-specific reference; do not invoke in this project] Sentry SDK internals for the ezra_observability Sentry adapter — sentry_sdk.init configuration, StarletteIntegration/FastApiIntegration/SqlalchemyIntegration setup, EventScrubber denylist, before_send filters, PII rules, and adapter-level tests. ADAPTER AUTHORS ONLY. App code must use `from ezra_observability import get_observability` (see ezra-add-monitoring).