סקיל to-prd

פקודת התקנה

ההתקנה מתבצעת דרך מנהל החבילות הרשמי של הסקילים בפקודה אחת. הסקיל הוא קובץ Markdown פתוח מהמאגר של מאט פוקוק, ומופעל במפורש כפקודה ולא אוטומטית. אפשר להוריד ולבדוק את הקוד דרך הכפתורים שבראש העמוד.

מה הסקיל כולל?

הסקיל מתעד תהליך קצר וברור: חקירת מצב הקוד הקיים, סימון התפרים שבהם תיבדק התכונה, וכתיבת מסמך אפיון לפי תבנית קבועה שמתפרסמת למערכת המשימות.

קוד הסקיל המלא

---
name: to-prd
description: Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
disable-model-invocation: true
---

This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.

The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.

## Process

1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.

2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.

Check with the user that these seams match their expectations.

3. Write the PRD using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.

<prd-template>

## Problem Statement

The problem that the user is facing, from the user's perspective.

## Solution

The solution to the problem, from the user's perspective.

## User Stories

A LONG, numbered list of user stories. Each user story should be in the format of:

1. As an <actor>, I want a <feature>, so that <benefit>

<user-story-example>
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
</user-story-example>

This list of user stories should be extremely extensive and cover all aspects of the feature.

## Implementation Decisions

A list of implementation decisions that were made. This can include:

- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions

Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.

Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.

## Testing Decisions

A list of testing decisions that were made. Include:

- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)

## Out of Scope

A description of the things that are out of scope for this PRD.

## Further Notes

Any further notes about the feature.

</prd-template>

מה זה to-prd ולמה הסקיל הזה שונה?

to-prd פותר בעיה מוכרת בכל צוות פיתוח: השיחה על הפיצ'ר הייתה מצוינת, כולם הבינו מה צריך, אבל כשמגיע הרגע לכתוב מסמך אפיון מסודר, האנרגיה נגמרת והפרטים מתחילים להישכח. הסקיל לוקח את ההקשר של השיחה שכבר התקיימה והופך אותו למסמך עבודה שלם, בלי שתצטרכו לעבור שוב על הכול מההתחלה.

מה שמייחד אותו הוא שאין בו ראיון. סקילים אחרים שואלים שאלה אחרי שאלה, וזה מתיש כשכבר דיברתם על הכול. הסקיל הזה מסנתז את מה שידוע, מסקיץ את תפרי הבדיקה של התכונה ומעדיף תפרים קיימים על פני חדשים, ורק מוודא איתכם שהכיוון נכון. אחר כך הוא כותב מסמך לפי תבנית קבועה ומפרסם אותו למערכת המשימות עם תווית שמסמנת שהוא מוכן לעבודה. כך אין נתק בין התכנון לבין הביצוע.

ההבדל מורגש בקצב. במקום שעה של כתיבת אפיון אחרי שיחה טובה, מקבלים מסמך מסודר בתוך דקות, מוכן להעברה לצוות או לסוכן AI. בעבודות האוטומציה שאני בונה, מסמך אפיון מסודר הוא נקודת הפתיחה לכל פיתוח, והסקיל הזה הופך אותו ממשימה שנדחית למשהו שקורה מאליו בסוף כל שיחת תכנון.

מה to-prd נותן לקלוד קוד?

הסקיל מוסיף לקלוד את היכולת לסגור שיחת תכנון במסמך עבודה מסודר, במקום להשאיר את ההחלטות פזורות בהיסטוריית הצ'אט.

ארבע היכולות סוגרות את הלולאה בין שיחה לביצוע: מדברים, מסנתזים, מפרסמים ומתחילים לעבוד. בעבודות שלי, הסקיל הזה הפך את כתיבת האפיון מצוואר בקבוק שנדחה למשהו שקורה אוטומטית בסוף כל שיחת תכנון.

למי הסקיל הזה מתאים?

מנהלי מוצר ומובילי פיתוח: זה הקהל המובהק. הסקיל הופך כל שיחת תכנון למסמך אפיון מוכן, וחוסך את השעה המתישה של כתיבה ידנית. השילוב עם סקיל grill-with-docs מחדד את הדרישות מול התיעוד הקיים עוד לפני תחילת הפיתוח.

יזמים שמתכננים פיצ'ר חדש: אחרי שיחה עם קלוד על רעיון, מקבלים מסמך מסודר שאפשר להעביר למפתח או למשקיע. הרעיון מפסיק להישאר בראש ומקבל צורה שאפשר לעבוד לפיה.

צוותים שעובדים עם סוכני AI: מסמך אפיון מסודר עם תווית מוכן לעבודה הוא בדיוק מה שסוכן צריך כדי להתחיל לפתח. הסקיל מייצר את הקלט הזה אוטומטית, וכך מקצר את הדרך מרעיון לקוד.

פרילנסרים וסוכנויות: מסמך אפיון מקצועי מול לקוח משדר רצינות ומונע אי הבנות. הסקיל מפיק אותו במהירות, כך שאפשר לאשר תכולה מול הלקוח לפני שמתחילים. גם בעבודות קידום אורגני שלי, אפיון ברור של הדרישות חוסך סבבי תיקונים.

מפתחי סולו: גם כשעובדים לבד, מסמך אפיון כתוב עוזר לחשוב לעומק ולא לשכוח פרטים. הסקיל הופך את זה למשהו שקורה בלי מאמץ נוסף.

מי שפחות יתאים: משימה קטנה וברורה שלא דורשת אפיון פורמלי לא צריכה את הסקיל. שם עדיף פשוט לבצע. הסקיל מבריק דווקא כשיש תכונה מורכבת שעברה דיון ושצריך לתרגם אותה למסמך עבודה.

איך to-prd עזר לי בפרויקטים אמיתיים

ארבעת המקרים מראים שהסקיל לא רק חוסך זמן כתיבה, הוא משפר את איכות התקשורת: בין חברי צוות, מול לקוחות ומול סוכני AI. כשכל שיחת תכנון נסגרת במסמך מסודר, פחות דברים נופלים בין הכיסאות והפיתוח מתחיל מנקודה ברורה.

סיכום

סקיל to-prd הוא כלי מצוין לכל מי שמתכנן תכונות ומתעב לכתוב אפיונים. הוא הופך שיחה טובה למסמך עבודה מסודר תוך דקות, עם מבנה קבוע ופרסום ישיר למערכת המשימות, בלי ראיון ובלי חיכוך.

אם אתם מתחילים, נהלו שיחה עם קלוד על תכונה שאתם רוצים לבנות, ואז הפעילו את הסקיל. תקבלו מסמך אפיון מלא שאפשר להעביר מיד לעבודה. משם, כל רעיון שעולה בשיחה יכול להפוך למשימה מוכנה בלחיצה.

בפוסטים הבאים אמשיך לסקור סקילים שמשדרגים את תהליך הפיתוח. האתר של דביר נעמן מרכז את כל הכלים, השיטות והליווי שאני מציע לעסקים שרוצים לעבוד חכם עם בינה מלאכותית.