all-hands-cli 0.1.0

package/.allhands/flows/shared/jury/EXPECTATIONS_FIT_REVIEW.md

@@ -0,0 +1,78 @@
+<goal>
+Review implementation for engineer expectations fit. Per **Ideation First**, verify that implementation honors the desires, concerns, and decisions captured during ideation and planning.
+</goal>
+
+<inputs>
+- Alignment doc path
+- Spec doc path
+</inputs>
+
+<outputs>
+- Critical review of expectations fit
+- Improvements needed to better match expectations
+- Summary of expectation violations, ordered by priority
+</outputs>
+
+<constraints>
+- MUST read both spec doc and alignment doc completely
+- MUST account for all engineer decisions in alignment doc
+- MUST verify implementation against original ideation desires
+</constraints>
+
+## Context Gathering
+
+- Read the spec doc for original engineer expectations, desires, and success criteria
+- Read the alignment doc for planning decisions and engineer interjections
+- Identify implementation files changed from base branch
+- Read select prompts for detailed implementation context where necessary
+
+## Expectations Extraction
+
+From spec doc:
+- Engineer desires and expectations
+- Success criteria defined
+- Concerns raised during ideation
+- Guiding principles synthesized
+
+From alignment doc:
+- Planning decisions made
+- Engineer-specific interjections
+- Compromises documented
+- Scope adjustments
+
+## Review Process
+
+Compare implementation against expectations:
+
+| Check | Question |
+|-------|----------|
+| Desires | Are engineer's stated desires implemented? |
+| Success Criteria | Does implementation meet defined success criteria? |
+| Concerns | Were engineer's concerns addressed? |
+| Decisions | Are planning decisions honored? |
+| Scope | Does implementation match agreed scope? |
+| Goal Achievement | Does implementation achieve goals or just complete tasks? |
+
+Per **Quality Engineering**, task completion ≠ goal achievement. Verify implementation is substantive and connected, not placeholder-heavy.
+
+## Output Format
+
+Return findings ordered by priority:
+
+```
+## Expectations Fit Review
+
+### P1 (Expectation Gaps)
+- [Expectation]: [What was expected] -> [What was implemented] -> [Gap]
+
+### P2 (Partial Fit)
+- [Expectation]: [What was expected] -> [What was implemented] -> [What's missing]
+
+### P3 (Minor Deviations)
+- [Expectation]: [What was expected] -> [What was implemented] -> [Deviation]
+
+## Summary
+- [Total expectations reviewed]
+- [Fit percentage]
+- [Critical gaps requiring engineer attention]
+```

package/.allhands/flows/shared/jury/MAINTAINABILITY_REVIEW.md

@@ -0,0 +1,110 @@
+<goal>
+Review implementation for maintainability, code simplicity, and agentic anti-patterns. Per **Frontier Models are Capable**, identify hallucinations, duplications, and inter-prompt miscommunications. Per **Quality Engineering**, estimate simplification opportunities with LOC reduction.
+</goal>
+
+<inputs>
+- Git diff to base (implementation files)
+</inputs>
+
+<outputs>
+- Areas for improvement, ordered by priority
+- Simplification recommendations with before/after
+- LOC reduction estimates
+- Complexity score assessment
+- Agentic issues detected
+</outputs>
+
+<constraints>
+- MUST use git diff to base for implementation review
+- MUST compare against established codebase patterns
+- MUST identify agentic-specific anti-patterns
+</constraints>
+
+## Context Gathering
+
+- Review all implementation changes from base branch
+- Run `ah knowledge docs search "architecture"` for established patterns
+- Run `ah knowledge docs search "conventions"` for codebase standards
+
+## Agentic Anti-Patterns to Detect
+
+| Pattern | Description |
+|---------|-------------|
+| **Hallucination** | Imports that don't exist, APIs used incorrectly, made-up patterns |
+| **Duplication** | Re-implementing existing utilities, duplicate logic across prompts |
+| **Miscommunication** | Prompt A establishes pattern, Prompt B ignores it |
+| **Inconsistency** | Different approaches for same problem in different files |
+| **Over-abstraction** | Unnecessary wrappers, premature generalization |
+| **Orphaned Artifacts** | Files created but never imported or connected |
+
+## Design Quality Checks
+
+| Check | Question |
+|-------|----------|
+| Composability | Can components be reused independently? |
+| Naming | Are names descriptive and consistent? |
+| Structure | Does organization follow codebase conventions? |
+| Readability | Is the code self-documenting? |
+| Simplicity | Is this the simplest solution that works? |
+
+## Simplification Analysis
+
+For each file, identify:
+- **Unnecessary complexity** - Logic that could be simpler
+- **Redundant code** - Duplicate checks, repeated patterns
+- **Over-engineering** - Abstractions for single use cases
+- **Dead code** - Unused functions, unreachable branches
+
+Estimate LOC reduction for each simplification opportunity.
+
+## Review Process
+
+For each changed file:
+- Compare against similar existing code
+- Identify deviations from established patterns
+- Flag probable agentic issues
+- Note design inefficiencies
+- Estimate simplification potential (LOC)
+
+## Output Format
+
+Return findings ordered by priority:
+
+```
+## Maintainability Review
+
+### P1 (Critical)
+- [File:lines]: [Issue] -> [Impact] -> [Fix]
+
+### P2 (Important)
+- [File:lines]: [Issue] -> [Impact] -> [Fix]
+
+### P3 (Polish)
+- [File:lines]: [Issue] -> [Impact] -> [Fix]
+
+## Simplification Recommendations
+
+### 1. [Most impactful simplification]
+- **File**: [path:lines]
+- **Current**: [Brief description of current approach]
+- **Proposed**: [Simpler alternative]
+- **LOC reduction**: ~X lines
+
+### 2. [Next simplification]
+...
+
+## Agentic Issues Detected
+
+| Type | Count | Examples |
+|------|-------|----------|
+| Hallucinations | X | [Brief examples of made-up APIs/patterns] |
+| Duplications | X | [Brief examples of redundant code] |
+| Miscommunications | X | [Brief examples of inter-prompt conflicts] |
+
+## Complexity Assessment
+
+- **Total LOC added**: X
+- **Potential LOC reduction**: ~Y (Z%)
+- **Complexity score**: [High/Medium/Low]
+- **Recommendation**: [Proceed as-is / Minor simplifications / Significant refactoring needed]
+```

package/.allhands/flows/shared/jury/PROMPTS_EXPECTATIONS_FIT.md

@@ -0,0 +1,74 @@
+<goal>
+Review planning artifacts for engineer expectations fit. Per **Ideation First**, verify that prompts and alignment doc fully capture engineer desires from spec with no gaps or inconsistencies.
+</goal>
+
+<inputs>
+- Alignment doc path
+- Spec doc path
+- Prompts folder path
+</inputs>
+
+<outputs>
+- Review of expectations fit for planning artifacts
+- Improvements needed (by prompt number / alignment doc section)
+- Summary of expectation gaps, ordered by priority
+</outputs>
+
+<constraints>
+- MUST treat spec doc engineer expectations as ground truth
+- MUST identify inconsistencies between spec and planning artifacts
+- MUST find holes missed during planning consolidation
+</constraints>
+
+## Context Gathering
+
+- Read the spec doc for engineer expectations (ground truth)
+- Read the alignment doc for planning decisions
+- Read all prompts in the prompts folder
+
+## Expectations Comparison
+
+| Spec Element | Check |
+|--------------|-------|
+| Desires | Are they reflected in prompts? |
+| Success Criteria | Do prompts collectively achieve them? |
+| Concerns | Are they addressed in tasks? |
+| Assumptions | Are they validated by prompt dependencies? |
+| Open Questions | Were they resolved in alignment doc? |
+
+## Inconsistency Detection
+
+Look for:
+- Spec desires not covered by any prompt
+- Prompts that contradict spec expectations
+- Alignment doc decisions that deviate from spec without explanation
+- Holes in coverage (engineer expected X, nothing implements X)
+
+## Review Process
+
+For each spec expectation:
+- Trace to prompts that address it
+- Verify alignment doc documents any deviations
+- Flag gaps where planning missed expectations
+
+## Output Format
+
+Return findings ordered by priority:
+
+```
+## Prompts Expectations Fit Review
+
+### P1 (Missing Coverage)
+- [Spec expectation]: [What was expected] -> [No prompt addresses this]
+
+### P2 (Inconsistencies)
+- [Spec expectation]: [What was expected] -> [Prompt X says Y instead]
+
+### P3 (Clarification Needed)
+- [Spec element]: [Ambiguous] -> [Prompts interpret as X, but could be Y]
+
+## Summary
+- [Total spec expectations reviewed]
+- [Coverage percentage]
+- [Critical gaps requiring planner attention]
+```

package/.allhands/flows/shared/jury/PROMPTS_FLOW_ANALYSIS.md

@@ -0,0 +1,92 @@
+<goal>
+Analyze prompt dependencies and ordering for optimal derisking and parallelization. Per **Quality Engineering**, derisk the most critical logic first to reveal feasibility/stability signals as early as possible.
+</goal>
+
+<inputs>
+- Alignment doc path
+- Prompts folder path
+</inputs>
+
+<outputs>
+- Dependency analysis with parallelization opportunities
+- Reordering recommendations for derisking
+- Merge/conflict risk identification
+</outputs>
+
+<constraints>
+- MUST map all prompt dependencies
+- MUST identify critical path for derisking
+- MUST balance parallelization with merge risk
+</constraints>
+
+## Context Gathering
+
+- Read all prompts in the prompts folder
+- Extract `dependencies` from each prompt's frontmatter
+- Read alignment doc for goal priorities
+
+## Dependency Analysis
+
+Build dependency graph:
+- Map which prompts block which others
+- Identify prompts that can run in parallel
+- Find critical path (longest dependency chain)
+
+## Derisking Analysis
+
+Think like a tech lead engineer:
+
+| Priority | Question |
+|----------|----------|
+| Feasibility | Which prompts reveal if implementation is even possible? |
+| Stability | Which prompts prove core architecture works? |
+| Blockers | Which prompts unblock the most other work? |
+| Confidence | Which prompts give earliest signal on success? |
+| Wiring | Do prompts plan how components connect, not just create artifacts? |
+
+Order prompts to derisk:
+- Most important/revealing work first
+- Critical feasibility checks before polish
+- Foundation before features
+
+## Parallelization Opportunities
+
+For prompts that could run in parallel:
+- Assess merge/conflict risks
+- Identify setup/teardown dependencies
+- Consider file overlap risks
+
+| Risk Level | Criteria |
+|------------|----------|
+| Safe | No file overlap, independent domains |
+| Medium | Shared utilities, coordinated patterns |
+| High | Same files, database migrations, state |
+
+## Output Format
+
+Return findings ordered by priority:
+
+```
+## Prompts Flow Analysis
+
+### Critical Path
+1. Prompt X (blocks Y, Z)
+2. Prompt Y (blocks W)
+3. ...
+
+### Parallelization Opportunities
+- [Prompts A, B, C] can run in parallel (safe)
+- [Prompts D, E] can run in parallel (medium risk: shared utils)
+
+### Derisking Recommendations
+- P1: Move Prompt X earlier (reveals feasibility of core feature)
+- P2: Split Prompt Y into two (unblocks more parallelization)
+
+### Merge Risks
+- [Prompts N, M] have conflict risk if parallel (both touch auth)
+
+## Summary
+- [Critical path length]
+- [Parallelization potential]
+- [Reordering recommendations]
+```

package/.allhands/flows/shared/jury/PROMPTS_YAGNI.md

@@ -0,0 +1,78 @@
+<goal>
+Review planning artifacts for YAGNI (You Ain't Gonna Need It) violations. Per **Quality Engineering**, identify over-engineering and unnecessary complexity that wastes effort.
+</goal>
+
+<inputs>
+- Alignment doc path
+- Prompts folder path
+</inputs>
+
+<outputs>
+- YAGNI violations identified
+- Recommendations for simplification, ordered by priority
+</outputs>
+
+<constraints>
+- MUST give leniency to explicit engineer decisions
+- MUST still offer YAGNI perspective even on engineer-decided items (lower priority)
+- MUST distinguish agentic over-engineering from engineer-requested complexity
+</constraints>
+
+## Context Gathering
+
+- Read alignment doc for engineer decisions and rationale
+- Read all prompts in the prompts folder
+- Identify which elements were engineer-decided vs. agent-proposed
+
+## YAGNI Detection
+
+Look for:
+
+| Pattern | Description | Example |
+|---------|-------------|---------|
+| Premature Abstraction | Generalization before proven need | Helper class for one-time operation |
+| Future-Proofing | Building for hypothetical requirements | Config for thing that won't change |
+| Over-Configuration | Making unchanging things configurable | ENV var for hardcoded value |
+| Defensive Complexity | Error handling for impossible scenarios | Null check on required param |
+| Feature Creep | Scope beyond stated goals within planned prompts (note: `type: emergent` prompts and disposable variants are not feature creep per **Quality Engineering** - they discover which extensions are valuable) | "While we're here, let's add..." |
+| Scope Bloat | 10+ files or 7+ tasks in single prompt | Split needed |
+
+## Priority Weighting
+
+| Source | Priority Treatment |
+|--------|-------------------|
+| Agent-proposed complexity | Higher priority (agents over-engineer) |
+| Engineer-decided complexity | Lower priority (explicit awareness, but still offer perspective) |
+
+This respects engineer decisions while still providing value.
+
+## Review Process
+
+For each prompt/alignment doc element:
+- Is this necessary for stated goals?
+- Could this be simpler?
+- Is complexity justified by requirements?
+- Was this engineer-decided or agent-proposed?
+
+## Output Format
+
+Return findings ordered by priority:
+
+```
+## YAGNI Review
+
+### P1 (Agent-Proposed Over-Engineering)
+- [Prompt X]: [What's unnecessary] -> [Simpler alternative]
+- [Alignment decision Y]: [Why it's excessive] -> [Leaner approach]
+
+### P2 (Questionable Complexity)
+- [Element]: [What seems over-engineered] -> [Consider simplifying]
+
+### P3 (Engineer-Decided, Worth Reconsidering)
+- [Element]: [Engineer chose this, but YAGNI perspective suggests...] -> [Alternative if desired]
+
+## Summary
+- [Potential effort saved by simplification]
+- [Scope reduction opportunities]
+- [Complexity hotspots]
+```

package/.allhands/flows/shared/jury/PROMPT_PREMORTEM.md

@@ -0,0 +1,125 @@
+<goal>
+Identify failure modes in prompts before execution. Per **Quality Engineering**, detecting risks early prevents rework and wasted agent cycles.
+</goal>
+
+<inputs>
+- Alignment doc path
+- Prompts folder path
+</inputs>
+
+<outputs>
+Structured risk findings in REVIEW_OPTIONS_BREAKDOWN consumable format:
+- Tigers (clear threats requiring action)
+- Elephants (unspoken concerns worth surfacing)
+- Paper Tigers (looks scary but acceptable)
+</outputs>
+
+<constraints>
+- MUST verify every potential risk before flagging as Tiger
+- MUST read prompt files and alignment doc before flagging risks
+- MUST output in structured format for REVIEW_OPTIONS_BREAKDOWN
+- NEVER flag risks based on pattern-matching alone
+</constraints>
+
+## Risk Categories
+
+| Category | Symbol | Meaning | Action Required |
+|----------|--------|---------|-----------------|
+| **Tiger** | `[TIGER]` | Clear threat that will hurt if not addressed | Must address or accept |
+| **Paper Tiger** | `[PAPER]` | Looks threatening but probably fine | Acknowledge |
+| **Elephant** | `[ELEPHANT]` | Concern nobody mentioned yet | Surface for discussion |
+
+## Analysis Checklist
+
+Work through each category systematically for the prompt set:
+
+### Prompt Completeness
+- [ ] Every prompt has clear acceptance criteria?
+- [ ] Validation tooling referenced for each prompt?
+- [ ] Dependencies between prompts explicit?
+- [ ] Scope per prompt reasonable (2-3 tasks, <7 files)?
+
+### Technical Risks
+- [ ] External dependencies with fallbacks?
+- [ ] Breaking changes identified?
+- [ ] Migration/rollback path defined?
+- [ ] Security considerations for auth/data?
+- [ ] Error handling coverage?
+
+### Integration Risks
+- [ ] Components wire together (API → UI)?
+- [ ] Feature flags needed for partial delivery?
+- [ ] Testing strategy for cross-prompt work?
+
+### Process Risks
+- [ ] Requirements clear and complete?
+- [ ] Validation suites exist for domains touched?
+- [ ] Parallel execution conflicts avoided?
+
+## Verification Protocol
+
+Before flagging ANY Tiger, verify:
+
+```yaml
+potential_finding:
+  what: "<description of concern>"
+  prompt: "<prompt number(s) affected>"
+
+verification:
+  context_read: true    # Did I read the relevant prompts?
+  alignment_check: true # Is this addressed in alignment doc?
+  scope_check: true     # Is this actually in scope?
+
+result: tiger | paper_tiger | elephant | false_alarm
+```
+
+**If ANY verification check is "no" or "unknown", DO NOT flag as Tiger.**
+
+## Output Format
+
+Structure findings for REVIEW_OPTIONS_BREAKDOWN consumption:
+
+```yaml
+premortem:
+  prompts_analyzed: [01, 02, 03, ...]
+  alignment_doc: "<path>"
+
+  tigers:
+    - risk: "<description>"
+      prompts_affected: [01, 02]
+      severity: high | medium
+      category: completeness | technical | integration | process
+      mitigation_checked: "<what mitigation was looked for and NOT found>"
+      suggested_action: "<how to address>"
+
+  elephants:
+    - risk: "<unspoken concern worth surfacing>"
+      prompts_affected: [all | specific numbers]
+      severity: medium
+      suggested_action: "<what to discuss>"
+
+  paper_tigers:
+    - risk: "<looks scary but acceptable>"
+      reason: "<why it's fine - cite evidence from prompts/alignment>"
+      prompts_affected: [numbers]
+
+  checklist_gaps:
+    - category: "<which checklist section>"
+      items_failed: ["<item1>", "<item2>"]
+      prompts_affected: [numbers]
+```
+
+## Severity Guidelines
+
+| Severity | Criteria | Examples |
+|----------|----------|----------|
+| **High** | Blocks goal achievement, security risk, data loss | Missing auth check, no rollback plan, circular dependencies |
+| **Medium** | Quality impact, technical debt, maintenance burden | Missing tests, unclear acceptance criteria, over-engineering |
+
+## Integration with Review Flow
+
+This premortem output feeds directly into REVIEW_OPTIONS_BREAKDOWN:
+- Tigers become P1 (blocking) or P2 (recommended) items
+- Elephants become discussion points for engineer interview
+- Paper Tigers are documented as acknowledged acceptable risks
+- Checklist gaps inform specific prompt amendments

package/.allhands/flows/shared/jury/SECURITY_REVIEW.md

@@ -0,0 +1,86 @@
+<goal>
+Review implementation for security vulnerabilities and risks. Per **Agentic Validation Tooling**, identify security issues that programmatic validation may have missed.
+</goal>
+
+<inputs>
+- Alignment doc path
+- Prompts folder path
+</inputs>
+
+<outputs>
+- Security vulnerabilities identified
+- Risk assessment and remediation recommendations, ordered by priority
+</outputs>
+
+<constraints>
+- MUST use git diff to base for implementation review
+- MUST check alignment doc for security-specific decisions
+- MUST focus on OWASP Top 10 and common vulnerability patterns
+</constraints>
+
+## Context Gathering
+
+- Review all implementation changes from base branch
+- Read alignment doc for security decisions made during planning
+- Identify security-sensitive areas touched
+
+## Vulnerability Categories
+
+| Category | Check For |
+|----------|-----------|
+| Injection | SQL, command, LDAP, XPath injection |
+| Auth | Broken authentication, session management |
+| XSS | Cross-site scripting vectors |
+| IDOR | Insecure direct object references |
+| Misconfig | Security misconfigurations |
+| Exposure | Sensitive data exposure |
+| Access Control | Broken access control |
+| CSRF | Cross-site request forgery |
+| Dependencies | Known vulnerable components |
+| Logging | Insufficient logging and monitoring |
+
+## Implementation Review
+
+For each changed file:
+
+| File Type | Security Focus |
+|-----------|----------------|
+| API endpoints | Input validation, auth, authorization |
+| Database queries | Parameterization, access control |
+| Frontend | XSS prevention, CSRF tokens, secure storage |
+| Config files | Secrets exposure, default credentials |
+| Auth code | Token handling, session management |
+
+## Risk Assessment
+
+| Severity | Criteria |
+|----------|----------|
+| Critical | Remotely exploitable, data breach risk |
+| High | Significant vulnerability, requires attention |
+| Medium | Security weakness, should be addressed |
+| Low | Minor issue, improve when convenient |
+
+## Output Format
+
+Return findings ordered by priority:
+
+```
+## Security Review
+
+### Critical
+- [File:line]: [Vulnerability] -> [Risk] -> [Remediation]
+
+### High
+- [File:line]: [Vulnerability] -> [Risk] -> [Remediation]
+
+### Medium
+- [File:line]: [Vulnerability] -> [Risk] -> [Remediation]
+
+### Low
+- [File:line]: [Issue] -> [Recommendation]
+
+## Summary
+- [Total vulnerabilities found]
+- [Risk score]
+- [Immediate actions required]
+```