strikethroo 3.0.0

package/templates/strikethroo/config/hooks/PRE_TASK_ASSIGNMENT.md

@@ -0,0 +1,32 @@
+# PRE_TASK_ASSIGNMENT Hook
+
+## Agent Selection and Task Assignment
+
+- For each task in the current phase:
+    - Read task frontmatter to extract the `skills` property (array of technical skills)
+    - Analyze task requirements and technical domain from description
+    - Match task skills against available sub-agent capabilities
+    - Select the most appropriate sub-agent (if any are available). If no sub-agent is appropriate, use the general-purpose one.
+    - Consider task-specific requirements from the task document
+
+[IMPORTANT] Analyze the set of tasks skills in order to engage any relevant harness skills as necessary (either global
+or project skills).
+
+
+## Available Sub-Agents
+Analyze the sub-agents available in your current harness's agents directory. If none are available or the available
+ones do not match the task's requirements, then use a generic agent.
+
+## Matching Criteria
+Select agents based on:
+1. **Primary skill match**: Task technical requirements from the `skills` array in task frontmatter
+2. **Domain expertise**: Specific frameworks or libraries mentioned in task descriptions
+3. **Task complexity**: Senior vs. junior agent capabilities
+4. **Resource efficiency**: Avoid over-provisioning for simple tasks
+
+## Skills Extraction and Agent Detection
+
+1. Read the `skills` array from the task's YAML frontmatter directly.
+2. Check for available sub-agents in your harness's agents directory.
+3. If matching sub-agents are found, select the most appropriate one based on the task's required skills.
+4. If no sub-agents are available or none match, use a general-purpose agent for task execution.

package/templates/strikethroo/config/hooks/PRE_TASK_EXECUTION.md

@@ -0,0 +1 @@
+# PRE_TASK_EXECUTION Hook

package/templates/strikethroo/config/templates/BLUEPRINT_TEMPLATE.md

@@ -0,0 +1,24 @@
+## Execution Blueprint
+
+**Validation Gates:**
+- Reference: `/config/hooks/POST_PHASE.md`
+
+### Phase 1: [Descriptive Phase Name]
+**Parallel Tasks:**
+- Task 001: [Description]
+- Task 005: [Description]
+- Task 009: [Description]
+
+### Phase 2: [Descriptive Phase Name]
+**Parallel Tasks:**
+- Task 002: [Description] (depends on: 001)
+- Task 003: [Description] (depends on: 001)
+- Task 006: [Description] (depends on: 005)
+
+[Continue for all phases...]
+
+### Post-phase Actions
+
+### Execution Summary
+- Total Phases: X
+- Total Tasks: Y

package/templates/strikethroo/config/templates/EXECUTION_SUMMARY_TEMPLATE.md

@@ -0,0 +1,13 @@
+## Execution Summary
+
+**Status**: ✅ Completed Successfully
+**Completed Date**: [YYYY-MM-DD]
+
+### Results
+[Brief summary of execution results and key deliverables]
+
+### Noteworthy Events
+[Highlight any unexpected events, challenges overcome, or significant findings during execution. If none occurred, state "No significant issues encountered."]
+
+### Necessary follow-ups
+[Any follow-up actions or optimizations identified]

package/templates/strikethroo/config/templates/PLAN_TEMPLATE.md

@@ -0,0 +1,109 @@
+---
+id: [PLAN-ID]
+summary: "[Brief one-line description of what this plan accomplishes]"
+created: [YYYY-MM-DD]
+---
+
+# Plan: [Descriptive Plan Title]
+
+## Original Work Order
+[The unmodified user input that was used to generate this plan, as a quote]
+
+## Plan Clarifications [only add it if clarifications were necessary]
+[Clarification questions and answers in table format]
+
+## Executive Summary
+
+[Provide a 2-3 paragraph overview of the plan. Include:
+- What the plan accomplishes
+- Why this approach was chosen
+- Key benefits and outcomes expected]
+
+## Context
+
+### Current State vs Target State
+[Create a table that compares the current state with the target state in the different aspects of the implementation. Include a column on why the change is necessary.]
+
+Example:
+
+| Current State            | Target State | Why?                      |
+|--------------------------| ------------ |---------------------------|
+| Users have to click twice | Users can click once | We want to improve the UX |
+| The button is small | The button is bigger | Fix site design           |
+| ... | ... | ...                       |
+
+### Background
+[Any additional context, requirements, constraints, any solutions that we tried that didn't work, or relevant history that informs the implementation approach.]
+
+## Architectural Approach
+[Provide an overview of the implementation strategy, key architectural decisions, and technical approach. Break down into major components or phases using ### subheadings. Add a mermaid diagram summary.]
+
+### [Component/Stage 1 Name]
+**Objective**: [What this component accomplishes and why it's important]
+
+[Detailed & concise explanation of implementation approach, key technical decisions, specifications, and rationale for design choices.]
+
+### [Component/Stage 2 Name]
+**Objective**: [What this component accomplishes and why it's important]
+
+[Detailed & concise explanation of implementation approach, key technical decisions, specifications, and rationale for design choices.]
+
+### [Additional Components as Needed]
+[Continue with additional technical components or phases following the same pattern]
+
+## Risk Considerations and Mitigation Strategies
+
+<details>
+<summary>Technical Risks</summary>
+- **[Specific Technical Risk]**: [Description of the technical challenge or limitation]
+    - **Mitigation**: [Specific strategy to address this technical risk]
+</details>
+
+<details>
+<summary>Implementation Risks</summary>
+- **[Specific Implementation Risk]**: [Description of implementation-related challenge]
+    - **Mitigation**: [Specific strategy to address this implementation risk]
+</details>
+
+[Additional Risk Categories as Needed: continue with other risk categories such as Integration Risks, Quality Risks, Resource Risks, etc.]
+
+## Success Criteria
+
+### Primary Success Criteria
+1. [Measurable outcome 1]
+2. [Measurable outcome 2]
+3. [Measurable outcome 3]
+
+## Self Validation
+
+[Describe the concrete steps an LLM should execute after all tasks are completed to verify the implementation works correctly. These must be actionable verification procedures that inspect the real system — not just running pre-existing tests.
+
+Examples of good validation steps:
+- Use Playwright CLI to open a browser, navigate to the affected pages, and take screenshots to confirm the UI renders correctly
+- Run a CLI command to query the database and verify the expected configuration or content exists
+- Use `curl` or a browser automation tool to exercise the new API endpoints and confirm correct responses
+- Take a screenshot of the form/page/component and visually verify the expected elements are present
+- Run the application and interact with the new feature end-to-end, capturing evidence of success
+
+Avoid vague statements like "verify it works" or "ensure quality". Each step must be a specific, executable action.]
+
+## Documentation
+
+[Required documentation updates to existing documentation, either human-focused documentation like README.md or AI-facing documentation like AGENTS.md and related configuration files.]
+
+## Resource Requirements
+
+### Development Skills
+[Required technical expertise and specialized knowledge areas needed for successful implementation]
+
+### Technical Infrastructure
+[Tools, libraries, frameworks, and systems needed for development and deployment]
+
+### [Additional Resource Categories as Needed]
+[Other resources such as external dependencies, research access, third-party services, etc.]
+
+## Integration Strategy
+[Optional section - how this work integrates with existing systems]
+
+## Notes
+[Optional section - any additional considerations, constraints, or important context]

package/templates/strikethroo/config/templates/TASK_TEMPLATE.md

@@ -0,0 +1,36 @@
+---
+id: [TASK-ID]
+group: "user-authentication"
+dependencies: []  # List of task IDs, e.g., [2, 3]
+status: "[STATUS]"  # pending | in-progress | completed | needs-clarification
+created: [YYYY-MM-DD]
+skills: # Technical skills required for this task
+  - [SKILL-1]
+  - [SKILL-2]
+---
+# [TASK-TITLE]
+
+## Objective
+[Clear statement of what this task accomplishes]
+
+## Skills Required
+[Reference to the skills listed in frontmatter - these should align with the technical work needed]
+
+## Acceptance Criteria
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+Use your internal Todo tool to track these and keep on track.
+
+## Technical Requirements
+[Specific technical details, APIs, libraries, etc. - use this to infer appropriate skills]
+
+## Input Dependencies
+[What artifacts/code from other tasks are needed]
+
+## Output Artifacts
+[What this task produces for other tasks to consume]
+
+## Implementation Notes
+[Any helpful context or suggestions, including skill-specific guidance]