Struct UpdateSpecArgs 

pub struct UpdateSpecArgs {
    pub project_name: String,
    pub spec_name: String,
    pub spec: Option<String>,
    pub tasks: Option<String>,
    pub notes: Option<String>,
    pub operation: String,
    pub context_patch: Option<String>,
}

Arguments for update_spec command

Fields

project_name: String

Project name containing the spec to update

Must be an existing project in ~/.foundry/ Use ‘foundry list-projects’ to see available projects

spec_name: String

Spec name to update (YYYYMMDD_HHMMSS_feature_name format)

Must be an existing spec within the project Use ‘foundry load-project PROJECT_NAME’ to see available specs

spec: Option<String>

New content for spec.md (optional)

Complete Content Replacement (–operation replace):

• Entirely replaces the existing spec.md content
• Use for major requirement changes or complete rewrites
• Existing content is lost - ensure you have backups if needed

Content Addition (–operation append):

• Adds new content to the end of existing spec.md
• Preserves existing requirements and specifications
• Use for iterative spec development and additions

Markdown Formatting Guidelines:

• Use # Feature Name as main header
• Use ## for major sections (## Overview, ## Requirements, ## Implementation)
• Include functional requirements, acceptance criteria, technical approach
• Use bullet points, numbered lists, and code blocks as needed

tasks: Option<String>

New content for task-list.md (optional)

Complete Content Replacement (–operation replace):

• Entirely replaces the existing task-list.md content
• Use when completely restructuring the implementation plan
• Existing task history is lost

Content Addition (–operation append):

• Adds new tasks to the end of existing task-list.md
• Preserves existing task history and completion status
• Use for adding new tasks or marking existing tasks as complete

Markdown Checklist Format:

• Use “## Phase Name” headers to group related tasks
• Use “- [ ] Task description” for uncompleted tasks
• Use “- [x] Task description” for completed tasks
• Include implementation details and dependencies

notes: Option<String>

New content for notes.md (optional)

Complete Content Replacement (–operation replace):

• Entirely replaces the existing notes.md content
• Use when consolidating or restructuring design decisions
• Existing notes and rationale are lost

Content Addition (–operation append):

• Adds new notes to the end of existing notes.md
• Preserves existing design decisions and implementation notes
• Use for adding new insights, decisions, or implementation details

Markdown Formatting Guidelines:

• Use ## headers for different categories (## Design Decisions, ## Implementation Notes)
• Document technical tradeoffs, constraints, and rationale
• Include code snippets, external references, and future considerations
• Keep notes conversational but technical

operation: String

Content replacement strategy (REQUIRED)

replace: Completely replaces the target file content with new content

• Use when: Completely rewriting content, major changes, starting fresh
• Risk: Existing content is lost permanently
• Example: Major requirement changes, technical direction changes

append: Adds new content to the end of existing file content

• Use when: Adding new content, iterative development, preserving history
• Risk: Low - existing content is preserved
• Example: Adding new tasks, accumulating notes, marking items complete

Applies to ALL files being updated in this command.

context_patch: Option<String>

Context-based patch data (JSON string, optional)

Context-Based Patching (–operation context_patch):

• Enables precise, targeted updates using surrounding text context
• Avoids need for line number precision or full file replacement
• Use JSON format with before_context, after_context, and content fields
• Supports fuzzy matching for minor formatting variations
• Example: {“file_type”:“spec”,“operation”:“insert”,“before_context”:[“- User auth”],“after_context”:[“- Session mgmt”],“content”:“- Two-factor auth”}

When to use context_patch:

• Small targeted changes (mark task complete, add single requirement)
• Precise insertions between existing content
• Updates where you know the surrounding context

JSON Schema Requirements:

• file_type: “spec”, “tasks”, or “notes”
• operation: “insert”, “replace”, or “delete”
• before_context: Array of strings (3-5 lines recommended)
• after_context: Array of strings (3-5 lines recommended)
• content: String content to insert/replace
• section_context: Optional header for disambiguation (e.g., “## Requirements”)
• match_config: Optional matching configuration

Trait Implementations

impl Args for UpdateSpecArgs

fn group_id() -> Option<Id>

Report the ArgGroup::id for this set of arguments

fn augment_args<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate Self via FromArgMatches::from_arg_matches_mut

fn augment_args_for_update<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate self via FromArgMatches::update_from_arg_matches_mut

impl Debug for UpdateSpecArgs

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl FromArgMatches for UpdateSpecArgs

fn from_arg_matches(__clap_arg_matches: &ArgMatches) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn from_arg_matches_mut( __clap_arg_matches: &mut ArgMatches, ) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn update_from_arg_matches( &mut self, __clap_arg_matches: &ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.

fn update_from_arg_matches_mut( &mut self, __clap_arg_matches: &mut ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.

impl McpToolDefinition for UpdateSpecArgs

fn tool_definition() -> Tool

Generate the MCP tool definition from the struct

fn from_mcp_params(params: &Value) -> Result<Self>

Convert MCP parameters to the CLI argument struct