নিজের নিয়ন্ত্রণাধীন Git রিপোজিটরিতে বড় পরিবর্তন করতে Superpowers একজন Claude Code ব্যবহারকারীকে পথ দেখাতে পারে: নকশায় সম্মত হওয়া, কাজের পরিকল্পনা অনুমোদন, পরীক্ষা সহ বাস্তবায়ন, প্রতিটি কাজের পর্যালোচনা এবং সম্পন্ন ব্রাঞ্চ পরীক্ষা। এই নির্দেশিকা ২০ অক্টোবর ২০২৬-এ যাচাই করা সরকারি Superpowers 7.0.0 ম্যানুয়াল অনুসরণ করে। BIG CHANGE নথি পর্যালোচনা করেছে; আমরা প্লাগইন ইনস্টল করিনি বা এটি দিয়ে কোনো প্রকল্প চালাইনি।

বড় পরিবর্তন

  • কী বদলেছে: অনুমোদিত নকশা ও বাস্তবায়ন পরিকল্পনা রিপোজিটরি সম্পাদনার আগে কোডিং এজেন্টকে নির্দিষ্ট কাজ ও সীমা দেয়।
  • কেন গুরুত্বপূর্ণ: নথিতে বর্ণিত কাজের প্রবাহে দেখা ব্যর্থ ও সফল পরীক্ষার সঙ্গে একজন পর্যালোচকের পৃথক স্পেসিফিকেশন ও গুণমানের রায় যুক্ত হয়, তারপর পুরো ব্রাঞ্চের বৃহত্তর পর্যালোচনা হয়।
  • কী খেয়াল রাখবেন: মালিক এখনো সম্পূর্ণ diff ও নতুন গ্রহণযোগ্যতা পরীক্ষার ফল যাচাই করেন এবং ব্রাঞ্চের পরবর্তী পদক্ষেপ ঠিক করেন। এজেন্টের কাজ শেষ হলেও প্রকাশ করা পর্যবেক্ষণ বাকি থাকতে পারে।

শুরু করার আগে

আপনার মালিকানাধীন বা সম্পাদনার অনুমতি থাকা রিপোজিটরিতে একটি অনুমোদিত, একাধিক ধাপের কোড পরিবর্তন বেছে নিন। সেটি পর্যালোচনাযোগ্য কাজে ভাগ করা এবং তার আচরণ পরীক্ষা করা সম্ভব হতে হবে। প্রত্যাশিত আচরণ, প্রভাবিত অংশ, বাদ দেওয়া কাজ, মূল গ্রহণযোগ্যতা কমান্ড ও শুরুর commit লিখুন। কাজের আগে সেই কমান্ড ও প্রাসঙ্গিক বিদ্যমান পরীক্ষা চালান। প্রাথমিক অবস্থায় পরীক্ষা ব্যর্থ হলে এখনই ব্যর্থতা শনাক্ত করুন; পরের সফল বা ব্যর্থ ফল বুঝতে পরিচিত শুরুর অবস্থা প্রয়োজন।

আপনার Git, প্রমাণীকৃত Claude Code ইনস্টলেশন, প্লাগইন ইনস্টল ও branch বা worktree তৈরির অনুমতি এবং Claude Code ও তার উপ-এজেন্টের জন্য যথেষ্ট প্ল্যান বা API সক্ষমতা দরকার। সোর্স কোডে প্রবেশ ও প্লাগইন ব্যবহারের সাংগঠনিক নিয়ম দেখুন। চালু করার আগে প্লাগইনের বিষয়বস্তু, কার্যকর অনুমতি, সরবরাহকারীর তথ্যের শর্ত ও ব্যয় নিয়ন্ত্রণ পর্যালোচনা করুন। Anthropic সতর্ক করে যে প্লাগইনের hooks ও server processes, tool-call sandbox-এর বাইরে আপনার ব্যবহারকারীর অধিকারে চলতে পারে; সাধারণ tool permission prompts এই সব কোডকে নিয়ন্ত্রণ করে না। গোপন তথ্য, dependencies, বাহ্যিক writes, pushes ও releases নিজের প্রকৃত ক্ষমতার মধ্যে রাখুন। Claude Code-এর প্লাগইন নিরাপত্তা নথি এই সীমা ব্যাখ্যা করে।

নিচের পথে একাধিক কাজের পরিবর্তনের জন্য Superpowers-এর subagent-driven-development দক্ষতা ব্যবহার করা হয়। ম্যানুয়াল একটি inline executing-plans পথও বর্ণনা করে এবং ছোট কাজে সহজ নকশা-সম্মতির অনুমতি দেয়। প্রতিটি প্রকল্পে পুরো ক্রম লাগবে ধরে না নিয়ে বাস্তবায়নের আগে মালিকের সঙ্গে পথ বেছে নিন।

১. প্লাগইন ইনস্টল করুন ও সক্রিয় সংস্করণ যাচাই করুন

একটি ইন্টারঅ্যাকটিভ Claude Code সেশনে লিখুন সরকারি marketplace কমান্ড:

Text
/plugin install superpowers@claude-plugins-official

ইনস্টলের আগে Claude Code প্লাগইনের বিস্তারিত প্যানেল খোলে। বিষয়বস্তু দেখুন এবং অনুমোদিত scope বেছে নিন। Local scope এই রিপোজিটরিতে আপনার জন্য এটি সক্রিয় করে; project scope সহযোগীদের রিপোজিটরি সেটিংসকে প্রভাবিত করে। ইনস্টলের সারাংশ ও Errors ট্যাব পড়ুন। সেশনের সক্রিয় করার নির্দেশ মানুন বা আবার চালু করুন, তারপর Installed ট্যাব দেখুন এবং shell-এ চালান claude plugin list । প্রদর্শিত Version, Scope ও Status লিখুন এবং সক্রিয় সেশনে Superpowers দক্ষতা আছে নিশ্চিত করুন। marketplace কমান্ড এই নির্দেশিকার গবেষণায় ব্যবহৃত commit নির্দিষ্ট করে না। ইনস্টল করা সংস্করণ বা দক্ষতার লেখা 7.0.0 থেকে আলাদা হলে এগোনোর আগে সেই সংস্করণের সঙ্গে প্রক্রিয়া মিলিয়ে নিন। ব্যর্থ বা নিষ্ক্রিয় ইনস্টলে থামুন; তা কাজের প্রবাহ লোড হওয়ার প্রমাণ নয়। Claude Code-এর ইনস্টল নির্দেশিকা এসব যাচাই নথিভুক্ত করে।

২. আগে নকশা, তারপর পরিকল্পনা অনুমোদন করুন

Claude Code-কে আসল পরিবর্তন, গ্রহণযোগ্যতার শর্ত, প্রাথমিক ফল ও নিষিদ্ধ সম্পাদনা বলুন। উদ্দেশ্য, নকশার বিকল্প ও সীমা ঠিক করতে Superpowers-এর brainstorming প্রক্রিয়া ব্যবহার করুন। এই একাধিক ধাপের পরিবর্তনে লিখিত নকশা ও builder-check-এর পর্যবেক্ষণ দেখুন, মালিকের সিদ্ধান্তের প্রশ্ন মেটান এবং সম্পূর্ণ বিবরণ অনুমোদন করুন। কী আচরণ তৈরি হবে তা অনুমোদনে স্পষ্ট থাকা উচিত; এজেন্ট কথা চালিয়ে যাচ্ছে মানেই অনুমোদন নয়। নকশার ম্যানুয়াল ছোট কাজে হালকা সম্মতি বা স্পষ্ট opt-out-এর অনুমতি দেয়, তাই এখানে বড় কাজের জন্য পুরো পথ সচেতনভাবে বেছে নেওয়া হয়েছে।

এরপর writing-plans প্রক্রিয়াকে সেই নকশা কাজে ভাগ করতে বলুন। পরিকল্পনার ফাইলের সীমানা, interfaces, সামগ্রিক সীমা, পরীক্ষার কমান্ড ও Review Focus পর্যালোচনা করুন। প্রতিটি কাজ দেখার মতো ছোট হোক এবং তার পরীক্ষা সম্মত আচরণ মাপুক। কোড পরিবর্তনের আগে পরিকল্পনা ও উপ-এজেন্টের বাস্তবায়ন পদ্ধতি অনুমোদন করুন। পরিকল্পনার ম্যানুয়াল হস্তান্তর নির্ধারণ করে। যুক্তিসংগত পরিকল্পনাকে dependencies যোগ বা অসংশ্লিষ্ট ফাইল পাল্টানোর অনুমতি ভাববেন না।

কাজের সময় using-git-worktrees উপযুক্ত বিদ্যমান workspace খোঁজে বা প্রয়োজনীয় সম্মতি নিয়ে আলাদা workspace তৈরি করে। প্রকৃত branch, base commit ও পরিষ্কার প্রাথমিক অবস্থা লিখুন। যেখানে আছে Claude Code-এর নিজস্ব worktree সুবিধা ব্যবহার করুন। workspace-এ অন্য কাজের সম্পাদনা থাকলে এগোনোর আগে তার মালিকানা মেটান। worktree ম্যানুয়াল যাচাই ও তৈরির পথ ব্যাখ্যা করে।

৩. প্রতিটি পরীক্ষা ও কাজের পর্যালোচনা দেখুন

অনুমোদিত পরিকল্পনা নিয়ে subagent-driven-development ব্যবহার করুন স্বাধীনভাবে পর্যালোচনাযোগ্য কাজে। বর্তমান ম্যানুয়াল একটি কাজের জন্য বাস্তবায়নকারী দেয়, তারপর বাস্তবায়ন ও তার diff পাঠায় একজন কাজের পর্যালোচকের কাছে । তিনি দুটি রায় দেন: কাজটি স্পেসিফিকেশন মেনেছে কি না এবং বাস্তবায়নের গুণমান গ্রহণযোগ্য কি না। এগুলো একটি পর্যালোচনার দুটি রায়, পরপর দুজন পর্যালোচক এজেন্ট নয়। একই ধরনের ছোট কাজ ম্যানুয়ালের নিয়মে একসঙ্গে করা যায়। কাজের প্রবাহ ও পর্যালোচকের নির্দেশ এই ক্রম নির্ধারণ করে।

আগে পরীক্ষা লেখা উপযুক্ত এমন প্রতিটি আচরণের জন্য দেখা যায় এমন red-green চক্র চাইুন: আচরণের পরীক্ষা যোগ করুন, চালিয়ে প্রত্যাশিত ব্যর্থতা দেখুন; ক্ষুদ্রতম বাস্তবায়ন করুন, আবার চালিয়ে সাফল্য দেখুন; তারপর সব পরীক্ষা সফল রেখে refactor করুন। import error বা নষ্ট test harness প্রত্যাশিত red ফল নয়। প্রতি কাজের কমান্ড, output ও প্রাসঙ্গিক commit বা diff রাখুন। test-driven-development ম্যানুয়াল মানুষের সম্মতি দরকার এমন ব্যতিক্রম বর্ণনা করে; এই নির্দেশিকা স্বাভাবিক test-first পথের উপযুক্ত কাজ ধরে।

পর্যালোচকের দুটি রায় ও প্রকৃত diff পড়ুন। কাজ গ্রহণের আগে “diff থেকে যাচাই করা যায় না” এমন প্রতিটি বিষয় পরিকল্পনা ও রিপোজিটরি দেখে মেটান। সংশোধন ও তার সীমিত পুনঃপর্যালোচনা দেখুন; সাফল্যের নতুন দাবিকে নতুন পরীক্ষার ফল ভাববেন না। 7.0.0 প্রবাহে সংশোধন চক্র সীমিত এবং লিখিত সিদ্ধান্ত দিয়ে পর্যবেক্ষণ স্থগিত রাখা যায়। পরে পর্যালোচনার জন্য সেগুলো রাখুন। কাজ complete দেখালেও তার পর্যালোচনা সমস্যামুক্ত নাও হতে পারে।

কাজগুলো শেষ হলে দেখুন পুরো ব্রাঞ্চের আলাদা পর্যালোচনা । এটি কাজগুলোর পারস্পরিক প্রভাব শনাক্ত এবং একটি diff থেকে কাজের পর্যালোচক মেটাতে না পারা স্থগিত বিষয় পুনরায় দেখতে পারে। খোলা প্রতিটি সমস্যার প্রমাণ ও সিদ্ধান্ত চাইুন। প্লাগইনের অস্থায়ী workspace পরিষ্কারের আগে নকশা, পরিকল্পনা, পরীক্ষার output, পর্যালোচনার রিপোর্ট ও পুরো diff রাখুন। প্রত্যাশিত দক্ষতা চালু না হলে সক্রিয় প্লাগইনের status ও version এবং নথির সমস্যা নির্ণয়ের পথ দেখুন; শুধু ইনস্টল করা হয়েছে বলে প্রবাহ কার্যকর হয়েছে ভাববেন না।

৪. ব্রাঞ্চ যাচাই করে পরবর্তী পদক্ষেপ বেছে নিন

চূড়ান্ত কোডে মূল গ্রহণযোগ্যতা কমান্ড ও প্রকল্পের পুরো test suite আবার চালান। নতুন output, সম্পূর্ণ branch-এর diff ও বাকি সব পর্যবেক্ষণ দেখুন। Superpowers-এর যাচাই ম্যানুয়াল কাজ সম্পন্ন দাবির আগে বর্তমান অবস্থার প্রমাণ চায়। suite ব্যর্থ হলে নির্দিষ্ট ব্যর্থতা শনাক্ত করে ঠিক করুন বা branch পর্যালোচনার জন্য রাখুন; ব্যর্থ suite-এ নথির branch-finish menu আসে না।

নামযুক্ত branch-এ finishing-a-development-branch local merge, push করে pull request তৈরি বা branch যেমন আছে রেখে দেওয়ার বিকল্প দেয়। detached HEAD-এ pull-request ও keep বিকল্প থাকে। Discard কেবল মালিকের স্পষ্ট অনুরোধ ও টাইপ করা নিশ্চয়তার পর হয়; এটি সাধারণ চতুর্থ বিকল্প নয়। ব্রাঞ্চ শেষ করার ম্যানুয়াল এই বিকল্পগুলো বর্ণনা করে। মালিকের সিদ্ধান্তের আগে তাঁকে পরীক্ষা, diff ও অবশিষ্ট পর্যবেক্ষণ দেখান। merge, push, deletion বা release-এর জন্য সেই কাজের উপযুক্ত ক্ষমতা লাগে।

উপযোগী ফল হলো মূল প্রয়োজনের সঙ্গে যুক্ত একটি পর্যালোচনাযোগ্য branch: অনুমোদিত নকশা ও পরিকল্পনা, দেখা পরীক্ষার ফল, কাজের পর্যালোচনার দুটি রায়, পুরো branch-এর পর্যালোচনা, সম্পূর্ণ diff ও নতুন গ্রহণযোগ্যতার ফল। ইনস্টল, প্রবেশ, বাজেট বা পরীক্ষা কাজ থামালে যাচাই করা উপকরণ রাখুন এবং শেষ সম্পন্ন ধাপ বলুন। নথি প্রক্রিয়া বর্ণনা করে; এই নির্দেশিকার না চালানো পরিবর্তন কম সময়ে, কম খরচে বা কম ত্রুটিতে হয়েছে তা প্রতিষ্ঠা করে না।

উৎস ও আরও পড়ুন

আরও সীমিত একটি সম্মত পরীক্ষার ত্রুটি সারানোর জন্য দেখুন BIG CHANGE-এর রিপোজিটরির একটি ব্যর্থ পরীক্ষা যাচাইয়ের নির্দেশিকা । এখানকার প্রক্রিয়া আরও আগে শুরু হয়, একাধিক কাজের পরিবর্তনের নকশা ও পরিকল্পনা থেকে।