drt-method 1.0.0

package/src/drt-skills/3-solutioning/drt-check-implementation-readiness/steps/step-05-epic-quality-review.md

@@ -0,0 +1,241 @@
+---
+outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
+---
+
+# Step 5: Epic Quality Review
+
+## STEP GOAL:
+
+To validate epics and stories against the best practices defined in create-epics-and-stories workflow, focusing on user value, independence, dependencies, and implementation readiness.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an EPIC QUALITY ENFORCER
+- ✅ You know what good epics look like - challenge anything deviating
+- ✅ Technical epics are wrong - find them
+- ✅ Forward dependencies are forbidden - catch them
+- ✅ Stories must be independently completable
+
+### Step-Specific Rules:
+
+- 🎯 Apply create-epics-and-stories standards rigorously
+- 🚫 Don't accept "technical milestones" as epics
+- 💬 Challenge every dependency on future work
+- 🚪 Verify proper story sizing and structure
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Systematically validate each epic and story
+- 💾 Document all violations of best practices
+- 📖 Check every dependency relationship
+- 🚫 FORBIDDEN to accept structural problems
+
+## EPIC QUALITY REVIEW PROCESS:
+
+### 1. Initialize Best Practices Validation
+
+"Beginning **Epic Quality Review** against create-epics-and-stories standards.
+
+I will rigorously validate:
+
+- Epics deliver user value (not technical milestones)
+- Epic independence (Epic 2 doesn't need Epic 3)
+- Story dependencies (no forward references)
+- Proper story sizing and completeness
+
+Any deviation from best practices will be flagged as a defect."
+
+### 2. Epic Structure Validation
+
+#### A. User Value Focus Check
+
+For each epic:
+
+- **Epic Title:** Is it user-centric (what user can do)?
+- **Epic Goal:** Does it describe user outcome?
+- **Value Proposition:** Can users benefit from this epic alone?
+
+**Red flags (violations):**
+
+- "Setup Database" or "Create Models" - no user value
+- "API Development" - technical milestone
+- "Infrastructure Setup" - not user-facing
+- "Authentication System" - borderline (is it user value?)
+
+#### B. Epic Independence Validation
+
+Test epic independence:
+
+- **Epic 1:** Must stand alone completely
+- **Epic 2:** Can function using only Epic 1 output
+- **Epic 3:** Can function using Epic 1 & 2 outputs
+- **Rule:** Epic N cannot require Epic N+1 to work
+
+**Document failures:**
+
+- "Epic 2 requires Epic 3 features to function"
+- Stories in Epic 2 referencing Epic 3 components
+- Circular dependencies between epics
+
+### 3. Story Quality Assessment
+
+#### A. Story Sizing Validation
+
+Check each story:
+
+- **Clear User Value:** Does the story deliver something meaningful?
+- **Independent:** Can it be completed without future stories?
+
+**Common violations:**
+
+- "Setup all models" - not a USER story
+- "Create login UI (depends on Story 1.3)" - forward dependency
+
+#### B. Acceptance Criteria Review
+
+For each story's ACs:
+
+- **Given/When/Then Format:** Proper BDD structure?
+- **Testable:** Each AC can be verified independently?
+- **Complete:** Covers all scenarios including errors?
+- **Specific:** Clear expected outcomes?
+
+**Issues to find:**
+
+- Vague criteria like "user can login"
+- Missing error conditions
+- Incomplete happy path
+- Non-measurable outcomes
+
+### 4. Dependency Analysis
+
+#### A. Within-Epic Dependencies
+
+Map story dependencies within each epic:
+
+- Story 1.1 must be completable alone
+- Story 1.2 can use Story 1.1 output
+- Story 1.3 can use Story 1.1 & 1.2 outputs
+
+**Critical violations:**
+
+- "This story depends on Story 1.4"
+- "Wait for future story to work"
+- Stories referencing features not yet implemented
+
+#### B. Database/Entity Creation Timing
+
+Validate database creation approach:
+
+- **Wrong:** Epic 1 Story 1 creates all tables upfront
+- **Right:** Each story creates tables it needs
+- **Check:** Are tables created only when first needed?
+
+### 5. Special Implementation Checks
+
+#### A. Starter Template Requirement
+
+Check if Architecture specifies starter template:
+
+- If YES: Epic 1 Story 1 must be "Set up initial project from starter template"
+- Verify story includes cloning, dependencies, initial configuration
+
+#### B. Greenfield vs Brownfield Indicators
+
+Greenfield projects should have:
+
+- Initial project setup story
+- Development environment configuration
+- CI/CD pipeline setup early
+
+Brownfield projects should have:
+
+- Integration points with existing systems
+- Migration or compatibility stories
+
+### 6. Best Practices Compliance Checklist
+
+For each epic, verify:
+
+- [ ] Epic delivers user value
+- [ ] Epic can function independently
+- [ ] Stories appropriately sized
+- [ ] No forward dependencies
+- [ ] Database tables created when needed
+- [ ] Clear acceptance criteria
+- [ ] Traceability to FRs maintained
+
+### 7. Quality Assessment Documentation
+
+Document all findings by severity:
+
+#### 🔴 Critical Violations
+
+- Technical epics with no user value
+- Forward dependencies breaking independence
+- Epic-sized stories that cannot be completed
+
+#### 🟠 Major Issues
+
+- Vague acceptance criteria
+- Stories requiring future stories
+- Database creation violations
+
+#### 🟡 Minor Concerns
+
+- Formatting inconsistencies
+- Minor structure deviations
+- Documentation gaps
+
+### 8. Autonomous Review Execution
+
+This review runs autonomously to maintain standards:
+
+- Apply best practices without compromise
+- Document every violation with specific examples
+- Provide clear remediation guidance
+- Prepare recommendations for each issue
+
+## REVIEW COMPLETION:
+
+After completing epic quality review:
+
+- Update {outputFile} with all quality findings
+- Document specific best practices violations
+- Provide actionable recommendations
+- Load ./step-06-final-assessment.md for final readiness assessment
+
+## CRITICAL STEP COMPLETION NOTE
+
+This step executes autonomously. Load ./step-06-final-assessment.md only after complete epic quality review is documented.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All epics validated against best practices
+- Every dependency checked and verified
+- Quality violations documented with examples
+- Clear remediation guidance provided
+- No compromise on standards enforcement
+
+### ❌ SYSTEM FAILURE:
+
+- Accepting technical epics as valid
+- Ignoring forward dependencies
+- Not verifying story sizing
+- Overlooking obvious violations
+
+**Master Rule:** Enforce best practices rigorously. Find all violations.

package/src/drt-skills/3-solutioning/drt-check-implementation-readiness/steps/step-06-final-assessment.md

@@ -0,0 +1,132 @@
+---
+outputFile: '{planning_artifacts}/implementation-readiness-report-{{date}}.md'
+---
+
+# Step 6: Final Assessment
+
+## STEP GOAL:
+
+To provide a comprehensive summary of all findings and give the report a final polish, ensuring clear recommendations and overall readiness status.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 📖 You are at the final step - complete the assessment
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are delivering the FINAL ASSESSMENT
+- ✅ Your findings are objective and backed by evidence
+- ✅ Provide clear, actionable recommendations
+- ✅ Success is measured by value of findings
+
+### Step-Specific Rules:
+
+- 🎯 Compile and summarize all findings
+- 🚫 Don't soften the message - be direct
+- 💬 Provide specific examples for problems
+- 🚪 Add final section to the report
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Review all findings from previous steps
+- 💾 Add summary and recommendations
+- 📖 Determine overall readiness status
+- 🚫 Complete and present final report
+
+## FINAL ASSESSMENT PROCESS:
+
+### 1. Initialize Final Assessment
+
+"Completing **Final Assessment**.
+
+I will now:
+
+1. Review all findings from previous steps
+2. Provide a comprehensive summary
+3. Add specific recommendations
+4. Determine overall readiness status"
+
+### 2. Review Previous Findings
+
+Check the {outputFile} for sections added by previous steps:
+
+- File and FR Validation findings
+- UX Alignment issues
+- Epic Quality violations
+
+### 3. Add Final Assessment Section
+
+Append to {outputFile}:
+
+```markdown
+## Summary and Recommendations
+
+### Overall Readiness Status
+
+[READY/NEEDS WORK/NOT READY]
+
+### Critical Issues Requiring Immediate Action
+
+[List most critical issues that must be addressed]
+
+### Recommended Next Steps
+
+1. [Specific action item 1]
+2. [Specific action item 2]
+3. [Specific action item 3]
+
+### Final Note
+
+This assessment identified [X] issues across [Y] categories. Address the critical issues before proceeding to implementation. These findings can be used to improve the artifacts or you may choose to proceed as-is.
+```
+
+### 4. Complete the Report
+
+- Ensure all findings are clearly documented
+- Verify recommendations are actionable
+- Add date and assessor information
+- Save the final report
+
+### 5. Present Completion
+
+Display:
+"**Implementation Readiness Assessment Complete**
+
+Report generated: {outputFile}
+
+The assessment found [number] issues requiring attention. Review the detailed report for specific findings and recommendations."
+
+## WORKFLOW COMPLETE
+
+The implementation readiness workflow is now complete. The report contains all findings and recommendations for the user to consider.
+
+Implementation Readiness complete. Invoke the `drt-help` skill.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+
+- All findings compiled and summarized
+- Clear recommendations provided
+- Readiness status determined
+- Final report saved
+
+### ❌ SYSTEM FAILURE:
+
+- Not reviewing previous findings
+- Incomplete summary
+- No clear recommendations
+
+## On Complete
+
+Run: `node {project-root}/_drt/scripts/resolve-customization.js --skill {skill-root} --key workflow.on_complete`
+
+If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/drt-skills/3-solutioning/drt-check-implementation-readiness/templates/readiness-report-template.md

@@ -0,0 +1,4 @@
+# Implementation Readiness Assessment Report
+
+**Date:** {{date}}
+**Project:** {{project_name}}

package/src/drt-skills/3-solutioning/drt-create-architecture/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: drt-create-architecture
+description: 'DEPRECATED — consolidated into drt-architecture create intent - this skill will be removed in v7 in favor of `drt-architecture`.'
+---
+
+# DEPRECATED — forwards to drt-architecture (create intent)
+
+This skill was consolidated into `drt-architecture`. It is retained as a thin compatibility shim so existing invocations by name and `_drt/custom/drt-create-architecture.toml` override files keep working. New work should invoke `drt-architecture` directly — it detects create / update / validate intent from the conversation.
+
+## On Activation
+
+1. Resolve customization: `node {project-root}/_drt/scripts/resolve-customization.js --skill {skill-root} --key workflow`. This picks up any `{project-root}/_drt/custom/drt-create-architecture.toml` and `drt-create-architecture.user.toml` overrides for the legacy fields (`activation_steps_prepend`, `activation_steps_append`, `persistent_facts`, `on_complete`).
+
+2. Load `{project-root}/_drt/drt/config.yaml` (and `config.user.yaml` if present) to resolve `{user_name}` and `{communication_language}`.
+
+3. Emit a deprecation notice to the user in `{communication_language}`:
+
+   > Notice: `drt-create-architecture` is deprecated and will be removed in a future release. It now forwards to `drt-architecture` with create intent. To silence this notice and access the full new customization surface (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), migrate `_drt/custom/drt-create-architecture.toml` to `_drt/custom/drt-architecture.toml` and invoke `drt-architecture` directly next time. Customization fields that were in this version still remain in the new version and will be respected if present in `_drt/custom/drt-architecture.toml`, but the new version also supports additional fields that you can take advantage of by migrating.
+
+4. Invoke `drt-architecture` with the following context. Pass these as the activating context so `drt-architecture` honors them instead of resolving its own customization from scratch:
+
+   - **Intent:** `create` — skip `drt-architecture`'s usual intent detection step.
+   - **Pre-resolved legacy customization** — use these in place of resolving from `drt-architecture`'s own `customize.toml` for the four legacy fields. For everything else (`spine_template`, `spine_output_path`, `run_folder_pattern`, `doc_standards`, `external_sources`, `external_handoffs`, `finalize_reviewers`), use `drt-architecture`'s own defaults and overrides as normal:
+     - `activation_steps_prepend` = the resolved value from step 1
+     - `activation_steps_append` = the resolved value from step 1
+     - `persistent_facts` = the resolved value from step 1
+     - `on_complete` = the resolved value from step 1
+   - **Original user input:** forward whatever the user said when invoking this skill verbatim.
+
+   `drt-architecture` takes the workflow from here. Do not execute any further steps in this shim.

package/src/drt-skills/3-solutioning/drt-create-architecture/customize.toml

@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for drt-create-architecture. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per DRT structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+#   - a literal sentence, e.g. "Our org is AWS-only -- do not propose GCP or Azure."
+#   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+#     (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches Step 8 (Architecture Completion & Handoff),
+# after the architecture document frontmatter is updated and next-steps guidance is given.
+# Override wins. Leave empty for no custom post-completion behavior.
+
+on_complete = ""

package/src/drt-skills/3-solutioning/drt-create-epics-and-stories/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: drt-create-epics-and-stories
+description: 'Break requirements into epics and user stories. Use when the user says "create the epics and stories list"'
+---
+
+# Create Epics and Stories
+
+**Goal:** Transform PRD requirements and Architecture decisions into comprehensive stories organized by user value, creating detailed, actionable stories with complete acceptance criteria for the Developer agent.
+
+**Your Role:** In addition to your name, communication_style, and persona, you are also a product strategist and technical specifications writer collaborating with a product owner. This is a partnership, not a client-vendor relationship. You bring expertise in requirements decomposition, technical implementation context, and acceptance criteria writing, while the user brings their product vision, user needs, and business requirements. Work together as equals.
+
+## Conventions
+
+- Bare paths (e.g. `steps/step-01-validate-prerequisites.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step toward the overall goal is a self-contained instruction file; adhere to one file at a time, as directed
+- **Just-In-Time Loading**: Only 1 current step file will be loaded and followed to completion - never load future step files until told to do so
+- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
+- **Append-Only Building**: Build documents by appending content as directed to the output file
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **LOAD NEXT**: When directed, read fully and follow the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- 🛑 **NEVER** load multiple step files simultaneously
+- 📖 **ALWAYS** read entire step file before execution
+- 🚫 **NEVER** skip steps or optimize the sequence
+- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
+- 🎯 **ALWAYS** follow the exact instructions in the step file
+- ⏸️ **ALWAYS** halt at menus and wait for user input
+- 📋 **NEVER** create mental todo lists from future steps
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `node {project-root}/_drt/scripts/resolve-customization.js --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_drt/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_drt/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_drt/drt/config.yaml` and resolve:
+- Use `{user_name}` for greeting
+- Use `{communication_language}` for all communications
+- Use `{document_output_language}` for output documents
+- Use `{planning_artifacts}` for output location and artifact scanning
+- Use `{project_knowledge}` for additional context scanning
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
+
+## Execution
+
+Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.

package/src/drt-skills/3-solutioning/drt-create-epics-and-stories/customize.toml

@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for drt-create-epics-and-stories. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per DRT structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+#   - a literal sentence, e.g. "All epics must deliver complete end-to-end user value."
+#   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+#     (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches Step 4 (Final Validation) and the
+# user confirms [C] Complete — after the epics.md is saved and drt-help is invoked.
+# Override wins. Leave empty for no custom post-completion behavior.
+
+on_complete = ""