Spec-Driven Development: ایک فوری کورس

13 تصورات · what پر اتفاق کریں، پھر how generate کریں

آپ AI سے کچھ build کرنے کو کہتے ہیں۔ وہ code واپس دیتا ہے جو دیکھنے میں ٹھیک لگتا ہے۔ آپ اسے run کرتے ہیں۔ وہ ٹوٹ جاتا ہے۔ یا اس سے بھی برا: یہ چلتا ہے، مگر وہ problem solve کرتا ہے جو آپ کے ذہن میں موجود problem سے ذرا مختلف تھی۔ پھر آپ دوبارہ explain کرتے ہیں۔ AI وہ حصہ fix کرتا ہے اور خاموشی سے کوئی ایسی چیز undo کر دیتا ہے جو دو messages پہلے درست تھی۔ ایک گھنٹے بعد آپ کے پاس code کا ڈھیر ہے جس پر آپ پوری طرح trust نہیں کرتے اور جسے cleanly change نہیں کر سکتے۔

اس loop کا نام ہے: vibe coding۔ آپ AI کو vague idea دیتے ہیں اور امید کرتے ہیں کہ وہ correctly guess کرے گا۔ Throwaway prototype کے لیے یہ fine ہے۔ مگر جس چیز کو آپ keep، deploy، یا کسی اور کے حوالے کرنے کا ارادہ رکھتے ہیں، اس کے لیے یہ trap ہے۔

Spec-Driven Development (SDD) اسی trap سے نکلنے کا راستہ ہے۔ آپ جو چاہتے ہیں اسے hopeful انداز میں describe کرنے کے بجائے لکھتے ہیں، اتنا clear کہ code بننے سے پہلے آپ اور AI دونوں agree کر لیں۔ یہ written agreement spec ہے۔ Code وہ چیز بنتا ہے جو spec produce کرتی ہے، نہ کہ spec code کے بعد آتی ہے۔

یہ course discipline کو end to end cover کرتا ہے۔ آخر تک آپ full spec-driven build خود تین ways میں run کر سکیں گے: claude.ai میں، یعنی web app اور یہاں آپ کا main tool؛ Claude Code میں؛ اور OpenCode میں۔ Discipline تینوں میں منتقل ہوتی ہے۔

SDD میں spec source of truth ہے، اور code build output ہے۔ اس course کا ہر concept بہتر spec لکھنے، اس پر جلد agree کرنے، یا project grow ہوتے ہوئے اسے true رکھنے کا طریقہ ہے۔

یہ already practice میں agentic coding کا pattern ہے

اس بات کو faith پر لینے کی ضرورت نہیں۔ Anthropic کے 2026 analysis نے تقریباً 400,000 agentic coding sessions میں clear division of labor دیکھا: لوگ زیادہ تر planning decisions کرتے ہیں، یعنی کیا build کرنا ہے؛ agent زیادہ تر execution decisions کرتا ہے، یعنی کیسے build کرنا ہے۔ اور session کی success کا strongest predictor coding skill نہیں تھا؛ domain expertise تھا: انسان نے work کو کتنی precision سے frame کیا، agent سے کیا verify کروایا، اور drift ہونے پر اسے واپس کیسے steer کیا۔ SDD وہ discipline ہے جو آپ کو اس half میں اچھا بناتی ہے جو آپ کے پاس رہتا ہے۔ Anthropic کی Agentic coding and persistent returns to expertise دیکھیں۔

تقریباً 400,000 sessions میں what/how split (Anthropic، 2026)۔ SDD وہ discipline ہے جس سے آپ planning half میں بہتر ہوتے ہیں۔

Prerequisite: AI Prompting in 2026

اس course نے آپ کو AI سے بات کرنا سکھایا: context دینا، clear ask کرنا، work check کرنا۔ یہ course سکھاتا ہے کہ کسی بھی ask سے پہلے کیا کرنا ہے: fuzzy idea کو ایسی written spec میں کیسے بدلنا ہے جس سے build کیا جا سکے۔ یہ Agentic Coding Crash Course کے ساتھ naturally pair ہوتا ہے، جو coding tools کے mechanics کے لیے companion ہے۔

اس کے لیے programmer ہونا ضروری نہیں​

SDD thinking discipline ہے، coding skill نہیں۔ آپ اسے تقریباً entirely plain language میں، normal chat window میں practice کرتے ہیں۔ Output ایک clearly written document ہوتا ہے، پھر اس سے بنا ہوا working result: app، script، report generator، یا automation۔ اگر آپ capable colleague کے لیے clear brief لکھ سکتے ہیں، تو spec لکھ سکتے ہیں۔ (یہ skill اب developer-only نہیں رہی؛ اس کے لیے Code You Never Write دیکھیں۔)

Study اس بات کو concrete بناتی ہے: coding background نے session success کو barely change کیا؛ domain expertise نے کیا۔ آپ سے code لکھنے کو نہیں کہا جا رہا؛ آپ سے کہا جا رہا ہے کہ اپنے problem کو اتنا اچھی طرح جانیں کہ اسے لکھ سکیں: rules، edge cases، "done" کا مطلب۔ Spec وہ جگہ ہے جہاں آپ کی expertise جاتی ہے۔ وہ accountant جو ہر reconciliation rule state کر سکتا ہے، اس developer سے better build کرواتا ہے جو books نہیں سمجھتا؛ کیونکہ spec knowledge carry کرتی ہے اور agent code supply کرتا ہے۔

---

تین tools، ایک discipline​

نیچے دی گئی ہر چیز تین tools میں کام کرتی ہے۔ ہم claude.ai سے lead کرتے ہیں کیونکہ اسے install نہیں کرنا پڑتا، browser میں real spec-driven work آج ہی ہو سکتا ہے، اور chat-and-document loop thinking کو visible بناتا ہے۔ یہی moves دونوں coding agents پر cleanly map ہوتے ہیں۔

	claude.ai (main)	Claude Code	OpenCode
What it is	The web/desktop chat app	Anthropic's coding agent (terminal/IDE)	Open-source coding agent, any model
Where the spec lives	An Artifact (an editable doc beside the chat) in a Project (a saved workspace)	Files in your repo (CLAUDE.md, specs/)	Files in your repo (AGENTS.md, specs/)
Best for	Thinking, drafting, non-coders, getting started	Building real software, end-to-end	Same, with model choice and cost control
Alternatives	ChatGPT (Projects + Canvas) and Gemini (Gems + Canvas) run the same discipline	(none)	(none)

یہ course کیا cover کرتا ہے​

حصہ	موضوع	آپ کیا سیکھتے ہیں
1	Shift	Vibe coding کیوں fail ہوتی ہے، spec اصل میں کیا ہے، SDD کے تین levels
2	Method	Constitution، پھر چار phases: Research → Specify → Clarify → Build
3	Three Ways	claude.ai، Claude Code، اور OpenCode میں loop run کرنا
4	Complete Worked Example	ایک feature، start to finish، claude.ai پھر Claude Code میں
5	Judgment	SDD کب worth it ہے، کب overkill، اور spec کو alive کیسے رکھنا ہے

15-minute spine (اگر آپ کے پاس صرف چند منٹ ہیں)

اگر آپ نئے ہیں اور time کم ہے تو Concept 1 (vibe coding کیوں fail ہوتی ہے)، Concept 2 (spec product ہے)، Concept 7 (Clarify by interview)، Part 2 کے آخر کا four-prompt block، اور Part 4 کا worked example پڑھیں۔ یہ minimal viable read ہے؛ باقی later deepen کرتا ہے۔ جب discipline واقعی آپ کی بنانی ہو تو آخر کی Practice ladder پر جائیں۔ یہ split خود SDD move ہے: spine spec ہے، باقی plan۔

---

حصہ 1: Shift​

تین ideas AI کے ساتھ کام کرنے کا طریقہ reframe کرتے ہیں۔ انہیں سمجھ لیں، باقی mechanics ہیں۔

1. Vibe coding vs. spec-driven development​

فرق یہ ہے کہ آپ thinking کب کرتے ہیں۔

Vibe coding میں آپ AI کے build کرتے ہوئے سوچتے ہیں، یعنی جو وہ دیتا ہے اس پر react کر کے discover کرتے ہیں کہ آپ اصل میں کیا چاہتے تھے۔ یہ fast محسوس ہوتا ہے: screen پر فوراً کچھ آ جاتا ہے۔ مگر ہر round trip تھوڑا context کھو دیتا ہے، AI gaps کو reasonable-but-wrong assumptions سے fill کرتا ہے، اور result rarely آپ کے project کے باقی حصے سے match کرتا ہے۔ Cost بعد میں ایک ساتھ آتی ہے، جب آپ چیز کو change یا trust کرنے کی کوشش کرتے ہیں۔

Spec-driven development میں آپ پہلے سوچتے ہیں اور اسے لکھتے ہیں۔ AI build شروع نہیں کرتا جب تک آپ دونوں agree نہ کر لیں کہ "done" کا مطلب کیا ہے۔ Build پھر mostly mechanical ہو جاتی ہے: یہ agreement execute کر رہی ہوتی ہے، guess نہیں۔

دو loops: vibe coding prompt، code، اور "not quite" کے بیچ گھومتی ہے؛ SDD پہلے spec بناتا ہے، پھر اس کے خلاف short build-and-check loop چلاتا ہے۔

یہ prompting میں سیکھی ہوئی same move ہے (context first، then ask)، مگر stakes زیادہ ہیں: AI اب صرف question answer نہیں کر رہا، آپ کے project میں code لکھ رہا ہے۔

Rule of thumb: اگر result پھینکنا آپ کو annoying لگے، تو آپ vibe coding کے safe point سے آگے نکل چکے ہیں۔ Spec لکھیں۔

2. Spec product ہے؛ code build output ہے​

یہ mental flip SDD کو اس کا نام دیتا ہے۔ Decades تک spec code کی خدمت کرتی تھی: brief لکھا، چیز build کی، brief discard کر دیا۔ SDD اسے invert کرتا ہے۔ Spec durable artifact ہے جسے آپ maintain کرتے ہیں؛ code اس سے generate ہوتا ہے، اور spec change ہو تو دوبارہ generate ہوتا ہے۔ "Re-generated" کا مطلب magic compile button نہیں؛ updated spec پر build loop دوبارہ run کرنا اور result review کرنا ہے: spec ایک imperfect agent کو guide کرتی ہے جسے آپ supervise کرتے ہیں۔

Inversion: old way میں spec code کی scaffolding تھی؛ SDD spec کو source of truth بناتا ہے اور code re-derivable output۔

اچھی spec تین questions کا جواب order میں دیتی ہے:

1. Why: ہم کون سا problem solve کر رہے ہیں، اور کس کے لیے؟ یہی چیز زیادہ تر vibe sessions کبھی state نہیں کرتے۔
2. What: done ہونے پر کیا true ہونا چاہیے؟ Behaviours، inputs، outputs، rules، edge cases، اور clearly کیا out of scope ہے۔
3. What not to build: boundaries۔ یہی section زیادہ تر "اس نے بہت زیادہ کر دیا / غلط چیز بنا دی" failures روک دیتا ہے۔

Notice کریں کیا missing ہے: how۔ Spec behaviour describe کرتی ہے، implementation نہیں۔ "Users forgotten password کو 30 minutes بعد expire ہونے والے emailed link سے reset کر سکتے ہیں" spec ہے۔ "JWT اور Postgres tokens table use کریں" implementation ہے، اور plan میں آتا ہے، later phase۔ Beginner mistake یہی ہے کہ دونوں بہت جلد mix ہو جاتے ہیں: آپ behaviour agree کرنے سے پہلے technical choice lock کر دیتے ہیں۔

Spec کی ہر line کا test

پوچھیں: "کیا کوئی competent person اس line کو technically satisfy کر کے بھی غلط چیز build کر سکتا ہے؟" اگر yes، line vague ہے، tighten کریں۔ Spec تب finished نہیں ہوتی جب add کرنے کو کچھ نہ بچے؛ spec تب finished ہوتی ہے جب misread کرنے کو کچھ نہ بچے۔

3. SDD کے تین levels​

SDD all-or-nothing نہیں۔ تین levels ہیں، اور آپ work کی stakes کے حساب سے choose کرتے ہیں۔

Level	اس کا مطلب	کب use کریں
Spec-First	Spec once، upfront لکھیں، پھر اس سے build کریں۔ Spec بعد میں drift کر سکتی ہے۔	Most features۔ Default۔
Spec-Anchored	Spec source of truth رہتی ہے؛ behaviour change ہو تو spec update کرتے ہیں، اور اس سے دوبارہ derive کرتے ہیں۔	Anything you will maintain for months۔
Spec-as-Source	Spec the source ہے؛ code fully regenerated output کی طرح treat ہوتا ہے جسے آپ پھر بھی re-run اور review کرتے ہیں۔	Mature، high-discipline teams and tooling۔

اس course کے لیے Spec-First سے شروع کریں اور Spec-Anchored میں grow کریں۔ Spec-as-Source وہ direction ہے جہاں field جا رہی ہے، مگر first two master کر کے earn کریں۔ Discipline ہر level پر identical ہے؛ صرف یہ بدلتا ہے کہ spec کو sync رکھنے کے بارے میں آپ کتنے strict ہیں۔

---

حصہ 2: Method​

Workflow کی بنیاد ایک چیز ہے (constitution) اور چار phases ہیں: Research → Specify → Clarify → Build۔

Method ایک نظر میں: constitution چار phases کے اوپر بیٹھتی ہے (Research، Specify، Clarify، Build)، اور build کے دوران gap ملے تو واپس spec fix کر کے continue کرتے ہیں۔

4. Constitution: ہر spec کے اوپر rules​

کسی بھی ایک feature سے پہلے آپ تمام features کے لیے persistent rules کی مختصر document لکھتے ہیں: constitution۔ Coding agents میں یہ rules file ہوتی ہے (CLAUDE.md / AGENTS.md)؛ claude.ai میں آپ کی Project instructions۔ Idea everywhere same ہے: principles، constraints، اور conventions جنہیں آپ چاہتے ہیں کہ ہر spec اور build follow کرے۔

ایک honest caveat، کیونکہ use کا طریقہ بدلتا ہے: constitution persistent context ہے، enforced law نہیں۔ Agent اسے ہر session load کرتا ہے اور specific، concise ہونے پر زیادہ reliably follow کرتا ہے، مگر "loaded" کا مطلب "guaranteed" نہیں۔ Must-never rules کے لیے، جیسے production data نہ touch کرنا یا secrets commit نہ کرنا، صرف written rule پر rely نہ کریں؛ tests، pre-commit یا tool hooks، CI checks، tightened permissions، یا human diff review لگائیں۔ Constitution intent set کرتی ہے؛ enforcement ان mechanisms سے آتا ہے۔

Constitution principles ہے، encyclopedia نہیں۔ یہ answer کرتی ہے "یہاں ہمیشہ کیا true ہے؟" نہ کہ "feature X کیسے کام کرتا ہے؟" اسے tight رکھیں؛ AI اسے بار بار re-read کرتا ہے، اس لیے bloat expensive ہے اور important rules bury کر دیتا ہے۔ اچھی constitution lines ایسی لگتی ہیں:

# Constitution — Smart Notes

## Principles

- Plain language over cleverness. A new contributor should understand any file in 5 minutes.
- Prefer well-established libraries over custom code. Research before reinventing.
- Every feature ships with its spec in `specs/`. The spec is the source of truth.

## Constraints

- Stack: keep it to what's already here. Propose, don't add, new dependencies.
- Never touch `published/` or anything in `src/generated/`.

## Definition of done

- Behaviour matches the spec, edge cases included.
- A human has reviewed the diff against the spec before merge.

Too-strict constitution اپنے بعد ہر چیز کو heavy بنا دیتی ہے

Constitution اپنے بعد ہر phase کا tone set کرتی ہے: اگر weekend project کے لیے enterprise-grade testing، performance budgets، اور heavy process مانگے، تو ہر later phase وہ weight inherit کرتا ہے اور to-do app button add کرنے کے بجائے cathedral بن جاتی ہے۔ Constitution کو stakes کے مطابق رکھیں؛ bar بعد میں raise کر سکتے ہیں۔

یہ happen ہوتے دیکھ سکتے ہیں۔ Weekend habit-tracker کو ایسی constitution دیں جو 90% test coverage، performance budget، اور ہر change کے لیے decision record مانگتی ہو، تو first feature benchmark harness، تین layers of abstraction، اور decision log کے ساتھ ship ہوگا: ایک button کے لیے week of process۔ Nobody asked for that؛ constitution نے کیا، اور ہر phase نے weight inherit کیا۔

Opposite failure بھی common ہے: constitution اتنی vague کہ کچھ کہتی ہی نہیں۔ Same project کی تین versions:

Too light (useless)	Too strict (suffocating)	Just right
"Write clean code. Be consistent. Use best practices."	12 rules on test coverage %, performance budgets, commit-message format, and review steps, all for a weekend app	The 6–8 lines above: principles the AI can't infer, constraints that actually bite, one clear "done"

ہر rule کا test spec کی ہر line جیسا ہے: کیا اسے remove کرنے سے AI mistake کر سکتا ہے؟ "Write clean code" fail ہے، کیونکہ AI already کوشش کرتا ہے؛ line کچھ نہیں کرتی۔ "Never touch published/" pass ہے، کیونکہ AI خود یہ نہیں جان سکتا تھا۔

5. Phase 1: لکھنے سے پہلے research​

آپ وہ چیز spec نہیں کر سکتے جسے سمجھتے نہیں۔ Spec کی پہلی line لکھنے سے پہلے AI سے territory map کروائیں: problem، users، constraints، اور existing project کے لیے current code کیسے کام کرتا ہے اور new thing کہاں fit ہونی ہے۔

یہاں power move parallel research ہے: ایک long back-and-forth کے بجائے AI سے کئی questions ایک ساتھ investigate کروائیں اور structured findings doc واپس لیں؛ coding agents میں literal subagents use کرتے ہیں، ہر ایک اپنی context window میں ایک area research کرتا ہے اور summary واپس دیتا ہے، main conversation clean رہتی ہے، وہی context discipline جو Agentic Coding Crash Course میں سیکھی تھی۔

Output code نہیں اور ابھی spec نہیں۔ یہ short findings document ہے: کیا exists، options، unknowns، اور یہی spec کو feed کرتا ہے۔ تینوں tools میں کام آنے والا prompt:

Research what's involved in building [feature]. Investigate these separately and report each on its own: (1) how this kind of thing is usually done, (2) the main approaches and their trade-offs, (3) anything in our existing project it has to fit, (4) the failure modes and edge cases I should worry about. Give me a one-page findings doc: what exists, the options, and what's still unknown. Don't propose a final design or write any code yet.

6. Phase 2: Spec لکھیں (what اور why، کبھی how نہیں)​

اب research پر grounded spec لکھیں۔ Blank page سے شروع نہ کریں: AI کے ساتھ draft کریں، پھر اسے precise بنائیں۔ Concept 2 کے تین questions (why، what، اور what not to build) چھ concrete sections میں expand ہوتے ہیں۔ Workable spec میں minimum یہ ہوتا ہے:

• Goal: why، دو یا تین sentences۔
• User scenarios: "جب user X کرتا ہے، اسے Y ملتا ہے" walkthroughs۔
• Functional requirements: testable musts، ہر ایک اتنا specific کہ اسے ignore کرنے والی build fail ہو۔
• Edge cases & rules: empty، huge، duplicate، malformed، unauthorized input۔
• Out of scope: یہ explicitly کیا نہیں کرتا۔ اسے skip نہ کریں۔
• Acceptance criteria: checklist جو "done" کہتی ہے؛ constitution کی project-wide definition of done اس کے اوپر still apply ہوتی ہے۔

Spec کی anatomy: چھ sections جو behaviour describe کرتے ہیں، اور deliberately no HOW؛ وہ plan میں آتا ہے۔

ایسے prompt سے draft کروائیں، پھر hand-tighten کریں:

Using the research above and our constitution, draft spec.md for [feature]. Include: goal (the why), user scenarios, functional requirements, edge cases & rules, out-of-scope, and acceptance criteria. Describe behaviour only, no databases, frameworks, or file layout. Make each requirement specific enough that a build which ignored it would visibly fail.

"Tighten by hand" کا مطلب۔ Concept 2 کا precision test، real work کرتے ہوئے۔ دیکھیں ایک requirement AI کے wrongly satisfy کر سکنے والی line سے ایسی line تک کیسے جاتی ہے جسے صرف correctly satisfy کیا جا سکتا ہے:

Before: "Users can reset their password."

After: "A signed-out user can request a password reset by email. The link works once, expires after 30 minutes, and a used or expired link shows a 'request a new link' message. The response never reveals whether an email is registered."

First line ایسی build pass کر سکتی تھی جو plaintext password کسی بھی requester کو email کر دے۔ Second line صرف وہ چیز pass کر سکتی ہے جو آپ meant کرتے تھے۔ جو detail آپ چھوڑتے ہیں، AI آپ کی جگہ decide کرتا ہے؛ اس لیے جو matters کرتا ہے اسے یہاں words میں decide کریں۔

Spec کو implementation-free رکھنا ہی آپ کو later tooling کے بارے میں mind change کرنے دیتا ہے بغیر intent rewrite کیے۔

یہ discipline skip کریں تو tool choice accident سے requirement بن جاتی ہے۔ Spec کہتی ہے "uploads S3 میں store کریں"؛ plan اور code follow کرتے ہیں؛ ایک month بعد compliance deal company کے اپنے servers پر storage مانگتی ہے۔ اصل cared-about behaviour، uploads durable اور retrievable رہیں، کبھی written نہیں تھا؛ صرف vendor written تھا۔ Switching پھر plan کی one-line change کے بجائے refactor بن جاتی ہے۔

7. Phase 3: Clarify by interview (AI کو آپ سے پوچھنے دیں)​

یہ highest-value، most-skipped step ہے۔ Build سے پہلے questioning کو reverse کریں: AI کو instruct کرنے کے بجائے اسے آپ کا interview کرنے دیں، تاکہ spec میں چھپی ambiguity reveal ہو۔ ایک prompt زیادہ تر work کر دیتا ہے:

Before we build anything, interview me about this spec. Ask one question at a time, focusing on ambiguities, missing edge cases, and unstated assumptions. Keep going until you could hand this spec to a stranger and trust they'd build exactly what I mean. Don't write any code yet.

آپ حیران ہوں گے کہ کتنی "obvious" چیزیں actually stated نہیں تھیں۔ جو ambiguity آپ یہاں words میں resolve کرتے ہیں، وہ later غلط code delete کر کے resolve نہیں کرنی پڑتی۔ پوری process میں mistake fix کرنے کی یہ cheapest جگہ ہے: spec میں fix ایک sentence ہے؛ implementation کے بعد fix rebuild ہے۔

یہ skip کریں تو questions پھر بھی answer ہوتے ہیں، مگر later، code میں۔ Team spec کرتی ہے "users profile photo upload کر سکتے ہیں"؛ سب nod کرتے ہیں؛ ship ہو جاتا ہے۔ ایک دن میں issues: کسی نے 40 MB TIFF upload کی، size/type limit کبھی stated نہیں تھی؛ دو users ایک دوسرے کی photos overwrite کر گئے، uniqueness rule نہیں تھا؛ broken file site پر blank render ہوئی، fallback نہیں تھا۔ تین unstated assumptions؛ interview ہر ایک کو ایک sentence میں پوچھ لیتا؛ اب ہر ایک bug ہے۔

8. Phase 4: Spec سے build کریں​

Spec agreed ہے۔ اب آپ اس سے build کرتے ہیں، اور process کی مقدار change کے ساتھ scale کرتی ہے۔ ہر بار fixed pipeline نہیں: change جتنی planning مانگے اتنی کریں، پھر build کو spec کے خلاف supervise کریں۔

• ایسا change جو one sentence میں describe ہو سکے (typo، one rule، one new field): بس ask کریں۔ Plan skip کریں۔ One-line fix پر heavy process force کرنا overkill والی same mistake ہے۔
• ایسا change جس میں approach uncertain ہو، یا چند files touch ہوں: plan first۔ Agent سے approach propose کروائیں، اور code سے پہلے review کریں۔
• Multi-file یا architectural change: full loop، plan پھر build پھر verify، work کو small checkable steps میں break کریں۔

ہر size پر دو چیزیں constant رہتی ہیں: code سے پہلے approach review، اور result کو spec کے خلاف check۔ Verify وہ step نہیں جسے skip کیا جائے۔

Work کو tasks میں کون break کرتا ہے؟ Agent کرتا ہے۔ یہی part change ہوا ہے۔ آپ hand-written task list نہیں دیتے۔ Claude Code اور OpenCode work کو اپنے tracked checklist میں decompose کرتے ہیں اور step by step work کرتے ہیں، done mark کرتے جاتے ہیں۔ آپ کا کام breakdown review کرنے اور ہر step کو spec کے خلاف check کرنے میں ہے، list author کرنے میں نہیں۔ (claude.ai میں task tool نہیں، اس لیے plan اور tasks کو Artifacts میں آپ capture کرتے ہیں: یہی وہ one place ہے جہاں old "tasks file لکھیں" still fits.)

Plan (جب change اسے earn کرے):

Based on the agreed spec, propose a technical plan: stack, structure, and the key decisions, each with its trade-off. Match our constitution and reuse what already exists rather than adding new dependencies. Don't write code yet; I'll review the plan first.

Build (supervised):

Implement the agreed plan in small, checkable steps. Do one step at a time, and after each, check it against the spec and stop for me to confirm before the next. Commit after each so every step has a clean rollback point.

Strong model سے plan کریں، cheaper model سے implement

Expensive thinking plan ہے۔ Approach agree ہو جائے تو build "steps follow کرنا" ہے، جو cheaper یا faster model بھی اچھی طرح کرتا ہے۔ Coding agents میں یہ one setting ہے؛ claude.ai میں planning اپنے most capable chat میں کریں اور spec/plan کو handoff بنائیں۔ Agentic Coding Crash Course والا same Plan/Execute split۔

Loop بند کریں: spec کے خلاف verify کریں

Code کا run ہونا یہ نہیں کہ وہ agreed چیز کر رہا ہے۔ اپنی acceptance criteria کو actual checks میں بدلیں (جہاں tests لکھ سکتے ہیں automated tests، جہاں نہیں manual run-through، یا review questions کی short list) اور ہر step کے بعد چلائیں۔ اگر check اس لیے fail ہو کہ spec vague تھی، code غلط نہیں، تو پہلے spec fix کریں، پھر code۔ یہ skip کریں تو SDD quietly اسی چیز میں degrade ہو جاتی ہے جسے روکنے کے لیے بنائی گئی تھی: polished documentation کے ساتھ unverified code۔

Part 2 ایک screen پر​

پورا method، copyable۔ Checklist کا screenshot لیں؛ prompts کو snippet میں رکھیں۔

کیا میری spec done ہے؟

• Goal: why، 2–3 sentences میں
• User scenarios: "جب user X کرتا ہے، اسے Y ملتا ہے"
• Functional requirements: ہر ایک اتنا specific کہ اسے ignore کرنے سے build fail ہو
• Edge cases & rules: empty، huge، duplicate، malformed، unauthorized
• Out of scope: یہ explicitly کیا نہیں کرتا
• Acceptance criteria: checklist جو "done" کہتی ہے
• No HOW: no database، framework، یا file layout؛ وہ plan ہے

چار prompts، order میں:

RESEARCH:  Research what's involved in building [feature]. Investigate separately and
           report each on its own: (1) how this is usually done, (2) the main approaches
           and trade-offs, (3) what in our existing project it must fit, (4) failure modes
           and edge cases. One-page findings doc. No design or code yet.

SPECIFY:   Using the research and our constitution, draft spec.md for [feature]: goal,
           user scenarios, functional requirements, edge cases & rules, out-of-scope,
           acceptance criteria. Behaviour only — no tech choices. Make each requirement
           specific enough that a build ignoring it would visibly fail.

CLARIFY:   Before we build anything, interview me about this spec, one question at a
           time — ambiguities, missing edge cases, unstated assumptions — until there's
           nothing left to misread. No code yet.

BUILD:     Right-size it. Tiny change: just ask. Otherwise: have the agent propose a
           plan and review it, then let it build in small steps, checking each against
           the spec and committing as you go. Turn acceptance criteria into checks.

---

حصہ 3: تین ways​

Same constitution، same four phases، تین places جہاں انہیں run کیا جا سکتا ہے۔ ہم claude.ai سے شروع کرتے ہیں (install کچھ نہیں)، پھر دو coding agents۔

Tools move ہوتے ہیں؛ discipline نہیں

اس part کے specific mechanics، keybindings (Shift+Tab, Tab)، slash commands (/init, /undo)، model names، اور product features (Projects، Artifacts، Canvas، Gems)، جون 2026 تک current ہیں اور shift ہو سکتے ہیں۔ Four-phase discipline نہیں بدلتی۔

ایک discipline، تین homes: same loop claude.ai، Claude Code، اور OpenCode میں چلتا ہے؛ صرف spec کی جگہ بدلتی ہے۔

9. Way 1: claude.ai، main method​

Web app میں آپ کے دو building blocks ہیں: Projects، persistent workspace with custom instructions and uploaded knowledge؛ اور Artifacts، editable documents جو chat کے ساتھ رہتے ہیں۔ SDD ان پر directly map ہوتا ہے۔

Constitution ایک بار set کریں:

1. اپنے کام کے لیے Project بنائیں، مثلاً "Smart Notes"۔
2. Constitution کو Project کی custom instructions میں رکھیں۔ Research، existing docs، یا screenshots کو Project knowledge میں upload کریں تاکہ project کی ہر chat انہیں دیکھ سکے۔

چار phases چلائیں، ہر phase ایک Artifact produce کرے:

• Research → Claude سے investigate کروا کر findings Artifact بنوائیں۔ Web app میں subagents نہیں، اس لیے کئی questions ایک structured document میں cover کرنے کو کہیں۔
• Specify → Claude سے spec.md کو Artifact کے طور پر draft کروائیں۔ Artifact panel میں اسے direct edit کریں جب تک یہ right نہ ہو۔
• Clarify → Concept 7 کا interview prompt paste کریں۔ Questions answer کریں؛ Claude سے answers کو spec Artifact میں fold کروائیں۔
• Build → plan.md Artifact، پھر tasks.md Artifact مانگیں، پھر task by task implement کریں۔ ہر code file اپنا Artifact ہے جسے preview اور download کر سکتے ہیں۔

Project کیوں matter کرتا ہے: constitution اور spec ہر chat میں loaded رہتے ہیں، اس لیے implementation کے لیے fresh conversation کھول سکتے ہیں بغیر project دوبارہ explain کیے۔ Artifacts ہی آپ کی spec files ہیں؛ coding agent پر graduate ہوں تو انہیں repo میں copy کریں۔

ChatGPT اور Gemini same discipline run کر سکتے ہیں

اگر آپ کوئی اور web assistant prefer کرتے ہیں تو discipline carry over ہوتی ہے، mechanics مختلف ہوتے ہیں۔ ChatGPT: constitution کے لیے Projects، editable spec/plan documents کے لیے Canvas۔ Gemini: constitution کے لیے Gem، documents کے لیے Canvas۔ Loop (constitution، پھر Research → Specify → Clarify → Build) same ہے؛ صرف buttons اور project memory کی persistence مختلف ہے۔ claude.ai ہمارا default ہے کیونکہ Artifacts + Projects spec files پر صاف map ہوتے ہیں، مگر یہاں کچھ بھی Claude-only نہیں۔

Browser tool میں کچھ paste کرنے سے پہلے

Chat window آسان ہے، اور یہی risk ہے۔ Private source code، customer data، secrets، credentials، یا confidential business material کسی web assistant میں upload نہ کریں جب تک organization policy allow نہ کرے۔ Sensitive work کے لیے approved environment کے اندر repo-based agent چلائیں اور sanitized، fictional examples use کریں، جیسے نیچے Smart Notes feature کرتا ہے۔ Discipline same ہے؛ data boundary نہیں۔

10. Way 2: Claude Code، repo میں discipline​

جب project real software ہو، Claude Code copy-paste remove کر دیتا ہے: spec، plan، اور tasks آپ کے repo میں files کے طور پر رہتے ہیں، generated code کے ساتھ۔ نیچے native features کافی ہیں، extra frameworks نہیں۔ Chat loop پر جو add ہوتا ہے وہ ہر phase کے لیے built-in machinery ہے:

• Constitution وہ file ہے جسے Claude ہر session پڑھتا ہے۔ CLAUDE.md ہر conversation کے start پر context میں load ہوتی ہے، اس لیے re-paste نہیں؛ مگر اسے hard guarantee نہیں، persistent guidance سمجھیں (Concept 4 کے مطابق must-never rules کو hooks یا tests سے back کریں)۔ /init run کریں، پھر real rules تک trim کریں۔
• Plan mode آپ کا Specify/Clarify gate ہے، enforced۔ Shift+Tab سے plan mode Claude کو read-only بنا دیتا ہے: یہ code study کر سکتا ہے اور spec draft کر سکتا ہے، مگر approve ہونے تک ایک line نہیں لکھ سکتا۔ "Build سے پہلے agree" tool میں built in ہو جاتا ہے۔
• Subagents parallel research کرتے ہیں بغیر main context pollute کیے۔ ہر ایک اپنے window میں one area investigate کرتا ہے اور summary واپس دیتا ہے، اس لیے Phase 1 fast رہتا ہے اور main session lean۔
• Agent اپنی task list maintain کرتا ہے؛ آپ supervise کرتے ہیں۔ Plan approve ہونے کے بعد Claude work کو own tracked checklist میں break کرتا ہے، through work کرتا ہے، ہر item done mark کرتا ہے۔ آپ list author نہیں کرتے؛ آپ breakdown review کرتے ہیں، پھر ہر step کے بعد spec کے خلاف checks run کرتے ہیں اور next سے پہلے commit کرتے ہیں، تاکہ ہر step clean rollback point رکھے۔ Commit-after-each rhythm آپ drive کرتے ہیں؛ اسے constitution میں bake کر سکتے ہیں؛ اگر لازمی ہونا ہو تو hook سے enforce کریں۔

چونکہ چاروں artifacts plain files ہیں، spec version control میں آ جاتی ہے: آپ diff کر سکتے ہیں، pull request میں review کر سکتے ہیں، اور دیکھ سکتے ہیں behaviour کب change ہونا چاہیے تھا۔ یہی jump ہے "ایک spec جو میں نے once لکھی" سے "spec جو repo govern کرتی ہے" تک۔

11. Way 3: OpenCode، any model​

Concept 10 کی ہر چیز OpenCode پر بھی apply ہوتی ہے: rules file (AGENTS.md) constitution کے طور پر (اگر AGENTS.md نہ ہو تو OpenCode existing CLAUDE.md بھی read کرتا ہے)، Plan mode (Tab) read-only gate کے طور پر، research کے لیے subagents، اور build steps کے بیچ git-backed /undo۔ Claude Code کی طرح agent اپنی task list track کرتا ہے اور work through کرتا ہے جبکہ آپ breakdown review کرتے ہیں اور ہر step spec کے خلاف check کرتے ہیں؛ approve کرنے کے بعد Tab Build mode میں toggle کرتا ہے۔ OpenCode ایک چیز add کرتا ہے: model choice، جو SDD کے natural split سے pair ہوتی ہے: spec اور plan phases strong reasoning model کو reward کرتے ہیں، جبکہ clear، agreed task list build کرنا cheap model، جیسے deepseek-v4-flash، پر fine چلتا ہے۔ آپ decide کرتے ہیں کہ "thinking" کا ہر dollar کہاں لگتا ہے۔ دونوں agents کی setup details Agentic Coding Crash Course میں ہیں۔

---

حصہ 4: مکمل worked example​

12. ایک feature، start to finish، دو بار​

چلیں whole loop ایک small، real feature پر run کرتے ہیں: "weekly digest" جو ہر Monday ہر user کو اس کے notes کا summary email کرے۔ یہ کئی files touch کرتا ہے (scheduled job، notes query، mailer)، اس لیے Concept 8 کے right-sizing rule کے مطابق full loop earn کرتا ہے۔ ہم اسے دو بار کرتے ہیں: پہلے claude.ai میں جہاں thinking visible ہے، پھر Claude Code میں جہاں loop real repo files کے خلاف چلتا ہے۔

claude.ai میں

Phase 0: Constitution (Project میں already set). Principles: plain language، existing libraries prefer، ہر feature spec کے ساتھ ship، published/ کو کبھی touch نہ کریں۔

Phase 1: Research۔ Prompt:

Research what's involved in a "weekly digest email" for our notes app. Cover: how we'd select which notes to include, scheduling options, email-sending approaches, and the main failure modes (no notes that week, send failures, time zones). Give me a one-page findings doc. Don't propose a final design yet.

Claude findings Artifact واپس دیتا ہے۔ آپ skim کرتے ہیں؛ time-zone question وہ ہے جس پر آپ نے غور نہیں کیا تھا۔

Phase 2: Specify۔ Prompt:

Using those findings and our constitution, draft spec.md for the weekly digest. Include goal, user scenarios, functional requirements, edge cases, out-of-scope, and acceptance criteria. Describe behaviour only, no tech choices yet.

آپ کو spec Artifact ملتا ہے۔ یہ good ہے، مگر کچھ جگہ generic۔

Phase 3: Clarify۔ Prompt:

Before we plan anything, interview me about this spec, one question at a time, until there's nothing left to misread.

Interview وہ decisions surface کرتا ہے جو آپ نے state نہیں کیے تھے: digests user کے local Monday use کرتے ہیں، UTC نہیں؛ zero notes والی week empty email نہیں بھیجتی؛ unsubscribed users skip ہوتے ہیں۔ آپ answer کرتے ہیں؛ Claude ہر answer spec Artifact میں fold کرتا ہے۔ یہ وہ moment ہے جہاں SDD earn کرتی ہے: three future bugs just died as sentences۔

Phase 4: Build۔

Now write plan.md: the technical approach for this spec, given our existing stack. Then tasks.md: an ordered, checkable task list.

آپ plan review کرتے ہیں، یہ existing mailer reuse کرتا ہے اور constitution match کرتا ہے؛ approve کرتے ہیں؛ پھر task by task implement کرتے ہیں، ہر task spec کے خلاف check کرتے اور save کرتے ہیں۔ جب task دکھاتا ہے کہ spec کسی چیز پر silent تھی، مثلاً email subject line، تو آپ spec پہلے update کرتے ہیں، پھر continue۔ Spec true رہتی ہے۔

Same feature، Claude Code میں

Same four phases، same prompts؛ فرق یہ ہے کہ ہر artifact file ہے اور tool وہ gates enforce کرتا ہے جو browser میں آپ خود impose کر رہے تھے۔

• Research: one findings doc کے بجائے subagents spin up کریں، one per area، تاکہ main session lean رہے۔ Findings specs/weekly-digest/research.md میں land ہوتے ہیں۔
• Specify: Shift+Tab سے plan mode میں جائیں (read-only): "ابھی build نہ کرو" rule اب tool enforce کرتا ہے، willpower نہیں۔
• Build: Claude work کو اپنی tracked task list میں plan کرتا ہے اور build کرتا ہے؛ آپ ہر step spec کے خلاف review کرتے اور commit کرتے ہیں، اس لیے git log task list جیسا پڑھتا ہے اور ہر step clean rollback point ہے۔

One real difference یہ ہے کہ spec آخر کہاں جاتی ہے: claude.ai میں یہ Artifact تھی جسے آپ copy forward کرتے ہیں؛ Claude Code میں یہ specs/ میں رہتی ہے، version-controlled، produced code کے ساتھ۔ OpenCode identical ہے: CLAUDE.md کو AGENTS.md سے، اور Shift+Tab کو Tab سے swap کریں۔

Result صرف working code نہیں؛ یہ working code plus ایسی spec ہے جو اسے explain اور govern کرتی ہے، next person، یا future you، کے لیے safe change ready۔

Artifacts کی shape دیکھیں: compact spec.md, plan.md, اور tasks.md

Method abstract رہتا ہے جب تک آپ نہ دیکھیں اس سے نکلتا کیا ہے۔ یہاں تین artifacts کی trimmed versions ہیں تاکہ shape visible ہو۔ claude.ai میں آپ تینوں Artifacts بناتے ہیں؛ coding agent کے ساتھ spec.md اور plan.md files میں رکھتے ہیں، جبکہ task list عموماً agent کی اپنی ہوتی ہے۔ یہاں written out ہے تاکہ good one visible ہو۔ Real versions longer ہوتے ہیں؛ shape matter کرتی ہے۔

# spec.md — Weekly Digest

## Goal

Email each user a once-a-week summary of their own notes so they
re-engage without opening the app. Reduce silent churn.

## User Scenarios

- A user with notes this week gets a Monday-morning digest listing them.
- A user with no notes this week gets nothing (not an empty email).
- An unsubscribed user gets nothing, ever.

## Functional Requirements

FR-1 Digest sends on the user's local Monday at 8:00am.
FR-2 Include only notes created or edited in the prior 7 days.
FR-3 Zero qualifying notes → no email is sent.
FR-4 Unsubscribed users are skipped.
FR-5 A send failure is retried once, then logged; it never blocks others.

## Edge Cases & Rules

- Time zone missing → fall back to UTC.
- 50+ notes → list the 10 most recent, then "and N more."

## Out of Scope

- Digest customization, frequency options, non-email channels.

## Acceptance Criteria

- [ ] A user in Asia/Karachi receives the digest at their local Monday 8am.
- [ ] An empty week sends no email (verified in logs).
- [ ] Unsubscribed users receive nothing.
- [ ] One simulated send failure retries once, then logs, others still send.

# plan.md — Weekly Digest

## Approach

Reuse the existing mailer service (constitution: prefer what exists).
A scheduled job runs hourly, selects users whose local time is Mon 08:00,
builds the digest from the notes query, and hands it to the mailer.

## Key Decisions

- Scheduling: hourly cron + per-user timezone check (no per-user timers).
- Templating: reuse existing email template system.
- Failure handling: wrap each send; retry-once lives in the job, not the mailer.

## Touch Points

- new: jobs/weekly_digest.\* | reuse: services/mailer, models/note
- no schema change required

# tasks.md — Weekly Digest

1. Note-selection query: notes per user from the last 7 days. [FR-2]
2. Eligibility check: local Monday 08:00 + subscribed. [FR-1, FR-4]
3. Digest builder: top 10 + "and N more"; skip if empty. [FR-3, edge]
4. Wire to mailer with retry-once + logging. [FR-5]
5. Tests for each acceptance criterion. [Verify]

Threads notice کریں: ہر task وہ requirement cite کرتا ہے جسے satisfy کرتا ہے، اور final task verification ہے، directly acceptance criteria سے derived۔

---

حصہ 5: Judgment​

13. SDD کب pays off کرتی ہے، اور کب overkill ہے​

SDD discipline ہے، اور discipline کی cost ہوتی ہے: Specify اور Clarify slow feel ہوں گے، tens of minutes of thinking، جہاں vibe coding already code دکھا رہی ہوتی۔ یہی وہ trade ہے جو آپ کر رہے ہیں؛ beginners method کو exactly اس moment abandon کرتے ہیں جب یہ worst feel ہوتی ہے، payoff سے ذرا پہلے۔ One-line fix پر اسے spend کرنا اتنا ہی wrong ہے جتنا payment system پر اسے skip کرنا۔ Skill یہ جاننا ہے کہ کون سا case کون سا ہے۔

SDD تب use کریں جب…	اسے skip کریں (just vibe) جب…
Work multiple files، modules، یا data touch کرے	یہ one-off script یا tiny tweak ہو
کوئی اور، یا future-you، اسے maintain کرے	آپ result آج ہی پھینک دیں
غلطی expensive ہو (money، data، trust)	Wrong guess کی cost صرف "undo press" ہو
Requirements fuzzy ہوں اور pin down کرنے ہوں	Task one sentence میں fully clear ہو
کئی لوگوں کو "done" پر agree کرنا ہو	آپ explore کر رہے ہوں تاکہ جانیں کیا چاہتے ہیں

"Make this button blue" کو full constitution-to-implement process سے گزارنا absurd ہے۔ مگر جس moment task state، permissions، data models، money، یا کسی اور کی expectations involve کرے، structure اپنا cost pay کرنا شروع کر دیتی ہے، اور جتنی دیر چیز زندہ رہتی ہے اتنا زیادہ pay کرتی ہے۔

Threshold جان بوجھ کر low ہے: tiny throwaway work left پر رہتا ہے، مگر زیادہ تر work جسے آپ keep کرتے ہیں right پر land کرتا ہے، جہاں spec pay off کرتی ہے۔

First-time correctness سے beyond second payoff بھی ہے: یہ آپ کو unstuck کرتی ہے۔ Anthropic session data میں، جب build sideways گئی، least-experienced users نے troubled sessions abandon کر دیے، باقی users کے مقابلے several times زیادہ rate پر؛ experience کا main benefit agent کو back on track steer کرنے کی ability تھا۔ Agreed spec steering wheel ہے: جب کچھ break ہو، آپ کے پاس debug کے لیے fixed point ہے، vague memory نہیں۔ Recovery move concrete ہے: جب agent mid-build spec سے drift کرے تو ignored specific requirement (FR) paste کر کے re-ground کریں، task کو shrink کر کے صرف اسی one thing تک لائیں، پھر acceptance criteria کی طرف point کریں۔

Spec کو alive رکھیں (وہ part جو سب بھولتے ہیں). Spec source of truth صرف تب ہے جب true رہے۔ Behaviour change ہو (new rule، removed feature، fixed edge case)، تو spec first change کریں، پھر code re-derive کریں۔ یہی move Spec-First کو Spec-Anchored بناتی ہے، اور spec کو time کے ساتھ زیادہ valuable بناتی ہے، نہ کہ repo میں ایک month کے اندر lie۔

Drift practice میں کیسی لگتی ہے: کوئی digest email کی subject line directly code میں tweak کر کے ship کرتا ہے۔ Spec ابھی old subject describe کرتی ہے۔ تین weeks بعد new teammate spec پڑھتا ہے، code کو spec match کرنے کے لیے "fix" کرتا ہے، اور quietly working thing break کر دیتا ہے۔ Nobody lied؛ spec true رہنا بند ہو گئی تھی، اور bug سے پتا چلا۔ Fix cheap اور boring ہے: code کے same commit میں spec.md بھی change ہوتا ہے، every time۔

جب specs بہت زیادہ ہوں تو کیا change ہوتا ہے۔ ایک spec document ہے؛ dozens کا folder system ہے۔ Whole specs/ directory کے ساتھ live question "کیا یہ spec clear ہے؟" نہیں رہتا، بلکہ "کیا یہ specs ابھی بھی agree کرتے ہیں؟" بن جاتا ہے۔ Features interact کرتے ہیں، ایک change دوسرے specs میں ripple کر سکتا ہے، اور جب دو specs conflicting choices کی طرف point کریں تو constitution ہی اسے settle کرتی ہے۔ Specs کے پورے set کو consistent رکھنا ہی real jump ہے "میں feature spec کر سکتا ہوں" سے "میں repo SDD پر چلاتا ہوں" تک۔

---

Practice​

SDD پڑھنا SDD سیکھنا نہیں۔ Discipline صرف تب آپ کی بنتی ہے جب آپ full loop کسی real چیز پر run کرتے ہیں اور Clarify phase کو ایسی mistake catch کرتے محسوس کرتے ہیں جو آپ otherwise ship کر دیتے۔ یہ order میں کریں۔ ہر one stakes raise کرتا ہے، اور deliberately "just vibe it" line سے آگے ہے تاکہ structure کو earn کرنا پڑے۔

ہر project کے لیے same four artifacts produce کریں (constitution, spec.md, plan.md, tasks.md) plus working result۔ Single success test Concept 2 والا ہے: کیا stranger آپ کی spec alone سے، ایک question پوچھے بغیر، right thing build کر سکتا ہے؟

Warm-up: interview محسوس کریں (claude.ai, ~30 min). وہ smallest real چیز pick کریں جو آپ build کرنا چاہتے تھے: study planner، CSV-to-summary tool، habit tracker۔ Project بنائیں، three-line constitution paste کریں، اور four phases run کریں۔ One rule: Concept 7 skip نہ کریں۔ کسی code سے پہلے Claude سے interview کروائیں۔ Count کریں کتنے decisions سامنے آئے جو آپ نے state کرنے کا سوچا ہی نہیں تھا۔ یہی number ہے جس کی وجہ سے SDD exists کرتی ہے۔

Project 1: real rules والا feature (claude.ai, ~1 hr). Smart Notes کے لیے "tag and filter" feature spec اور build کریں (worked example والی app): users notes میں tags add کرتے ہیں اور ان سے filter کرتے ہیں۔ یہ trivial لگتا ہے جب تک آپ اسے spec نہ کریں، اور یہی point ہے۔ Edge cases کو spec میں pin down کریں: no tags؟ duplicate tags؟ filter nothing match کرے؟ case sensitivity؟ in-use tag rename؟ Done when implementation کی first line سے پہلے spec ان پانچوں کا answer دیتی ہے۔

Project 2: اسے repo میں move کریں (Claude Code یا OpenCode, ~2 hrs). Project 1 کو chat window سے باہر نکالیں اور same loop coding agent میں run کریں۔ Constitution کو CLAUDE.md / AGENTS.md میں رکھیں، spec.md, plan.md, اور tasks.md کو repo files میں رکھیں، اور plan mode کو specify/clarify gate بنائیں۔ One task at a time implement کریں، ہر task کے بعد commit۔ Done when git log one clean commit per task دکھاتا ہے اور spec version control میں produced code کے ساتھ رہتی ہے۔

Project 3: spec کو alive رکھیں (hard one, ~1 hr). اب mind change کریں۔ Project 2 میں new requirement add کریں: مثلاً tags colour-coded ہو سکتے ہیں، یا filtering "any of" اور "all of" modes support کرتی ہے۔ Agent کو simply add کرنے کی urge resist کریں۔ Instead: spec.md پہلے edit کریں، changed section پر Clarify دوبارہ run کریں، plan اور tasks update کریں، پھر implement کریں۔ Done when spec.md کا diff اور code کا diff same story بتاتے ہیں۔ یہی move Spec-First کو Spec-Anchored بناتی ہے، اور یہی وہ چیز ہے جس کی practice most people نہیں کرتے۔

Project 4: ایسے code میں work کریں جو آپ نے نہیں لکھا (Claude Code یا OpenCode, ~2 hrs). Brand-new project easy case ہے۔ کوئی small open-source project clone کریں جو آپ نے پہلے نہیں دیکھا، یا کسی اور کا repo pick کریں، اور SDD سے one modest feature add کریں۔ اس بار Phase 1 weight اٹھاتا ہے: spec سے پہلے agent سے research کروائیں کہ existing code کیسے structured ہے، feature کہاں fit ہو گا، کون سی conventions respect کرنی ہیں؛ subagents use کریں تاکہ ہر ایک area map کر کے report کرے۔ Spec میں "fits the existing system" section ہونا چاہیے جو matching patterns name کرے۔ Done when feature ایسے read ہو جیسے ہمیشہ codebase کا part تھا، bolt-on نہیں، اور spec explain کرتی ہے why it fits۔

Project 5: SDD without code (claude.ai, ~45 min). خود prove کریں کہ یہ thinking discipline ہے، coding نہیں (Concept "not a programmer"). App نہیں، repeatable process pick کریں: raw notes سے weekly status report، content-repurposing pipeline، inbox-triage routine، submissions پر grading rubric۔ Exact same loop run کریں (constitution، research، spec، clarify، build) جہاں "build" process اور prompts produce کرتا ہے، source code نہیں۔ Done when آپ، یا teammate، spec سے process run کر کے ہر بار consistent result لے سکے، no improvisation۔

Project 6: stranger test، real capstone (~1.5 hrs). اب تک آپ نے خود check کیا، جو weakest reviewer ہے؛ آپ جانتے ہیں آپ کا مطلب کیا تھا۔ خود کو remove کریں۔ Feature کے لیے spec لکھیں، پھر اسے fresh، empty AI session (brand-new chat with no memory) یا peer کو دیں، اور zero questions allowed کے ساتھ build کروائیں۔ جہاں وہ غلط چیز build کرے، fault spec کا ہے، builder کا نہیں: spec fix کریں، code نہیں، پھر دوبارہ try کریں۔ Done when cold reader first pass پر وہی build کرے جو آپ actually meant کرتے تھے۔ یہ pass کر لیا تو real skill آ گئی: intent کو اتنی precision سے لکھنا کہ وہ آپ کے head سے نکل کر survive کرے۔

---

یہ آگے کہاں لے جاتا ہے​

اب آپ کے پاس پوری discipline ہے: what پر agree کریں before you generate how، spec کو source of truth رکھیں، اور constitution → Research → Specify → Clarify → Build loop کو اس tool میں run کریں جو moment fit کرے۔

یہ book میں باقی ہر چیز کے نیچے thinking layer ہے۔ آپ نے coding tools، Claude Code اور OpenCode، Agentic Coding Crash Course میں دیکھے جو یہ loop run کرتے ہیں، اور discipline کو Cowork Crash Course میں work کرتے دیکھا؛ mechanics کے لیے دونوں revisit کریں۔ یہاں سے Mode tracks اس loop کو work پر لگاتے ہیں: آپ جو بھی build course لیتے ہیں، Python in the AI Era, Build AI Agents, AI Searchable Context, اور Building a Digital FTE, یہی loop ہے، bigger and bigger systems پر applied۔

Book کی thesis یاد رکھیں: General Agents build Custom Agents۔ Spec-Driven Development وہ how ہے جس سے آپ general agent کو hard problem پر point کرتے ہیں اور guesses کے ڈھیر کے بجائے reliable system واپس لیتے ہیں۔

---

Flashcards Study Aid

---

Test Your Understanding

جو کچھ آپ نے سیکھا اسے test کریں۔ ہر session میں 18 questions کی fresh set دکھتی ہے، اس لیے ہر retake پر نئے questions ملتے ہیں۔

Checking access...