1. Drafting phases: Generate human-readable markdown documents
2. Structuring phases: Use agent CLI commands for JSON-to-TOML conversion
3. Visualization: Present ASCII graphs at overview and detail levels
4. Iterative: Refine at each phase before proceeding

1. Explicit override: If the user states a preference, always honor it:
   • Automatic signals: "just do it", "go ahead", "automatic", "quick", "don't ask"
   • Interactive signals: "walk me through", "help me", "guide me", "step by step", "let me decide"
2. Skill default: Each skill defines its own default based on the nature of the task.
3. Request analysis: If no explicit signal and no strong skill default, assess the request:
   • Detailed, specific requirements → automatic
   • Brief, ambiguous, or subjective → interactive

• State assumptions briefly before proceeding
• Make reasonable decisions at each step
• Present the result when done
• Pause only if a critical ambiguity could lead to wasted work

• Ask clarifying questions at the start
• Present options at decision points
• Confirm before proceeding at checkpoints
• Allow the user to steer direction

• If in automatic mode and the user asks a question or gives feedback → switch to interactive for the current phase
• If in interactive mode and the user says "looks good, go ahead" or similar → switch to automatic for remaining phases

• User provides a clear one-sentence goal → automatic
• User describes a complex multi-step process → interactive
• User mentions batching, conditions, or parallel execution → interactive
• User says "create a pipeline for X" with no elaboration → automatic

mthds-agent --version

• If it succeeds: proceed to the next step.
• If it fails or the command is not found: STOP. Do not proceed with this skill. Tell the user:

The

mthds-agent

CLI is required but not installed. Install it with:

npm install -g mthds

Then re-run this skill.

.mthds

• Skip entirely if the user's request signals intent to create something new. This includes phrases like "new method", "a new method", "brand new", "from scratch", "create a method", or similar.
• Targeted search if the user references a specific existing method by name or path, search specifically for that method instead of scanning broadly. If the specific method cannot be found, fall back to the general search approach below.

mthds-wip/

.mthds

1. List all

   .mthds

   files in the project (glob for

   **/*.mthds

   )
2. For each file found, read the file header (domain, main pipe code, description) to understand what it does
3. Compare with the user's current request — look for overlap in topic, domain, or purpose

I found an existing method that seems related to what you're asking for:

• <path/to/bundle.mthds>

  — <brief description of what it does>

How would you like to proceed?

1. Start fresh — Create a wholly new method from scratch (ignoring the existing one)
2. Use the existing method — It already does what you need; cancel this build
3. Build upon it — Extend the existing method by adding pipes before or after the current flow

• Start fresh: Proceed with the build as normal (automatic or interactive path below).
• Use the existing method: End the build. Remind the user they can run it with

  /mthds-run

  and point them to its

  inputs.json

  if available.
• Build upon it: Switch to the /mthds-edit skill, framing the task as an extension — ask the user what additional processing they want to add (e.g., a preprocessing step before the main pipe, a postprocessing step after, or additional parallel branches). Pass the existing

  .mthds

  file path to the edit workflow.

• What are the method's inputs? (documents, images, text, structured data)
• What outputs should it produce?
• What transformations are needed?
• Are there conditional branches or parallel operations?
• Should items be processed in batches?

• The overall flow from inputs to outputs
• Each processing step with its purpose
• Variable names (snake_case) for inputs and outputs of each step
• Where structured data or lists are involved

• Name variables consistently across steps
• Use plural names for lists (e.g.,

  documents

  ), singular for items (e.g.,

  document

  )
• Don't detail types yet - focus on the flow

• Name: PascalCase, singular noun (e.g.,

  Invoice

  not

  Invoices

  )
• Description: What it represents
• Type: Either

  refines: NativeConcept

  OR

  structure: {...}

Text

Html

Image

Document

Number

Page

TextAndImages

ImgGenPrompt

JSON

Anything

Dynamic

Note:

Document

is the native concept for any document (PDF, Word, etc.).

Image

is for any image format (JPEG, PNG, etc.). File formats like "PDF" or "JPEG" are not concepts.

Image

url

public_url

filename

caption

Document

url

public_url

filename

Page

text_and_images

page_view

$var.field

construct

• No adjectives:

  Article

  not

  LongArticle

• No circumstances:

  Argument

  not

  CounterArgument

• Always singular:

  Employee

  not

  Employees

**Field types**: `text`, `integer`, `boolean`, `number`, `date`, `concept`, `list`

**Choices (enum-like constrained values)**:
```toml
status = {choices = ["pending", "processing", "completed"], description = "Order status", required = true}
score = {type = "number", choices = ["0", "0.5", "1", "1.5", "2"], description = "Score on a half-point scale"}

choices

type

text

integer

number

field = {type = "concept", concept_ref = "my_domain.OtherConcept", description = "...", required = true}
items = {type = "list", item_type = "concept", item_concept_ref = "my_domain.OtherConcept", description = "..."}

Partial failures: If some commands fail, fix the failing specs using the error JSON (

error_domain: "input"

means the spec is wrong). Re-run only the failed commands.

Note:

Page[]

outputs from PipeExtract automatically convert to text when inserted into prompts using

@variable

.

• Main pipe is clearly identified and handles method inputs
• Variable names are consistent across all pipes
• Input/output types match between connected pipes
• PipeBatch branches receive singular items, not lists
• PipeBatch:

  input_item_name

  (singular) differs from

  input_list_name

  (plural) and all

  inputs

  keys
• PipeSequence batch steps:

  batch_as

  (singular) differs from

  batch_over

  (plural)
• PipeImgGen inputs are text (add PipeLLM if needed to generate prompt)
• No circular dependencies

mthds-agent pipelex models --type llm          # when structuring PipeLLM pipes
mthds-agent pipelex models --type extract      # when structuring PipeExtract pipes
mthds-agent pipelex models --type img_gen      # when structuring PipeImgGen pipes

Partial failures: Fix failing specs using the error JSON. Re-run only the failed commands.

1. Input template: Show the

   inputs

   JSON from the inputs command output. Save it to

   <output_dir>/inputs.json

   for the user to fill in.
2. Next steps — try it now: If the method requires inputs, the saved

   inputs.json

   still contains placeholder values, so suggest a dry run first:

   To try this method right now, use /mthds-run or from the terminal:

   mthds run pipe <output_dir>/ --dry-run --mock-inputs

3. Next steps — run with real data: Explain how to prepare real inputs, then run for real:

   To run with real data, use /mthds-inputs to prepare your inputs (provide your own files, or generate synthetic test data), then:

   mthds run pipe <output_dir>/

   Replace

   <output_dir>

   with the actual output directory path used throughout the build.

• Text

  - single item

• Text[]

  - variable-length list

• Text[3]

  - exactly 3 items

• @variable

  - Block insertion (multi-line, with delimiters)

• $variable

  - Inline insertion (short text)

• $var.field

  - Access nested field

• Domain:

  snake_case

• Concepts:

  PascalCase

  , singular
• Pipes:

  snake_case

• Variables:

  snake_case

• Error Handling — read when CLI returns an error to determine recovery
• MTHDS Agent Guide — read for CLI command syntax or output format details
• MTHDS Language Reference — read when writing or modifying .mthds TOML syntax
• Native Content Types — read when using

  $var.field

  in prompts or

  from

  in construct blocks, to know which attributes each native concept exposes
• Manual Build Phases — read for detailed ASCII diagrams and CLI examples per phase
• Talents and Presets — read when selecting model talents for pipe structuring