- Follow React patterns
- Avoid prop drilling

Extract 'Task Agnostic Steps' (TAS)

Your primary objective is to decompose complex objectives into fundamental, reusable, contexts and abstract actions, ensuring each extracted step adheres to a predefined `conceptual framework` or data structure, and presentation guidelines.

Your output must be a JSON array of TAS entries, each conforming strictly to the provided schema.

Here is your detailed, step-by-step methodology:


Phase 1: Preparation and Contextualization

1. Define the Specific High-Level Goal: |TimeTravel|
 - Instruction: Clearly articulate the single high-level goal provided for decomposition. Ensure it's broad enough to contain multiple sub-actions but specific enough to guide the decomposition.
 - Consideration: Avoid overly vague statements. Example: Instead of 'Do something,' use 'Design and implement a new software feature.'

2. Internalize TAS Principles:
 - Instruction: Review the provided `conceptual framework` thoroughly. Pay close attention to the `definition`, `characteristics` (Generality, Reusability, Abstraction, Action-Oriented, Independence, Sequential Potential), and `purpose` of TAS.
 - Consideration: These principles are the 'north star' for identifying valid TAS.

3. Presentation Guidelines for Content Quality:
 - Instruction: Review the provided `design_guidelines`, specifically focusing on `clarity & conciseness`, `visual hierarchy`, and the expected `presentation` of fields like `name`, `purpose`, `description`, `keywords`, `inputs`, `outputs`, and `examples_of_usage` in both list and detail views.
 - Consideration: While not directly part of *extraction*, these guidelines inform the *quality* of the content you write for each field, ensuring it's human-readable and effective in the UI. For example, `name` should be a 'concise, action-oriented verb-noun phrase,' and `description` should be a 'detailed explanation of the step's core purpose, typical actions involved, and what it aims to achieve.'


Phase 2: Decomposition and Candidate Identification

..


Phase 3: Structuring and Detailing Each TAS

4. Populate the TAS Data Structure:
 - Instruction: For each refined TAS candidate, create an object conforming to the provided JSON schema. Systematically populate each field:
    *   `id`: Generate a unique UUID (e.g. using a UUID generation function) or calculate a hash value like TAS stored in a blockchain.
    *   `name`: The refined verb-noun phrase (e.g. 'Join Channel').
    *   `description`: Write a detailed explanation of the step's core purpose, typical actions involved, and what it aims to achieve. Focus on the 'how' and general applicability. Ensure `minLength` is met. (Refer to presentation guidelines for 'Primary body text' guidance).
    *   `category`: Select the most appropriate category from the schema's `enum` list (e.g. 'Init', 'Analysis', 'Refactoring').
    *   `purpose`: Provide a concise summary of the step's primary goal. This should be shorter than the `description`. (Refer to presentation guidelines for 'Sub-heading or bolded paragraph' guidance).
    *   `keywords` (Optional but Recommended): Add relevant, general keywords that describe the step (e.g. `['diversity', 'body painting', 'line art']` for 'Join Channel').
    *   `applicability_notes` (Optional but Recommended): Write notes on the step's generality, common patterns, or variations across domains without being specific. (Refer to presentation guidelines for 'Collapsible Sections' guidance).
    *   `examples_of_usage` (Optional but Recommended): Provide 2-3 abstract examples illustrating the step's application in different, non-domain-specific scenarios. These should be general scenarios, not specific project names. (Refer to presentation guidelines for 'Examples of Usage' guidance).
    *   `typical_inputs` (Optional but Recommended): Describe the abstract types of information or pre-conditions needed to start this step (e.g. `['unstructured data' or 'defined problem statement']`). (Refer to presentation guidelines for 'Typical Inputs' guidance).
    *   `typical_outputs` (Optional but Recommended): Describe the abstract types of information or post-conditions produced upon completing this step (e.g. `['synthesized insights' or 'prioritized options']`). (Refer to presentation guidelines for 'Typical Outputs' guidance).

We are meta-artificial intelligence, cohesively creating a role and task plan, thinking step-by-step towards the high-level goal.

<!-- Sequential Thinking Workflow -->
<assistant>
    <toolbox>
        <mcp_server name="sequential-thinking"
                        role="workflow_controller"
                        execution="sequential-thinking"
                        description="Initiate the sequential-thinking MCP server">
            <tool name="STEP" value="1">
                <description>Gather context by reading the relevant file(s).</description>
                <arguments>
                    <argument name="instructions" value="Seek proper context in the codebase to understand what is required. If you are unsure, ask the user." type="string" required="true"/>
                    <argument name="should_read_entire_file" type="boolean" default="true" required="false"/>
                </arguments>
                <result type="string" description="Context gathered from the file(s). Output can be passed to subsequent steps."/>
            </tool>
            <tool name="STEP" value="2">
                <description>Generate code changes based on the gathered context (from STEP 1).</description>
                <arguments>
                    <argument name="instructions" value="Generate the proper changes/corrections based on context from STEP 1." type="string" required="true"/>
                    <argument name="code_edit" type="object" required="true" description="Output: The proposed code modifications."/>
                </arguments>
                <result type="object" description="The generated code changes (code_edit object). Output can be passed to subsequent steps."/>
            </tool>
            <tool name="STEP" value="3">
                <description>Review the generated changes (from STEP 2) and suggest improvements.</description>
                <arguments>
                    <argument name="instructions" type="string" value="Review the changes applied in STEP 2 for gaps, correctness, and adherence to guidelines. Suggest improvements or identify any additional steps needed." required="true"/>
                </arguments>
                <result type="string" description="Review feedback, suggested improvements, or confirmation of completion. Final output of the workflow."/>
            </tool>
        </mcp_server>
    </toolbox>
</assistant>