Initial commit
This commit is contained in:
Zhongwei Li
440
commands/create-spec.md
Normal file
440
commands/create-spec.md
Normal file
@@ -0,0 +1,440 @@
|
||||
# Create Spec
|
||||
|
||||
Create a detailed spec for a new artifact with technical specifications and task breakdown
|
||||
|
||||
# Spec Creation Rules
|
||||
|
||||
## Overview
|
||||
|
||||
Generate detailed feature specifications aligned with product roadmap and mission.
|
||||
|
||||
<pre_flight_check>
|
||||
- IMPORTANT: For any step that specifies a subagent in the subagent="" XML attribute you MUST use the specified subagent to perform the instructions for that step.
|
||||
|
||||
- Process XML blocks sequentially
|
||||
|
||||
- Read and execute every numbered step in the process_flow EXACTLY as the instructions specify.
|
||||
|
||||
- If you need clarification on any details of your current task, stop and ask the user specific numbered questions and then continue once you have all of the information you need.
|
||||
|
||||
- Use exact templates as provided
|
||||
</pre_flight_check>
|
||||
|
||||
<process_flow>
|
||||
|
||||
<step number="1" subagent="context-fetcher" name="spec_initiation">
|
||||
|
||||
### Step 1: Spec Initiation
|
||||
|
||||
Use the context-fetcher subagent to identify spec initiation method by either finding the next uncompleted roadmap item when user asks "what's next?" or accepting a specific spec idea from the user.
|
||||
|
||||
<option_a_flow>
|
||||
<trigger_phrases>
|
||||
- "what's next?"
|
||||
</trigger_phrases>
|
||||
<actions>
|
||||
1. CHECK research-os/project/roadmap.md
|
||||
2. FIND next uncompleted item
|
||||
3. SUGGEST item to user
|
||||
4. WAIT for approval
|
||||
</actions>
|
||||
</option_a_flow>
|
||||
|
||||
<option_b_flow>
|
||||
<trigger>user describes specific spec idea</trigger>
|
||||
<accept>any format, length, or detail level</accept>
|
||||
<proceed>to context gathering</proceed>
|
||||
</option_b_flow>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="2" subagent="context-fetcher" name="context_gathering">
|
||||
|
||||
### Step 2: Context Gathering (Conditional)
|
||||
|
||||
Use the context-fetcher subagent to read research-os/project/mission.md and research-os/project/tech-stack.md only if not already in context to ensure minimal context for spec alignment.
|
||||
|
||||
<conditional_logic>
|
||||
IF both mission.md AND tech-stack.md already read in current context:
|
||||
SKIP this entire step
|
||||
PROCEED to step 3
|
||||
ELSE:
|
||||
READ only files not already in context:
|
||||
- mission.md (if not in context)
|
||||
- tech-stack.md (if not in context)
|
||||
CONTINUE with context analysis
|
||||
</conditional_logic>
|
||||
|
||||
<context_analysis>
|
||||
<mission>core product purpose and value</mission>
|
||||
<tech_stack>technical requirements</tech_stack>
|
||||
</context_analysis>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="3" subagent="context-fetcher" name="requirements_clarification">
|
||||
|
||||
### Step 3: Requirements Clarification
|
||||
|
||||
Use the context-fetcher subagent to clarify scope boundaries and technical considerations by asking numbered questions as needed to ensure clear requirements before proceeding.
|
||||
|
||||
<clarification_areas>
|
||||
<scope>
|
||||
- in_scope: what is included
|
||||
- out_of_scope: what is excluded (optional)
|
||||
</scope>
|
||||
<technical>
|
||||
- functionality specifics
|
||||
- UI/UX requirements
|
||||
- integration points
|
||||
</technical>
|
||||
</clarification_areas>
|
||||
|
||||
<decision_tree>
|
||||
IF clarification_needed:
|
||||
ASK numbered_questions
|
||||
WAIT for_user_response
|
||||
ELSE:
|
||||
PROCEED to_date_determination
|
||||
</decision_tree>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="4" subagent="date-checker" name="date_determination">
|
||||
|
||||
### Step 4: Date Determination
|
||||
|
||||
Use the date-checker subagent to determine the current date in YYYY-MM-DD format for folder naming. The subagent will output today's date which will be used in subsequent steps.
|
||||
|
||||
<subagent_output>
|
||||
The date-checker subagent will provide the current date in YYYY-MM-DD format at the end of its response. Store this date for use in folder naming in step 5.
|
||||
</subagent_output>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="5" subagent="file-creator" name="spec_folder_creation">
|
||||
|
||||
### Step 5: Artifact Folder Creation
|
||||
|
||||
Use the file-creator subagent to create directory: research-os/artifacts/YYYY-MM-DD-artifact-name/ using the date from step 4.
|
||||
|
||||
Use kebab-case for artifact name. Maximum 5 words in name.
|
||||
|
||||
<folder_naming>
|
||||
<format>YYYY-MM-DD-artifact-name</format>
|
||||
<date>use stored date from step 4</date>
|
||||
<name_constraints>
|
||||
- max_words: 5
|
||||
- style: kebab-case
|
||||
- descriptive: true
|
||||
</name_constraints>
|
||||
</folder_naming>
|
||||
|
||||
<example_names>
|
||||
- 2025-03-15-password-reset-flow
|
||||
- 2025-03-16-user-profile-dashboard
|
||||
- 2025-03-17-api-rate-limiting
|
||||
</example_names>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="6" subagent="file-creator" name="create_spec_md">
|
||||
|
||||
### Step 6: Create spec.md
|
||||
|
||||
Use the file-creator subagent to create the file: research-os/artifacts/YYYY-MM-DD-artifact-name/spec.md using this template:
|
||||
|
||||
<file_template>
|
||||
<header>
|
||||
# Spec Requirements Document
|
||||
|
||||
> Spec: [SPEC_NAME]
|
||||
> Created: [CURRENT_DATE]
|
||||
</header>
|
||||
<required_sections>
|
||||
- Overview
|
||||
- User Stories
|
||||
- Spec Scope
|
||||
- Out of Scope
|
||||
- Expected Deliverable
|
||||
</required_sections>
|
||||
</file_template>
|
||||
|
||||
<section name="overview">
|
||||
<template>
|
||||
## Overview
|
||||
|
||||
[1-2_SENTENCE_GOAL_AND_OBJECTIVE]
|
||||
</template>
|
||||
<constraints>
|
||||
- length: 1-2 sentences
|
||||
- content: goal and objective
|
||||
</constraints>
|
||||
<example>
|
||||
Implement a secure password reset functionality that allows users to regain account access through email verification. This feature will reduce support ticket volume and improve user experience by providing self-service account recovery.
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section name="user_stories">
|
||||
<template>
|
||||
## User Stories
|
||||
|
||||
### [STORY_TITLE]
|
||||
|
||||
As a [USER_TYPE], I want to [ACTION], so that [BENEFIT].
|
||||
|
||||
[DETAILED_WORKFLOW_DESCRIPTION]
|
||||
</template>
|
||||
<constraints>
|
||||
- count: 1-3 stories
|
||||
- include: workflow and problem solved
|
||||
- format: title + story + details
|
||||
</constraints>
|
||||
</section>
|
||||
|
||||
<section name="spec_scope">
|
||||
<template>
|
||||
## Spec Scope
|
||||
|
||||
1. **[FEATURE_NAME]** - [ONE_SENTENCE_DESCRIPTION]
|
||||
2. **[FEATURE_NAME]** - [ONE_SENTENCE_DESCRIPTION]
|
||||
</template>
|
||||
<constraints>
|
||||
- count: 1-5 features
|
||||
- format: numbered list
|
||||
- description: one sentence each
|
||||
</constraints>
|
||||
</section>
|
||||
|
||||
<section name="out_of_scope">
|
||||
<template>
|
||||
## Out of Scope
|
||||
|
||||
- [EXCLUDED_FUNCTIONALITY_1]
|
||||
- [EXCLUDED_FUNCTIONALITY_2]
|
||||
</template>
|
||||
<purpose>explicitly exclude functionalities</purpose>
|
||||
</section>
|
||||
|
||||
<section name="expected_deliverable">
|
||||
<template>
|
||||
## Expected Deliverable
|
||||
|
||||
1. [TESTABLE_OUTCOME_1]
|
||||
2. [TESTABLE_OUTCOME_2]
|
||||
</template>
|
||||
<constraints>
|
||||
- count: 1-3 expectations
|
||||
- focus: browser-testable outcomes
|
||||
</constraints>
|
||||
</section>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="7" subagent="file-creator" name="create_spec_lite_md">
|
||||
|
||||
### Step 7: Create spec-lite.md
|
||||
|
||||
Use the file-creator subagent to create the file: research-os/artifacts/YYYY-MM-DD-artifact-name/spec-lite.md for the purpose of establishing a condensed spec for efficient AI context usage.
|
||||
|
||||
<file_template>
|
||||
<header>
|
||||
# Spec Summary (Lite)
|
||||
</header>
|
||||
</file_template>
|
||||
|
||||
<content_structure>
|
||||
<spec_summary>
|
||||
- source: Step 6 spec.md overview section
|
||||
- length: 1-3 sentences
|
||||
- content: core goal and objective of the feature
|
||||
</spec_summary>
|
||||
</content_structure>
|
||||
|
||||
<content_template>
|
||||
[1-3_SENTENCES_SUMMARIZING_SPEC_GOAL_AND_OBJECTIVE]
|
||||
</content_template>
|
||||
|
||||
<example>
|
||||
Implement secure password reset via email verification to reduce support tickets and enable self-service account recovery. Users can request a reset link, receive a time-limited token via email, and set a new password following security best practices.
|
||||
</example>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="8" subagent="file-creator" name="create_technical_spec">
|
||||
|
||||
### Step 8: Create Technical Specification
|
||||
|
||||
Use the file-creator subagent to create the file: sub-specs/technical-spec.md using this template:
|
||||
|
||||
<file_template>
|
||||
<header>
|
||||
# Technical Specification
|
||||
|
||||
This is the technical specification for the artifact detailed in research-os/artifacts/YYYY-MM-DD-artifact-name/spec.md
|
||||
</header>
|
||||
</file_template>
|
||||
|
||||
<spec_sections>
|
||||
<technical_requirements>
|
||||
- functionality details
|
||||
- UI/UX specifications
|
||||
- integration requirements
|
||||
- performance criteria
|
||||
</technical_requirements>
|
||||
<external_dependencies_conditional>
|
||||
- only include if new dependencies needed
|
||||
- new libraries/packages
|
||||
- justification for each
|
||||
- version requirements
|
||||
</external_dependencies_conditional>
|
||||
</spec_sections>
|
||||
|
||||
<example_template>
|
||||
## Technical Requirements
|
||||
|
||||
- [SPECIFIC_TECHNICAL_REQUIREMENT]
|
||||
- [SPECIFIC_TECHNICAL_REQUIREMENT]
|
||||
|
||||
## External Dependencies (Conditional)
|
||||
|
||||
[ONLY_IF_NEW_DEPENDENCIES_NEEDED]
|
||||
- **[LIBRARY_NAME]** - [PURPOSE]
|
||||
- **Justification:** [REASON_FOR_INCLUSION]
|
||||
</example_template>
|
||||
|
||||
<conditional_logic>
|
||||
IF spec_requires_new_external_dependencies:
|
||||
INCLUDE "External Dependencies" section
|
||||
ELSE:
|
||||
OMIT section entirely
|
||||
</conditional_logic>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="9" subagent="file-creator" name="create_database_schema">
|
||||
|
||||
### Step 9: Create Database Schema (Conditional)
|
||||
|
||||
Use the file-creator subagent to create the file: sub-specs/database-schema.md ONLY IF database changes needed for this task.
|
||||
|
||||
<decision_tree>
|
||||
IF spec_requires_database_changes:
|
||||
CREATE sub-specs/database-schema.md
|
||||
ELSE:
|
||||
SKIP this_step
|
||||
</decision_tree>
|
||||
|
||||
<file_template>
|
||||
<header>
|
||||
# Database Schema
|
||||
|
||||
This is the database schema implementation for the artifact detailed in research-os/artifacts/YYYY-MM-DD-artifact-name/spec.md
|
||||
</header>
|
||||
</file_template>
|
||||
|
||||
<schema_sections>
|
||||
<changes>
|
||||
- new tables
|
||||
- new columns
|
||||
- modifications
|
||||
- migrations
|
||||
</changes>
|
||||
<specifications>
|
||||
- exact SQL or migration syntax
|
||||
- indexes and constraints
|
||||
- foreign key relationships
|
||||
</specifications>
|
||||
<rationale>
|
||||
- reason for each change
|
||||
- performance considerations
|
||||
- data integrity rules
|
||||
</rationale>
|
||||
</schema_sections>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="10" subagent="file-creator" name="create_api_spec">
|
||||
|
||||
### Step 10: Create API Specification (Conditional)
|
||||
|
||||
Use the file-creator subagent to create file: sub-specs/api-spec.md ONLY IF API changes needed.
|
||||
|
||||
<decision_tree>
|
||||
IF spec_requires_api_changes:
|
||||
CREATE sub-specs/api-spec.md
|
||||
ELSE:
|
||||
SKIP this_step
|
||||
</decision_tree>
|
||||
|
||||
<file_template>
|
||||
<header>
|
||||
# API Specification
|
||||
|
||||
This is the API specification for the artifact detailed in research-os/artifacts/YYYY-MM-DD-artifact-name/spec.md
|
||||
</header>
|
||||
</file_template>
|
||||
|
||||
<api_sections>
|
||||
<routes>
|
||||
- HTTP method
|
||||
- endpoint path
|
||||
- parameters
|
||||
- response format
|
||||
</routes>
|
||||
<controllers>
|
||||
- action names
|
||||
- business logic
|
||||
- error handling
|
||||
</controllers>
|
||||
<purpose>
|
||||
- endpoint rationale
|
||||
- integration with features
|
||||
</purpose>
|
||||
</api_sections>
|
||||
|
||||
<endpoint_template>
|
||||
## Endpoints
|
||||
|
||||
### [HTTP_METHOD] [ENDPOINT_PATH]
|
||||
|
||||
**Purpose:** [DESCRIPTION]
|
||||
**Parameters:** [LIST]
|
||||
**Response:** [FORMAT]
|
||||
**Errors:** [POSSIBLE_ERRORS]
|
||||
</endpoint_template>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="11" name="user_review">
|
||||
|
||||
### Step 11: User Review
|
||||
|
||||
Request user review of spec.md and all sub-specs files, waiting for approval or revision requests.
|
||||
|
||||
<review_request>
|
||||
I've created the artifact documentation:
|
||||
|
||||
- Spec Requirements: research-os/artifacts/YYYY-MM-DD-artifact-name/spec.md
|
||||
- Spec Summary: research-os/artifacts/YYYY-MM-DD-artifact-name/spec-lite.md
|
||||
- Technical Spec: research-os/artifacts/YYYY-MM-DD-artifact-name/sub-specs/technical-spec.md
|
||||
[LIST_OTHER_CREATED_SPECS]
|
||||
|
||||
Please review and let me know if any changes are needed.
|
||||
|
||||
When you're ready, run the /create-tasks command to have me build the tasks checklist from this spec.
|
||||
</review_request>
|
||||
|
||||
</step>
|
||||
|
||||
</process_flow>
|
||||
|
||||
<post_flight_check>
|
||||
After completing all steps in a process_flow, always review your work and verify:
|
||||
|
||||
- Every numbered step has read, executed, and delivered according to its instructions.
|
||||
|
||||
- All steps that specified a subagent should be used, did in fact delegate those tasks to the specified subagent. IF they did not, see why the subagent was not used and report your findings to the user.
|
||||
|
||||
- IF you notice a step wasn't executed according to its instructions, report your findings and explain which part of the instructions were misread or skipped and why.
|
||||
</post_flight_check>
|
||||
121
commands/create-tasks.md
Normal file
121
commands/create-tasks.md
Normal file
@@ -0,0 +1,121 @@
|
||||
# Create Tasks
|
||||
|
||||
Create a tasks list with sub-tasks to execute an artifact based on its spec.
|
||||
|
||||
# Spec Creation Rules
|
||||
|
||||
## Overview
|
||||
|
||||
With the user's approval, proceed to creating a tasks list based on the current feature spec.
|
||||
|
||||
<pre_flight_check>
|
||||
- IMPORTANT: For any step that specifies a subagent in the subagent="" XML attribute you MUST use the specified subagent to perform the instructions for that step.
|
||||
|
||||
- Process XML blocks sequentially
|
||||
|
||||
- Read and execute every numbered step in the process_flow EXACTLY as the instructions specify.
|
||||
|
||||
- If you need clarification on any details of your current task, stop and ask the user specific numbered questions and then continue once you have all of the information you need.
|
||||
|
||||
- Use exact templates as provided
|
||||
</pre_flight_check>
|
||||
|
||||
<process_flow>
|
||||
|
||||
<step number="1" subagent="file-creator" name="create_tasks">
|
||||
|
||||
### Step 1: Create tasks.md
|
||||
|
||||
Use the file-creator subagent to create file: tasks.md inside of the current feature's spec folder.
|
||||
|
||||
<file_template>
|
||||
<header>
|
||||
# Spec Tasks
|
||||
</header>
|
||||
</file_template>
|
||||
|
||||
<task_structure>
|
||||
<major_tasks>
|
||||
- count: 1-5
|
||||
- format: numbered checklist
|
||||
- grouping: by feature or component
|
||||
</major_tasks>
|
||||
<subtasks>
|
||||
- count: up to 8 per major task
|
||||
- format: decimal notation (1.1, 1.2)
|
||||
- first_subtask: typically write tests
|
||||
- last_subtask: verify all tests pass
|
||||
</subtasks>
|
||||
</task_structure>
|
||||
|
||||
<task_template>
|
||||
## Tasks
|
||||
|
||||
- [ ] 1. [MAJOR_TASK_DESCRIPTION]
|
||||
- [ ] 1.1 Write tests for [COMPONENT]
|
||||
- [ ] 1.2 [IMPLEMENTATION_STEP]
|
||||
- [ ] 1.3 [IMPLEMENTATION_STEP]
|
||||
- [ ] 1.4 Verify all tests pass
|
||||
|
||||
- [ ] 2. [MAJOR_TASK_DESCRIPTION]
|
||||
- [ ] 2.1 Write tests for [COMPONENT]
|
||||
- [ ] 2.2 [IMPLEMENTATION_STEP]
|
||||
</task_template>
|
||||
|
||||
<ordering_principles>
|
||||
- Consider technical dependencies
|
||||
- Follow TDD approach
|
||||
- Group related functionality
|
||||
- Build incrementally
|
||||
</ordering_principles>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="2" name="execution_readiness">
|
||||
|
||||
### Step 2: Execution Readiness Check
|
||||
|
||||
Evaluate readiness to begin implementation by presenting the first task summary and requesting user confirmation to proceed.
|
||||
|
||||
<readiness_summary>
|
||||
<present_to_user>
|
||||
- Spec name and description
|
||||
- First task summary from tasks.md
|
||||
- Estimated complexity/scope
|
||||
- Key deliverables for task 1
|
||||
</present_to_user>
|
||||
</readiness_summary>
|
||||
|
||||
<execution_prompt>
|
||||
PROMPT: "The spec planning is complete. The first task is:
|
||||
|
||||
**Task 1:** [FIRST_TASK_TITLE]
|
||||
[BRIEF_DESCRIPTION_OF_TASK_1_AND_SUBTASKS]
|
||||
|
||||
Would you like me to proceed with implementing Task 1? I will focus only on this first task and its subtasks unless you specify otherwise.
|
||||
|
||||
Type 'yes' to proceed with Task 1, or let me know if you'd like to review or modify the plan first."
|
||||
</execution_prompt>
|
||||
|
||||
<execution_flow>
|
||||
IF user_confirms_yes:
|
||||
Execute the /execute-task command.
|
||||
FOCUS: Only Task 1 and its subtasks
|
||||
CONSTRAINT: Do not proceed to additional tasks without explicit user request
|
||||
ELSE:
|
||||
WAIT: For user clarification or modifications
|
||||
</execution_flow>
|
||||
|
||||
</step>
|
||||
|
||||
</process_flow>
|
||||
|
||||
<post_flight_check>
|
||||
After completing all steps in a process_flow, always review your work and verify:
|
||||
|
||||
- Every numbered step has read, executed, and delivered according to its instructions.
|
||||
|
||||
- All steps that specified a subagent should be used, did in fact delegate those tasks to the specified subagent. IF they did not, see why the subagent was not used and report your findings to the user.
|
||||
|
||||
- IF you notice a step wasn't executed according to its instructions, report your findings and explain which part of the instructions were misread or skipped and why.
|
||||
</post_flight_check>
|
||||
274
commands/execute-tasks.md
Normal file
274
commands/execute-tasks.md
Normal file
@@ -0,0 +1,274 @@
|
||||
# Execute Tasks
|
||||
|
||||
Execute the next task from an artifact.
|
||||
|
||||
# Task Execution Rules
|
||||
|
||||
## Overview
|
||||
|
||||
Execute a specific task along with its sub-tasks systematically following a TDD development workflow.
|
||||
|
||||
<pre_flight_check>
|
||||
- IMPORTANT: For any step that specifies a subagent in the subagent="" XML attribute you MUST use the specified subagent to perform the instructions for that step.
|
||||
|
||||
- Process XML blocks sequentially
|
||||
|
||||
- Read and execute every numbered step in the process_flow EXACTLY as the instructions specify.
|
||||
|
||||
- If you need clarification on any details of your current task, stop and ask the user specific numbered questions and then continue once you have all of the information you need.
|
||||
|
||||
- Use exact templates as provided
|
||||
</pre_flight_check>
|
||||
|
||||
|
||||
<process_flow>
|
||||
|
||||
<step number="1" name="task_understanding">
|
||||
|
||||
### Step 1: Task Understanding
|
||||
|
||||
Read and analyze the given parent task and all its sub-tasks from tasks.md to gain complete understanding of what needs to be built.
|
||||
|
||||
<task_analysis>
|
||||
<read_from_tasks_md>
|
||||
- Parent task description
|
||||
- All sub-task descriptions
|
||||
- Task dependencies
|
||||
- Expected outcomes
|
||||
</read_from_tasks_md>
|
||||
</task_analysis>
|
||||
|
||||
<instructions>
|
||||
ACTION: Read the specific parent task and all its sub-tasks
|
||||
ANALYZE: Full scope of implementation required
|
||||
UNDERSTAND: Dependencies and expected deliverables
|
||||
NOTE: Test requirements for each sub-task
|
||||
</instructions>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="2" name="technical_spec_review">
|
||||
|
||||
### Step 2: Technical Specification Review
|
||||
|
||||
Search and extract relevant sections from technical-spec.md to understand the technical implementation approach for this task.
|
||||
|
||||
<selective_reading>
|
||||
<search_technical_spec>
|
||||
FIND sections in technical-spec.md related to:
|
||||
- Current task functionality
|
||||
- Implementation approach for this feature
|
||||
- Integration requirements
|
||||
- Performance criteria
|
||||
</search_technical_spec>
|
||||
</selective_reading>
|
||||
|
||||
<instructions>
|
||||
ACTION: Search technical-spec.md for task-relevant sections
|
||||
EXTRACT: Only implementation details for current task
|
||||
SKIP: Unrelated technical specifications
|
||||
FOCUS: Technical approach for this specific feature
|
||||
</instructions>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="3" subagent="context-fetcher" name="standards_review">
|
||||
|
||||
### Step 3: Standards Review
|
||||
|
||||
Use the context-fetcher subagent to retrieve relevant sections from ~/.research-os/standards/ that apply to the current task, including conventions.md, error-handling.md, validation.md, and testing standards.
|
||||
|
||||
<selective_reading>
|
||||
<search_standards>
|
||||
FIND sections relevant to:
|
||||
- Task's technology stack
|
||||
- Feature type being implemented
|
||||
- Testing approaches (from coverage.md, unit-tests.md)
|
||||
- Code organization patterns (from conventions.md)
|
||||
- Error handling requirements (from error-handling.md)
|
||||
</search_standards>
|
||||
</selective_reading>
|
||||
|
||||
<instructions>
|
||||
ACTION: Use context-fetcher subagent
|
||||
REQUEST: "Find standards sections relevant to:
|
||||
- Task's technology stack: [CURRENT_TECH]
|
||||
- Feature type: [CURRENT_FEATURE_TYPE]
|
||||
- Testing approaches needed
|
||||
- Code organization patterns"
|
||||
PROCESS: Returned standards
|
||||
APPLY: Relevant patterns to implementation
|
||||
</instructions>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="4" subagent="context-fetcher" name="code_style_review">
|
||||
|
||||
### Step 4: Code Style Review
|
||||
|
||||
Use the context-fetcher subagent to retrieve relevant code style rules from ~/.research-os/standards/global/coding-style.md for the languages and file types being used in this task.
|
||||
|
||||
<selective_reading>
|
||||
<search_code_style>
|
||||
FIND style rules for:
|
||||
- Languages used in this task
|
||||
- File types being modified
|
||||
- Component patterns being implemented
|
||||
- Testing style guidelines
|
||||
</search_code_style>
|
||||
</selective_reading>
|
||||
|
||||
<instructions>
|
||||
ACTION: Use context-fetcher subagent
|
||||
REQUEST: "Find code style rules for:
|
||||
- Languages: [LANGUAGES_IN_TASK]
|
||||
- File types: [FILE_TYPES_BEING_MODIFIED]
|
||||
- Component patterns: [PATTERNS_BEING_IMPLEMENTED]
|
||||
- Testing style guidelines"
|
||||
PROCESS: Returned style rules
|
||||
APPLY: Relevant formatting and patterns
|
||||
</instructions>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="5" name="task_execution">
|
||||
|
||||
### Step 5: Task and Sub-task Execution
|
||||
|
||||
Execute the parent task and all sub-tasks in order using test-driven development (TDD) approach.
|
||||
|
||||
<typical_task_structure>
|
||||
<first_subtask>Write tests for [feature]</first_subtask>
|
||||
<middle_subtasks>Implementation steps</middle_subtasks>
|
||||
<final_subtask>Verify all tests pass</final_subtask>
|
||||
</typical_task_structure>
|
||||
|
||||
<execution_order>
|
||||
<subtask_1_tests>
|
||||
IF sub-task 1 is "Write tests for [feature]":
|
||||
- Write all tests for the parent feature
|
||||
- Include unit tests, integration tests, edge cases
|
||||
- Run tests to ensure they fail appropriately
|
||||
- Mark sub-task 1 complete
|
||||
</subtask_1_tests>
|
||||
|
||||
<middle_subtasks_implementation>
|
||||
FOR each implementation sub-task (2 through n-1):
|
||||
- Implement the specific functionality
|
||||
- Make relevant tests pass
|
||||
- Update any adjacent/related tests if needed
|
||||
- Refactor while keeping tests green
|
||||
- Mark sub-task complete
|
||||
</middle_subtasks_implementation>
|
||||
|
||||
<final_subtask_verification>
|
||||
IF final sub-task is "Verify all tests pass":
|
||||
- Run entire test suite
|
||||
- Fix any remaining failures
|
||||
- Ensure no regressions
|
||||
- Mark final sub-task complete
|
||||
</final_subtask_verification>
|
||||
</execution_order>
|
||||
|
||||
<test_management>
|
||||
<new_tests>
|
||||
- Written in first sub-task
|
||||
- Cover all aspects of parent feature
|
||||
- Include edge cases and error handling
|
||||
</new_tests>
|
||||
<test_updates>
|
||||
- Made during implementation sub-tasks
|
||||
- Update expectations for changed behavior
|
||||
- Maintain backward compatibility
|
||||
</test_updates>
|
||||
</test_management>
|
||||
|
||||
<instructions>
|
||||
ACTION: Execute sub-tasks in their defined order
|
||||
RECOGNIZE: First sub-task typically writes all tests
|
||||
IMPLEMENT: Middle sub-tasks build functionality
|
||||
VERIFY: Final sub-task ensures all tests pass
|
||||
UPDATE: Mark each sub-task complete as finished
|
||||
</instructions>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="6" subagent="test-runner" name="task_test_verification">
|
||||
|
||||
### Step 6: Task-Specific Test Verification
|
||||
|
||||
Use the test-runner subagent to run and verify only the tests specific to this parent task (not the full test suite) to ensure the feature is working correctly.
|
||||
|
||||
<focused_test_execution>
|
||||
<run_only>
|
||||
- All new tests written for this parent task
|
||||
- All tests updated during this task
|
||||
- Tests directly related to this feature
|
||||
</run_only>
|
||||
<skip>
|
||||
- Full test suite (done later in execute-tasks.md)
|
||||
- Unrelated test files
|
||||
</skip>
|
||||
</focused_test_execution>
|
||||
|
||||
<final_verification>
|
||||
IF any test failures:
|
||||
- Debug and fix the specific issue
|
||||
- Re-run only the failed tests
|
||||
ELSE:
|
||||
- Confirm all task tests passing
|
||||
- Ready to proceed
|
||||
</final_verification>
|
||||
|
||||
<instructions>
|
||||
ACTION: Use test-runner subagent
|
||||
REQUEST: "Run tests for [this parent task's test files]"
|
||||
WAIT: For test-runner analysis
|
||||
PROCESS: Returned failure information
|
||||
VERIFY: 100% pass rate for task-specific tests
|
||||
CONFIRM: This feature's tests are complete
|
||||
</instructions>
|
||||
|
||||
</step>
|
||||
|
||||
<step number="7" name="task_status_updates">
|
||||
|
||||
### Step 7: Mark this task and sub-tasks complete
|
||||
|
||||
IMPORTANT: In the tasks.md file, mark this task and its sub-tasks complete by updating each task checkbox to [x].
|
||||
|
||||
<update_format>
|
||||
<completed>- [x] Task description</completed>
|
||||
<incomplete>- [ ] Task description</incomplete>
|
||||
<blocked>
|
||||
- [ ] Task description
|
||||
⚠️ Blocking issue: [DESCRIPTION]
|
||||
</blocked>
|
||||
</update_format>
|
||||
|
||||
<blocking_criteria>
|
||||
<attempts>maximum 3 different approaches</attempts>
|
||||
<action>document blocking issue</action>
|
||||
<emoji>⚠️</emoji>
|
||||
</blocking_criteria>
|
||||
|
||||
<instructions>
|
||||
ACTION: Update tasks.md after each task completion
|
||||
MARK: [x] for completed items immediately
|
||||
DOCUMENT: Blocking issues with ⚠️ emoji
|
||||
LIMIT: 3 attempts before marking as blocked
|
||||
</instructions>
|
||||
|
||||
</step>
|
||||
|
||||
</process_flow>
|
||||
|
||||
<post_flight_check>
|
||||
After completing all steps in a process_flow, always review your work and verify:
|
||||
|
||||
- Every numbered step has read, executed, and delivered according to its instructions.
|
||||
|
||||
- All steps that specified a subagent should be used, did in fact delegate those tasks to the specified subagent. IF they did not, see why the subagent was not used and report your findings to the user.
|
||||
|
||||
- IF you notice a step wasn't executed according to its instructions, report your findings and explain which part of the instructions were misread or skipped and why.
|
||||
</post_flight_check>
|
||||
Reference in New Issue
Block a user