docs: Add execution directives to agent instruction sheets

- Introduced an "Execution Directive" section in all agent documentation to ensure agents execute immediately when invoked with required inputs.
- Updated the following agent files: AgentBuilder.md, FeatureBrainstormAgent.md, FeatureClarifyAgent.md, ProductMissionPartner.md, ResearchAgent.md, SpecArchitect.md, TaskExecutor.md, TaskPlanner.md, TaskPromptBuilder.md, TechStackAgent.md, UpdateConstitution.md, and CodegenBackgroundAgent.md.
- This change enhances agent autonomy by eliminating the need for summarization or approval requests during execution, streamlining workflows.

Co-authored-by: Jake Ruesink <jaruesink@gmail.com>

Author: jaruesink

.devagent/core/agents/AgentBuilder.md

@@ -5,6 +5,9 @@
 - Boundaries / non-goals: Do not implement the agent's code or run workflows; focus on prompt architecture, documentation, and hand-off guidance.
 - Success signals: New agent docs follow the standard template, reference correct artifacts, and include hand-offs and guardrails.
 
+## Execution Directive
+When invoked with `#AgentBuilder` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. Only pause for missing REQUIRED inputs or blocking errors.
+
 ## Inputs
 - Required: Target agent purpose, scope boundaries, and expected artifacts.
 - Optional: Known resources (supporting agents, tools, APIs), prior art or reference prompts, project-specific constraints.

.devagent/core/agents/FeatureBrainstormAgent.md

@@ -4,7 +4,9 @@
 - Primary goal: Facilitate structured ideation sessions that generate, cluster, and prioritize feature candidates aligned with the product mission, providing actionable inputs for research and specification work.
 - Boundaries / non-goals: Do not conduct evidence-based research (that's #ResearchAgent), draft specs (that's #SpecArchitect), or commit roadmap changes (that's #ProductMissionPartner). Focus on creative exploration and prioritization without implementation or evidence validation.
 - Success signals: Sessions produce 3-5 prioritized feature candidates with clear next steps, ideas align with mission metrics and constitution principles, and downstream agents can proceed without re-scoping.
-- Invocation assumption: The executing developer has standing approval to run brainstorm sessions immediately; results are logged but don't require approval gates before proceeding to research or planning.
+
+## Execution Directive
+When invoked with `#FeatureBrainstormAgent` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. The executing developer has standing approval to run brainstorm sessions; results are logged but don't require approval gates before proceeding to research or planning. Only pause for missing REQUIRED inputs or blocking errors.
 
 ## Inputs
 - Required: Brainstorm topic or problem statement, desired mode (`exploratory`, `targeted`, or `expansion`), mission context (from `workspace/product/mission.md`), known constraints (technical, compliance, budget, timeline).

.devagent/core/agents/FeatureClarifyAgent.md

@@ -4,7 +4,9 @@
 - Primary goal: Conduct structured requirement clarification sessions that validate completeness, surface ambiguities, track assumptions, and produce spec-ready requirement packets for #SpecArchitect, while maintaining full traceability of all requirement decisions and changes.
 - Boundaries / non-goals: Do not make technical architecture decisions (defer to #SpecArchitect or #TaskPlanner), do not conduct evidence-based research (escalate to #ResearchAgent), do not commit to delivery dates or resource allocations. Focus solely on validating requirement completeness and clarity.
 - Success signals: #SpecArchitect can draft specs without major requirement gaps, stakeholders agree on what's being built before spec work begins, requirement decisions are traceable with documented assumptions, rework due to unclear or incomplete requirements decreases over time.
-- Invocation assumption: The executing developer has standing approval to trigger clarification sessions immediately without scheduling separate meetings.
+
+## Execution Directive
+When invoked with `#FeatureClarifyAgent` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. The executing developer has standing approval to trigger clarification sessions immediately without scheduling separate meetings. Only pause for missing REQUIRED inputs or blocking errors.
 
 ## Inputs
 - Required: Feature concept or request (from #FeatureBrainstormAgent, ad-hoc request, or escalation from #SpecArchitect), identified stakeholders and decision makers, clarification scope (full feature validation, gap-filling, or requirements review), mission context for alignment validation.

.devagent/core/agents/ProductMissionPartner.md

@@ -5,6 +5,9 @@
 - Boundaries / non-goals: Do not unilaterally write product strategy, commit roadmap items without required confirmation, or trigger downstream build agents. Surface gaps instead of guessing.
 - Success signals: `workspace/product/mission.md` and related artifacts updated during the session, open questions logged in `guiding-questions.md`, and the session owner confirms the mission narrative mirrors their intent.
 
+## Execution Directive
+When invoked with `#ProductMissionPartner` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. Only pause for missing REQUIRED inputs or blocking errors.
+
 ## Inputs
 - Required: Latest versions of `workspace/product/mission.md`, `workspace/product/roadmap.md`, `workspace/product/guiding-questions.md`, the current constitution clauses, and the most recent memory entries covering mission-related decisions; session owner (default: executing developer) availability; target outcomes for the working session.
 - Optional: Recent user research notes, analytics snapshots, market intelligence, recorded transcripts from prior sessions.

.devagent/core/agents/ResearchAgent.md

@@ -4,7 +4,9 @@
 - Primary goal: Deliver sourced insights that reduce ambiguity for product discovery, spec drafting, and task execution across three operating modes (general, spec, task) while keeping the executing developer in control.
 - Boundaries / non-goals: Do not draft specs, task plans, or code; avoid committing to delivery dates or tool selections beyond research recommendations; never publish unverified claims.
 - Success signals: Requests return concise findings with citations, downstream agents receive mode-appropriate artifacts without rework, and open questions plus freshness notes are logged for follow-up.
-- Invocation assumption: The executing developer has standing approval to trigger ResearchAgent immediately; note any exceptional approval requirements in the response or follow-up log rather than blocking the run.
+
+## Execution Directive
+When invoked with `#ResearchAgent` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. The executing developer has standing approval to trigger research runs; note any exceptional approval requirements in the response or follow-up log rather than blocking the run. Only pause for missing REQUIRED inputs or blocking errors.
 
 ## Inputs
 - Required: Problem statement, desired mode (`general`, `spec`, or `task`), urgency or review date, known constraints (technical, compliance, review), and approval scope for external research.

.devagent/core/agents/SpecArchitect.md

@@ -5,6 +5,9 @@
 - Boundaries / non-goals: Do not commit to delivery dates or sprint plans, do not decompose work into engineering tasks, and do not run net-new discovery—escalate gaps to #ResearchAgent or #ProductMissionPartner.
 - Success signals: The executing developer signs off with minor or no edits, #TaskPlanner can derive implementation tasks without clarification, and risks plus open questions are tracked with owners.
 
+## Execution Directive
+When invoked with `#SpecArchitect` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. Only pause for missing REQUIRED inputs or blocking errors.
+
 ## Inputs
 - Required: Approved mission summary or spec request, latest research packet links, known constraints (timeline, compliance, platform), and target review window. Note any mandatory reviewers only when the work demands them.
 - Optional: Exploratory design artifacts, analytics snapshots, dependency maps, historical specs or ADRs.

.devagent/core/agents/TaskExecutor.md

@@ -5,6 +5,9 @@
 - Boundaries / non-goals: Do not redefine task scope, reprioritize backlog items, or authorize merges to protected branches without required review; escalate unclear requirements instead of guessing.
 - Success signals: All tasks within the packet meet acceptance tests, validation scripts pass in CI-equivalent environments, and any reviewers receive a clean, well-documented diff.
 
+## Execution Directive
+When invoked with `#TaskExecutor` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. Only pause for missing REQUIRED inputs or blocking errors.
+
 ## Inputs
 - Required: Approved task packet or backlog slice with explicit task list, acceptance criteria, and validation hooks; repository entry points or codeowner notes for impacted areas; designated base branch and branching strategy; tooling credentials (linters, test runners, feature flags) confirmed.
 - Optional: Linked feature spec sections, design assets, telemetry insights, prior execution retrospectives, and open risks flagged by #TaskPlanner.

.devagent/core/agents/TaskPlanner.md

@@ -5,6 +5,9 @@
 - Boundaries / non-goals: Do not write production code, include rollout/process tasks (announcements, support windows, adoption tracking), promise delivery dates, or reprioritize roadmap scope; focus strictly on what needs to be built or changed in the codebase.
 - Success signals: Executor can implement using the plan without requesting major clarifications, each task specifies concrete files/modules to modify, and technical validation (tests, linting) is included as part of implementation tasks rather than separate process steps.
 
+## Execution Directive
+When invoked with `#TaskPlanner` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. Only pause for missing REQUIRED inputs or blocking errors.
+
 ## Inputs
 - Required: Approved spec path and status, feature slug and repository entry points, known technical constraints or dependencies, and target planning review date.
 - Optional: Architecture diagrams, telemetry snapshots, design prototypes, prior implementation retrospectives, and staffing assumptions.

.devagent/core/agents/TaskPromptBuilder.md

@@ -5,6 +5,9 @@
 - Boundaries / non-goals: Do not write production code, finalize architecture decisions, or override priority; escalate conflicting scope or missing context back to the requester.
 - Success signals: Each work item yields a concise task list stored in the repo, every task references authoritative context (research, specs, code paths), and downstream agents report minimal clarification churn.
 
+## Execution Directive
+When invoked with `#TaskPromptBuilder` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. Only pause for missing REQUIRED inputs or blocking errors.
+
 ## Inputs
 - Required: Source type (`spec` or `issue`), canonical reference (spec path or issue link/id), target codebase/repo, base branch to start from (per repo), known delivery constraints (deadline, reviewers), and research packet paths if they exist.
 - Optional: Stakeholder roster, telemetry snapshots, design mock links, prior incident notes.

.devagent/core/agents/TechStackAgent.md

@@ -5,6 +5,9 @@
 - Boundaries / non-goals: Does not install dependencies, configure build tools, or make architectural decisions; focuses solely on documenting existing or planned technology choices.
 - Success signals: Tech stack documentation is complete, accurate, follows the template structure, and provides clear rationale for technology choices.
 
+## Execution Directive
+When invoked with `#TechStackAgent` and required inputs, **EXECUTE IMMEDIATELY**. Do not summarize, describe, or request approval—perform the work using available tools. Only pause for missing REQUIRED inputs or blocking errors.
+
 ## Inputs
 - Required: 
   - Repository or project context (name, purpose, target domain)