sherpa-skill 2.0.6 → 2.0.7

package/.agents/skills/sherpa/workflows/judge-simulation.md

@@ -0,0 +1,408 @@
+# sherpa — Judge Simulation Workflow
+
+**Operation:** JUDGE-SIM  
+**Purpose:** Simulate how a realistic hackathon judge would perceive the project. Identify what judges would notice, question, misunderstand, praise, distrust, or penalize. Phase 9 is a judge simulation intelligence engine — it reviews and recommends; it does not optimize scores or change the project.
+
+**Pipeline:**
+Read Project State → Verify Readiness → Read Hackathon Rules / Criteria → Read Phase 2 Evaluation → Read Phase 3 Project Plan → Read Phase 4 Implementation Evidence → Read Phase 5 Testing/Security Evidence → Read Phase 7 UX Evidence → Read Phase 8 Red Team Evidence → Inspect Actual Repository → Inspect Actual Demo Flow → Build Judge Perspective → Evaluate Each Criterion → Simulate Judge Questions → Challenge Claims → Assess Judge Confidence → Identify Judge Concerns → Prioritize Preparation Needs → Produce Judge Simulation Report → Update Project State → Return Exactly ONE Primary Next Action
+
+---
+
+## When to Use
+
+Use JUDGE-SIM when:
+- A hackathon idea has been selected and implementation baseline exists
+- You want to anticipate how judges would perceive the project
+- You need to understand what judges would question, trust, or distrust
+
+**Prerequisite:** `.sherpa/project-state.md` must exist with `selected idea` known, Phase 2 idea evaluation, Phase 3 project plan, Phase 4 implementation evidence, Phase 5 testing/security evidence, Phase 7 UX evidence, and Phase 8 Red Team evidence.
+
+---
+
+## Pipeline Stages
+
+### Stage 1: Read Project State
+
+Read `.sherpa/project-state.md`:
+- Hackathon name, deadline, time remaining
+- Judging criteria and weights
+- Problem statement, target users
+- Selected idea (must be known)
+- Phase 2 decision outcome
+- Phase 3 architecture status
+- Phase 4 implementation status
+- Phase 5 test/security evidence
+- Phase 7 UX evidence
+- Phase 8 Red Team evidence
+
+If `selected idea` is UNKNOWN:
+- STOP normal judge simulation.
+- Do not invent a selected idea.
+- Return: selected idea is unknown, JUDGE-SIM cannot produce a normal simulation yet, exactly one primary next action: confirm the selected idea.
+
+If required information is missing:
+- Mark as UNKNOWN
+- Report JUDGE-SIM = BLOCKED or LIMITED
+- Do not invent readiness
+
+### Stage 2: Verify Readiness
+
+Check:
+- Hackathon rules / judging criteria exist (or mark UNKNOWN)
+- Phase 2 idea evaluation exists
+- Phase 3 project plan exists
+- Phase 4 implementation status is known
+- Phase 5 testing/security evidence exists
+- Phase 7 UX evidence exists
+- Phase 8 Red Team evidence exists
+
+If required information is missing:
+- Mark as UNKNOWN
+- Report JUDGE-SIM = BLOCKED or LIMITED
+- Do not invent readiness
+
+### Stage 3: Read Hackathon Rules / Criteria
+
+Read the hackathon's official judging criteria and weights:
+- Capture each criterion name and weight
+- If criteria/weights are UNKNOWN, mark UNKNOWN
+- Do NOT invent criteria or weights
+- Do NOT invent weights
+
+### Stage 4: Read Phase 2 Idea Evaluation
+
+Read `.sherpa/decisions.md` and `.sherpa/evaluations/<idea-name>.md`:
+- Selected idea name
+- Evaluation scores
+- Red-team outcomes from Phase 2
+- Rejected ideas and reasons
+- MVP scope
+
+### Stage 5: Read Phase 3 Project Plan
+
+Read `.sherpa/evidence/project-plan-*.md`:
+- Current architecture
+- Proposed architecture
+- MVP scope (MUST/SHOULD/OPTIONAL/EXCLUDED)
+- Implementation workstreams
+- Dependencies
+- Critical path
+- Technical risks
+- Time strategy
+
+### Stage 6: Read Phase 4 Implementation Evidence
+
+Read `.sherpa/evidence/` implementation artifacts:
+- Repository baseline
+- Components implemented
+- Tests executed
+- Deployment configuration
+- Known issues
+
+### Stage 7: Read Phase 5 Testing/Security Evidence
+
+Read `.sherpa/evidence/` testing/security artifacts:
+- Test results
+- Security findings
+- Blocked tests
+- Regression risks
+- Known failures
+
+Do not duplicate the Phase 5 testing/security engine. Consume its evidence only.
+
+### Stage 8: Read Phase 7 UX Evidence
+
+Read `.sherpa/ux-review.md` and `.sherpa/ux/` artifacts:
+- UX baseline
+- Critical flows
+- Findings
+- Quality gate status
+- Limitations
+
+Do not duplicate the Phase 7 UX engine. Consume its evidence only.
+
+### Stage 9: Read Phase 8 Red Team Evidence
+
+Read `.sherpa/red-team.md` and `.sherpa/red-team/` artifacts:
+- Red team findings
+- Risks
+- Mitigations
+- Quality gate status
+- Limitations
+
+Do not duplicate the Phase 8 Red Team engine. Consume its evidence only.
+
+### Stage 10: Inspect Current Repository
+
+Inspect the actual repository:
+- Project metadata
+- Dependency manifests
+- Top-level project structure
+- Application entry points
+- Frontend/backend/database/AI components
+- APIs
+- Tests
+- Deployment configuration
+- Documentation
+- Environment configuration
+
+Evidence classification (for every observation):
+- FACT: Directly observed
+- INFERENCE: Logical conclusion from facts
+- ASSUMPTION: Not yet verified
+- UNKNOWN: No information available
+
+Rules:
+- Never fabricate repository facts.
+- Execution claims require execution evidence.
+- Seeing a test file does NOT mean tests pass.
+- Generated sherpa artifacts are not independent evidence.
+
+### Stage 11: Inspect Actual Demo Flow
+
+Inspect the actual demo path if available:
+- Judge opens project
+- Initial understanding
+- First interaction
+- Core action
+- Result
+- Secondary behavior
+- Error/recovery
+- Completion
+
+Record:
+- Steps
+- Time
+- Visible output
+- Confusion points
+- Failure points
+- Recovery
+- Missing context
+- Judge-visible value
+
+Do not claim a demo was executed unless it was actually executed. If dynamic execution is unavailable:
+
+```text
+Demo execution = NOT_TESTED
+```
+
+### Stage 12: Build Judge Perspective
+
+Build simulation from multiple judge personas:
+- Technical Judge
+- Product Judge
+- Demo Judge
+- Skeptical Judge
+
+Do not assume every hackathon uses these exact judge types. They are simulation personas only.
+
+### Stage 13: Evaluate Each Criterion
+
+For each judging criterion:
+- Map to actual evidence
+- Identify strengths and weaknesses
+- Determine likely judge reaction
+- Assign confidence
+- Identify unknowns
+
+If official criteria exist, use them exactly. If UNKNOWN, mark UNKNOWN.
+
+### Stage 14: Simulate Judge Questions
+
+Construct questions a judge would ask:
+- Each question: ID, persona, question text, why asked, relevant criterion, expected answer points, evidence, potential trap, confidence
+- Map questions to criteria
+- Do not fabricate judge answers
+
+### Stage 15: Challenge Claims
+
+Cross-check claims against:
+- Phase 2 evidence
+- Phase 3 project plan
+- Phase 4 implementation
+- Phase 5 testing/security
+- Phase 7 UX
+- Phase 8 Red Team
+- repository
+- demo
+
+Flag contradictions:
+
+```text
+Documentation says X
+Repository does Y
+Demo shows Z
+```
+
+Do not silently reconcile contradictions. Record them.
+
+### Stage 16: Assess Judge Confidence
+
+Assess whether a skeptical judge could trust the project's claims:
+- claims backed by evidence
+- metrics backed by evidence
+- documentation consistent with implementation
+- demo consistent with repository
+- no exaggerated AI claims
+- no unsupported production claims
+- limitations visible
+
+If evidence is missing:
+
+```text
+UNKNOWN
+```
+
+### Stage 17: Identify Judge Concerns
+
+Identify concerns judges would raise:
+- unsupported claims
+- weak differentiation
+- demo failure risk
+- technical credibility issues
+- UX problems
+- missing evidence
+- hidden limitations
+
+Assign severity:
+- CRITICAL, HIGH, MEDIUM, LOW, INFO, UNKNOWN
+
+Do not inflate severity.
+
+### Stage 18: Prioritize Preparation Needs
+
+Priority order:
+1. CRITICAL demo failure
+2. CRITICAL credibility issue
+3. HIGH reliability risk
+4. HIGH differentiation weakness
+5. HIGH unsupported claim
+6. HIGH UX/demo friction
+7. important technical risk
+8. evidence gaps
+9. medium risks
+10. low-risk polish
+
+Do not prioritize cosmetic issues over project-breaking risks.
+
+### Stage 19: Produce Judge Simulation Report
+
+Use `templates/judge-simulation.md` as the record format.
+
+Save to `.sherpa/judge-simulation.md`.
+
+Include:
+- Project
+- Judge personas simulated
+- Judging criteria and weights
+- Current state
+- Target outcome
+- Current architecture
+- Proposed architecture
+- Components
+- Data flow
+- APIs/interfaces
+- Database/storage
+- AI/ML
+- External services
+- Deployment
+- MVP
+- MUST/SHOULD/OPTIONAL/EXCLUDED
+- Implementation workstreams
+- Dependencies
+- Critical path
+- Technical risks
+- Security priorities
+- Testing priorities
+- UX priorities
+- Time strategy
+- Judge questions
+- Expected answer quality
+- Likely objections
+- Technical credibility
+- Product credibility
+- Demo credibility
+- Claim consistency
+- Differentiation perception
+- Judge trust
+- Critical preparation risks
+- Unknowns
+- Time strategy
+- Judge readiness
+- Primary next action
+
+### Stage 20: Update Project State
+
+Update ONLY these compact fields in `.sherpa/project-state.md`:
+
+| Field | New Value |
+|-------|-----------|
+| Judge Simulation Status | NOT_STARTED | IN_PROGRESS | BLOCKED | COMPLETE |
+| Judge Baseline | UNKNOWN | VERIFIED |
+| Judge Criteria | UNKNOWN | IDENTIFIED | REVIEWED |
+| Critical Judge Concerns | UNKNOWN | NONE | IDENTIFIED |
+| Judge Readiness | NOT_READY | IN_PROGRESS | BLOCKED | CONDITIONAL | READY |
+
+Rules:
+- Do NOT put detailed judge simulation inside project-state.md.
+- Detailed material goes to `.sherpa/judge-simulation.md` and `.sherpa/judge/`.
+- Do not change `selected idea`.
+- Do not silently change architecture.
+- Human approval required for architecture changes.
+
+### Stage 21: Return Exactly One Primary Next Action
+
+Output format:
+
+```
+PRIMARY NEXT ACTION: <exactly one action>
+
+WHY: <explanation based on impact, time, risk, and judging criteria>
+
+DONE WHEN: <clear definition of done>
+
+Time remaining: <hours or UNKNOWN>
+
+Blocked by: <blocker or "None">
+```
+
+Rule: Exactly one primary next action. Do not produce competing alternatives.
+
+---
+
+## Validation Checklist
+
+After JUDGE-SIM completes:
+
+- [ ] Selected idea verified (or gate triggered)
+- [ ] Readiness verified (or BLOCKED/LIMITED reported)
+- [ ] Phase 2–8 evidence consumed
+- [ ] Repository inspected
+- [ ] Judging criteria identified (or UNKNOWN)
+- [ ] Judge personas identified
+- [ ] First impression evaluated
+- [ ] Judge-visible strengths and weaknesses identified
+- [ ] Criterion-by-criterion observations made
+- [ ] Simulated judge questions created
+- [ ] Expected answer quality assessed
+- [ ] Likely objections documented
+- [ ] Technical credibility assessed
+- [ ] Product credibility assessed
+- [ ] Demo credibility assessed
+- [ ] Claim consistency checked
+- [ ] Differentiation perception evaluated
+- [ ] Judge trust assessed
+- [ ] Critical preparation risks identified
+- [ ] Unknowns documented
+- [ ] Time-aware strategy applied
+- [ ] Unknown deadline not assumed
+- [ ] Judge readiness gate evaluated
+- [ ] No application source code modified
+- [ ] No Phase 1–8 files modified
+- [ ] No Phase 5/7/8 engines duplicated
+- [ ] No score optimization performed
+- [ ] No simulated score presented as official score
+- [ ] No idea silently changed
+- [ ] No architecture silently redesigned
+- [ ] project-state.md remains compact
+- [ ] Exactly ONE primary next action returned

package/.agents/skills/sherpa/workflows/lifecycle.md

@@ -0,0 +1,51 @@
+# sherpa Lifecycle
+
+Defines the hackathon lifecycle phases and how the skill transitions between them. The lifecycle is time-aware: strategy changes based on time remaining until the deadline.
+
+## Lifecycle Phases
+
+| Phase | When | Primary Focus |
+|-------|------|---------------|
+| Understand Rules | Start | Read hackathon rules, judging criteria, submission requirements |
+| Analyze Problem | Start | Understand the problem statement, target users, constraints |
+| Generate Ideas | Early | Brainstorm and capture candidate ideas |
+| Validate Ideas | Early | Evaluate ideas against judging criteria, feasibility, differentiation |
+| Research Market | Early | Research existing solutions and competitors |
+| Select Idea | Early-Mid | Choose the strongest idea to build |
+| Design Product/MVP | Mid | Define product scope, MVP, user flows |
+| Architecture | Mid | Decide technical architecture, tech stack |
+| Development Plan | Mid | Create implementation plan with time estimates |
+| Implementation | Mid-Late | Build the MVP |
+| Testing + Security | Late | Test the project, secure the application |
+| UX Review | Late | Review and improve UI/UX |
+| Red Team | Late | Actively find reasons the project could lose |
+| Judge Simulation | Late | Simulate multiple judge types |
+| Score Optimization | Late | Optimize based on judging criteria gaps |
+| Demo Preparation | Final | Prepare the demo |
+| PPT / Presentation | Final | Prepare the presentation |
+| Final Audit | Final | Final consistency and claim verification |
+| Submission | Final | Submit the project |
+| Post-Mortem | After | Analyze what worked and what didn't |
+
+## Time-Aware Strategy
+
+The skill adjusts its recommendations based on time remaining:
+
+| Time Remaining | Strategy | What to STOP |
+|----------------|----------|--------------|
+| > 24 hours | Core product, differentiation, architecture, important features, validation | Low-judging-value features |
+| 12–24 hours | Completing MVP, high-impact features, integration, testing | New feature exploration |
+| 6–12 hours | Stability, testing, UX, security, demo reliability, presentation | Architectural changes |
+| 2–6 hours | Bug fixing, demo flow, critical polish, PPT, documentation, deployment reliability | Any new feature development |
+| < 2 hours | Build working, deployment working, demo working, PPT accurate, links working, critical bugs fixed, submission requirements satisfied | All feature development |
+
+## How the Router Determines Phase
+
+1. Read `.sherpa/project-state.md`.
+2. Check the `Phase` field (if `UNKNOWN`, default to "Understand Rules").
+3. Check `Time remaining` against the deadline.
+4. The phase + time remaining determine which workflow guidance applies.
+
+## Persistence
+
+The lifecycle phase and time remaining are stored in `.sherpa/project-state.md` and updated on every skill invocation.

package/.agents/skills/sherpa/workflows/next.md

@@ -0,0 +1,96 @@
+# sherpa — NEXT Workflow
+
+**Operation**: NEXT  
+**Purpose**: Identify exactly ONE highest-priority action to take right now, based on project state, time remaining, risks, and judging criteria.
+
+## When to Use
+
+Use NEXT when:
+- You need to know what to work on right now
+- You want to avoid wasting time on low-impact tasks
+- You want a single clear direction instead of a long task list
+
+## Workflow Steps
+
+### Step 1: Verify State Exists
+
+Check if `.sherpa/project-state.md` exists. If not, recommend INIT first and stop.
+
+### Step 2: Read Project State
+
+Read `.sherpa/project-state.md` and capture:
+- Phase
+- Time remaining (from deadline)
+- Completed work, current work, blocked work
+- Risks, known weaknesses
+- Current estimated score, potential score
+- Largest gaps
+- Judging criteria and weights
+
+### Step 3: Inspect Repository for Evidence
+
+Inspect the repository to verify the current state of implementation. Look for broken features, missing tests, missing deployment config, etc.
+
+### Step 4: Apply Time-Aware Filtering
+
+Filter candidate actions based on time remaining:
+
+| Time Remaining | Allow | Block |
+|----------------|-------|-------|
+| > 24 hours | Core product, differentiation, architecture, important features, validation | Low-judging-value features |
+| 12–24 hours | Completing MVP, high-impact features, integration, testing | New feature exploration |
+| 6–12 hours | Stability, testing, UX, security, demo reliability, presentation | Architectural changes |
+| 2–6 hours | Bug fixing, demo flow, critical polish, PPT, documentation, deployment reliability | Any new feature development |
+| < 2 hours | Build working, deployment working, demo working, PPT accurate, links working, critical bugs fixed, submission requirements | All feature development |
+
+### Step 5: Apply Red-Team Filtering
+
+For each candidate action, ask:
+- Does this address a known weakness or risk?
+- Would a judge likely penalize us if this is not done?
+- Is this fixing a contradiction between PPT/README/code/demo?
+- Is this addressing the biggest current risk?
+
+### Step 6: Score Candidates
+
+For each remaining candidate, estimate:
+- Expected judging impact (High/Medium/Low)
+- Implementation effort (Small/Medium/Large)
+- Time required
+- Technical risk
+- Demo risk
+- Alignment with judging criteria weights
+
+### Step 7: Select ONE Primary Next Action
+
+Choose the candidate with the highest `judging impact / time / risk` ratio. There must be exactly ONE.
+
+Report:
+
+```
+PRIMARY NEXT ACTION: [action name]
+
+Why this is the highest priority:
+  [explanation based on impact, time, risk, and judging criteria]
+
+What you need to do:
+  [specific, actionable steps]
+
+What completion looks like:
+  [clear definition of done]
+
+Time remaining: [time or UNKNOWN]
+Blocked by: [any blockers or "None"]
+```
+
+Secondary actions may be listed optionally, but must be clearly marked as secondary.
+
+## Validation
+
+After NEXT completes:
+- [ ] Exactly one primary next action is identified
+- [ ] The "why" explains impact, time, risk, and judging criteria alignment
+- [ ] "What you need to do" is specific and actionable
+- [ ] "What completion looks like" is a clear definition of done
+- [ ] Time-aware filtering was applied
+- [ ] Secondary actions (if any) are clearly marked as secondary

package/.agents/skills/sherpa/workflows/postmortem.md

@@ -0,0 +1,76 @@
+# sherpa — POSTMORTEM Workflow
+
+**Lifecycle Phase:** 20 — Post-Mortem Intelligence (final phase)  
+**Purpose:** Preserve evidence-based lessons from the completed hackathon cycle.
+
+## Prerequisites
+
+1. Read `SKILL.md` and `workflows/lifecycle.md`; require exactly 20 phases with Phase 18 Final Audit, Phase 19 Submission, Phase 20 Post-Mortem. Never extend or renumber.
+2. Read `.sherpa/project-state.md`, `.sherpa/submission-plan.md`, and relevant files under `.sherpa/submission/` when present. If these do not establish a completed submission-readiness review, scope the result as `CONDITIONAL — FRAMEWORK VALIDATION ONLY`; do not treat framework test output as project history.
+3. Inspect Phase 19 rules, workflow, and templates alongside the available project records. Preserve prior project artifacts and behavior.
+4. If project state is absent, record that no live project state was inspected. Never write project state into this framework repository.
+
+## Procedure
+
+1. Determine evidence scope: LIVE POST-MORTEM only with sufficient actual project history; otherwise `CONDITIONAL — FRAMEWORK VALIDATION ONLY`.
+2. Inventory available historical artifacts and their provenance. Distinguish framework tests from live project records.
+3. Label every significant statement FACT, INFERENCE, ASSUMPTION, or UNKNOWN. Cite evidence. Never fill history gaps with typical or synthetic events.
+4. Review all 20 phases. For each, record purpose, usage, evidence, value, problems, redundancy, missing capability, contract gap and recommendation; unavailable project effectiveness is UNKNOWN.
+5. Build timeline and plan-vs-actual tables. Missing planned/actual dates, durations and events remain UNKNOWN. Classify time variance only when evidenced.
+6. Review planned/added/removed/deferred/accidental scope. Call scope creep only with evidence.
+7. Review important decisions with contemporaneous context, evidence, options, authority, expected/actual outcome, quality and lesson. Do not infer decision ownership.
+8. Record incidents only when supported by artifacts. Analyze observed outcome separately from cause; include counterevidence, alternatives, confidence and causality status.
+9. Review original risks against observed outcomes. Unknown exposure remains UNKNOWN, not AVOIDED.
+10. Review Phases 11–19 outcomes (testing/security, UX, red team, judge simulation, score optimization, demo, presentation, submission) only against actual records. Keep simulated judging/optimization separate from actual judging results.
+11. Record official result only from official evidence. Otherwise result = UNKNOWN. Do not infer participation/result from framework status.
+12. Identify evidence-backed wins and failures without blame. Extract lessons and reusable assets without modifying prior locked assets.
+13. Evaluate sherpa Phases 1–19, bottlenecks, process debt, contract gaps, and proposed internal improvement backlog. Label its priorities as internal, not judging scores.
+14. Add `postmortem` state only in the actual project's `.sherpa/project-state.md`, with listed fields and UNKNOWN where evidence is absent. Preserve all existing state. Never create project state in this skill repository.
+15. Run evidence-integrity and historical-integrity checks; ensure no prior evidence was edited, no unsupported causality/result/score/judge statement appears, and no Phase 21 exists.
+16. Produce the post-mortem artifact and exactly one `PRIMARY NEXT ACTION`. For framework-only validation this may be archival preservation of this completed cycle.
+
+## Project state extension (actual project repository only)
+
+```yaml
+postmortem:
+  status: UNKNOWN
+  evidence_scope: UNKNOWN
+  outcome: UNKNOWN
+  result: UNKNOWN
+  timeline_status: UNKNOWN
+  decision_review: UNKNOWN
+  incident_count: UNKNOWN
+  risk_outcome_status: UNKNOWN
+  lessons_count: UNKNOWN
+  reusable_assets_count: UNKNOWN
+  process_bottlenecks: UNKNOWN
+  process_debt: UNKNOWN
+  sherpa_effectiveness: UNKNOWN
+  contract_gaps: UNKNOWN
+  improvement_backlog: UNKNOWN
+  human_review: UNKNOWN
+  final_status: UNKNOWN
+  primary_next_action: UNKNOWN
+```
+
+Do not insert these values into the skill repository or overwrite prior state.
+
+## Required report sections
+
+Use `templates/postmortem.md` and include all 35 numbered sections listed there. Keep actual project claims UNKNOWN where evidence is missing. The post-mortem artifact for a real project belongs under that project's `.sherpa/` directory. Contract harnesses report to stdout and do not create repository audit reports.
+
+## Boundaries
+
+Do not modify application source, dependencies, deployments, submissions, repository visibility, prior phase artifacts, or the lifecycle map. Do not implement a Phase 21. Recommendations are recorded for future human-authorized work only.
+
+## Explicit review matrix
+
+For all phase reviews, use this record: Phase; Purpose; Used?; Evidence; Value; Problems; Redundancy; Missing Capability; Contract Gap; Recommendation; Effectiveness. Review Phase 1 Rules, 2 Problem, 3 Ideas, 4 Validation, 5 Research, 6 Idea Selection, 7 MVP, 8 Architecture, 9 Development Plan, 10 Implementation, 11 Testing + Security, 12 UX, 13 Red Team, 14 Judge Simulation, 15 Score Optimization, 16 Demo Preparation, 17 Presentation, 18 Final Audit, and 19 Submission. Framework tests are not evidence of live project effectiveness.
+
+The plan-vs-actual matrix has rows for timeline, scope, architecture, implementation, testing, security, UX, demo, presentation, and submission. Each row captures planned, actual, variance, evidence, reason, and impact. Unavailable values are UNKNOWN.
+
+Record observed outcome separately from possible causes. For every cause include evidence supporting and against it, alternatives, confidence, and causality status. Record the official result only in a separate outcome section with source evidence; otherwise UNKNOWN.
+
+Record explicit human approvals, rejected recommendations, scope and architecture decisions, risk acceptance, and final submission confirmation only when documented. Ownership otherwise UNKNOWN.
+
+Bottleneck categories are TOOLING, PROCESS, KNOWLEDGE, TIME, DEPENDENCY, HUMAN_DECISION, COMMUNICATION, UNKNOWN. Reusable assets must include asset, location, purpose, quality, reuse recommendation, and required changes. Internal improvement priority is not official hackathon scoring.