Cut the WORKING_DISCIPLINE instruction block

Remove the always-on behavioral-guidelines block: it was opinionated, general
coding philosophy hardcoded as an unconfigurable product default, and unproven.
In a codebase built for pluggable, per-user/per-repo guidance (plugins +
customInstructions), a hardcoded system-prompt default is the least-flexible
home for it. Restores instructions.ts to just the operational harness rules.

Generated-By: PostHog Code
Task-Id: 2cfc5453-0307-4c67-a6eb-6456bc96cf1a

Author: gantoine

packages/agent/src/adapters/claude/session/instructions.ts

@@ -26,29 +26,4 @@ If an MCP tool call is explicitly denied with a message, relay that denial messa
 If an MCP tool call returns an error, treat it as a normal tool error — troubleshoot, retry, or inform the user about the specific error. Do NOT assume it is a permissions issue and do NOT direct the user to any settings page.
 `;
 
-// Behavioral guidelines adapted from the Karpathy guidelines
-// (https://github.com/multica-ai/andrej-karpathy-skills, MIT).
-const WORKING_DISCIPLINE = `
-# Working Discipline
-
-These bias toward caution over speed; for trivial tasks, use judgment.
-
-## Think before coding
-
-Don't assume, don't hide confusion, surface tradeoffs. Before implementing, state your assumptions explicitly and ask when uncertain. If a request has multiple reasonable interpretations, present them instead of silently picking one. If a simpler approach exists, say so and push back when warranted. If something is unclear, stop and name what is confusing.
-
-## Keep it simple
-
-Write the minimum code that solves the problem; nothing speculative. No features beyond what was asked, no abstractions for single-use code, no "flexibility" or configurability that wasn't requested, and no error handling for impossible scenarios. If you write 200 lines and it could be 50, rewrite it. Ask yourself whether a senior engineer would call this overcomplicated — if so, simplify.
-
-## Make surgical changes
-
-Touch only what you must; clean up only your own mess. When editing existing code, don't "improve" adjacent code, comments, or formatting, and don't refactor things that aren't broken. Match the existing style even if you would do it differently. If you notice unrelated dead code, mention it — don't delete it. Remove only the imports, variables, and functions that YOUR changes made unused; leave pre-existing dead code unless asked. Every changed line should trace directly to the request.
-
-## Drive to verifiable goals
-
-Turn tasks into verifiable success criteria and loop until they are met: "add validation" becomes "write tests for invalid inputs, then make them pass"; "fix the bug" becomes "write a test that reproduces it, then make it pass." For a multi-step task, state a brief plan with a verification check for each step. Strong success criteria let you work independently; weak ones ("make it work") force constant clarification.
-`;
-
-export const APPENDED_INSTRUCTIONS =
-  BRANCH_NAMING + PLAN_MODE + MCP_TOOLS + WORKING_DISCIPLINE;
+export const APPENDED_INSTRUCTIONS = BRANCH_NAMING + PLAN_MODE + MCP_TOOLS;