haiku-method 2.2.0

package/studios/gamedev/stages/prototype/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit build artifact for the prototype stage of gamedev. Units here are prototype slice — discrete pieces of work with executable acceptance criteria. Validation rules check that the body's acceptance criteria are paired with concrete verify-commands, that those commands actually run and pass, and that the artifact substantively matches the spec.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Body matches the spec it claims to satisfy
+The unit body MUST substantively address every acceptance criterion declared in the unit's spec section. Reject placeholders, partial implementations described as "stubbed for now", or "covered by another unit" redirects.
+
+### 2. Acceptance criteria paired with verify-commands
+Every acceptance criterion in the body MUST be paired with a concrete shell command (or test invocation) that returns a clear pass/fail signal. Vague criteria ("works correctly", "tests pass") are a reject. Map verify-commands to the project's actual stack — read `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` to know which test runner / coverage tool / linter the project uses.
+
+### 3. Verify-commands actually pass
+Run the named verify-commands. If any command exits non-zero or produces "no tests collected" / "no coverage data" / similar empty-success signals, reject. Cite the failing command and its exit code in the rejection reason.
+
+### 4. Decision-register consistency
+The unit must not introduce an approach contradicting a recorded Decision (e.g., a sync API when Decision N chose async). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Build-stage open questions block downstream consumers — be strict.

package/studios/gamedev/stages/prototype/outputs/PROTOTYPE.md

@@ -0,0 +1,27 @@
+---
+name: prototype
+location: (project source tree / build artifact)
+scope: repo
+format: artifact
+required: true
+---
+
+# Prototype
+
+A playable build that validates whether the core loop is fun. Disposable by design — do not expect prototype code to survive into production.
+
+## Content Guide
+
+- **Playable build** — installable and runnable without the dev team present
+- **Playtest notes** — accumulated across sessions, linked from this artifact
+- **Fun verdict** — explicit pass/fail on whether the loop landed
+
+## Completion
+
+Complete when a prototype build is playable end-to-end by a new player and playtest data supports a confident "fun / not fun" verdict.
+
+## Quality Signals
+
+- Multiple playtest sessions with non-team players
+- Fun verdict is supported by specific observations, not vibes
+- The prototype exists in a state where another player can install and play it

package/studios/gamedev/stages/prototype/review-agents/fun-validation.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the prototype actually validated whether the core loop is fun, not whether it "runs" or "has features."
+
+**Check:**
+- The agent **MUST** verify playtests were conducted with non-team players
+- The agent **MUST** verify the fun verdict is supported by specific player observations, not team opinion
+- The agent **MUST** flag any "it'll be fun once we add X" reasoning — the prototype either validated fun or it didn't
+- The agent **MUST** verify negative feedback was engaged with, not dismissed

package/studios/gamedev/stages/prototype/review-agents/loop-integrity.md

@@ -0,0 +1,9 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the prototype actually exercises the core loop as defined in the concept doc, not a simpler or different loop.
+
+**Check:**
+- The agent **MUST** verify the prototype includes every element of the core loop from concept
+- The agent **MUST** verify playtesters experienced the full loop, not a subset
+- The agent **MUST** flag any prototype that cut corners on the loop itself to ship faster

package/studios/gamedev/stages/release/STAGE.md

@@ -0,0 +1,23 @@
+---
+name: release
+description: Storefront submission, platform certification, and patch pipeline
+hats: [release-engineer, platform-cert-specialist, verifier]
+fix_hats: [release-engineer, feedback-assessor]
+review: await
+elaboration: autonomous
+inputs:
+  - stage: polish
+    output: game-build
+---
+
+# Release
+
+Submit to storefronts (Steam, console platforms, mobile stores), pass platform
+certification, and stand up the post-launch patch pipeline. Platform-specific
+requirements vary wildly — console cert is a hard gate that can fail for
+reasons unrelated to the game's quality, mobile stores have their own review
+cycles, and Steam has its own submission cadence.
+
+The patch pipeline matters as much as the initial submission. Games ship
+with bugs; the ability to ship a hotfix within days is what separates a
+launch disaster from a launch hiccup.

package/studios/gamedev/stages/release/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/gamedev/stages/release/hats/platform-cert-specialist.md

@@ -0,0 +1,6 @@
+**Focus:** Navigate platform certification requirements for each target platform. Every platform has its own TRC/XR/lotcheck requirements and rejection reasons — the cert specialist knows them and preps the build to pass.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** pre-verify against every platform requirement before submission
+- The agent **MUST NOT** assume cert requirements are stable across platform SDK versions
+- The agent **MUST** track submission status and respond to cert feedback within platform timelines

package/studios/gamedev/stages/release/hats/release-engineer.md

@@ -0,0 +1,6 @@
+**Focus:** Build, package, and submit the game to target storefronts and platform holders. Manage the submission pipeline, handle rejections, ship patches, and own the post-launch hotfix loop.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** submit without verifying platform-specific requirements (icons, metadata, age ratings, accessibility)
+- The agent **MUST** have a patch pipeline ready before launch day
+- The agent **MUST NOT** ship an unsigned or improperly packaged build

package/studios/gamedev/stages/release/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the release stage of gamedev. Units here are release step — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/gamedev/stages/release/outputs/RELEASE.md

@@ -0,0 +1,25 @@
+---
+name: release
+location: (storefronts + patch pipeline)
+scope: external
+format: artifact
+required: true
+---
+
+# Release
+
+The shipped state of the game across all target storefronts, with an operational patch pipeline. This is not a document in the intent directory; it is the state of the outside world after release.
+
+## Content Guide
+
+A release is complete when:
+- **Every target platform** has an approved, live submission
+- **Storefront assets** (screenshots, trailers, descriptions, age ratings) are complete and accurate
+- **Patch pipeline** is operational and tested end-to-end
+- **Launch day comms** are prepared (release notes, community announcement)
+
+## Quality Signals
+
+- All platforms passed cert on first or acceptable retry count
+- The first post-launch hotfix can be shipped within 48 hours if needed
+- Storefront assets accurately represent the shipped game

package/studios/gamedev/stages/release/phases/ELABORATION.md

@@ -0,0 +1,46 @@
+# Release Stage — Elaboration
+
+Release is an **operational** stage. Its units are operational steps in the storefront-submission and certification pipeline — discrete actions with preconditions, an action procedure, and post-condition checks.
+
+## What a unit IS in this stage
+
+One operational step. Examples:
+
+- "Steam build upload — depots, branches, partner site config"
+- "Sony / Nintendo / Microsoft cert submission package — TRC checklist, build artifact, metadata"
+- "App Store / Play Store submission — privacy nutrition label, screenshots, release notes"
+- "Day-1 patch pipeline — branch protection, build automation, hotfix promotion path"
+- "Storefront launch-day metadata go-live — pricing, tags, release-date flip"
+- "Post-launch monitoring — crash report ingestion, review-feed alerts"
+
+What a unit is **NOT** in this stage:
+
+- ❌ A gameplay polish task (those belong in `polish`)
+- ❌ A feature or content addition (those belong in `production`)
+- ❌ A market positioning decision (that belongs in `concept` / inception-class research)
+
+## What "completion criteria" means here
+
+Operational-step criteria specify **preconditions, action, post-condition check, and rollback** — not vague "we did the thing" claims. Pass/fail must be decidable from a recorded artifact.
+
+### Good criteria — concrete and verifiable
+
+- "Steam upload preconditions: build is signed, depots A/B/C exist, branch `default` is locked. Action: `steamcmd +run_app_build_http <vdf>`. Post-condition: SteamDB shows new build_id within 10 minutes of upload"
+- "Cert submission post-condition: portal returns submission ID and confirmation email is filed in `release/cert-submissions/`"
+- "Patch pipeline post-condition: a synthetic hotfix PR can merge, build, and produce a `.patch` artifact in <30 minutes — recorded as a dry-run on a release branch"
+
+### Bad criteria — vague or wrong-stage
+
+- ❌ "Released to Steam" (no check, no evidence)
+- ❌ "Cert passed" (which cert? which build? recorded where?)
+- ❌ "Game is fun" — wrong stage; that's `concept`/`prototype`/`polish`
+
+## How verification happens
+
+Release artifacts are validated by the verifier hat (`hats/verifier.md`). The verifier checks **preconditions stated, action unambiguous, post-condition mechanically decidable, rollback declared where applicable** — body-content checks only, no frontmatter interpretation.
+
+## Anti-patterns
+
+- **Skipping rollback for non-idempotent actions.** A storefront submission you can't unsubmit needs an explicit "no rollback — forward-fix only via patch" statement, not silence.
+- **Vague post-conditions.** "Verify build is live" is not a check; "SteamDB shows build_id matching local build manifest within 10 minutes" is.
+- **Treating cert as binary.** Cert can fail for non-game reasons (TRC interpretation, account access, build-pipeline issues); each cert step should have a unit, not be lumped under "submit and wait".

package/studios/gamedev/stages/release/review-agents/cert-readiness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the build meets every platform certification requirement before submission. Failed cert wastes days or weeks of the launch window.
+
+**Check:**
+- The agent **MUST** verify every line item on each platform's TRC/XR/lotcheck checklist
+- The agent **MUST** verify required metadata (age ratings, content descriptors, accessibility) is complete
+- The agent **MUST** verify required icons, loading screens, and platform-specific UI are present
+- The agent **MUST** flag any platform-specific feature that was skipped (e.g., achievements on Xbox, trophies on PlayStation)

package/studios/gamedev/stages/release/review-agents/patch-pipeline.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the post-launch patch pipeline is operational before release, not after.
+
+**Check:**
+- The agent **MUST** verify a patch build can be produced, signed, and submitted end-to-end
+- The agent **MUST** verify submission turnaround time is understood for each platform
+- The agent **MUST** verify a live-ops rollback procedure exists for emergencies
+- The agent **MUST** flag any platform where the patch process has never been exercised

package/studios/hr/STUDIO.md

@@ -0,0 +1,11 @@
+---
+name: hr
+description: Human resources lifecycle for hiring, onboarding, and talent management
+stages: [requisition, sourcing, screening, interview, offer]
+category: back-office
+default_model: sonnet
+---
+
+# HR Studio
+
+Human resources hiring lifecycle from role definition through offer. Covers requisition creation, candidate sourcing, screening, structured interviews, and offer management. Works for individual contributor roles, leadership positions, and high-volume hiring.

package/studios/hr/examples/senior-backend-hire/intent.md

@@ -0,0 +1,17 @@
+---
+title: senior-backend-hire
+studio: hr
+stages: [requisition, sourcing, screening, interview, offer]
+status: complete
+---
+
+# Senior Backend Engineer — Platform Team
+
+Hire a senior backend engineer for the platform team to lead the event bus rewrite. Must-have signal is distributed systems experience. Remote US; senior comp band with equity-heavy mix.
+
+## Goals
+
+- Source candidates with demonstrable distributed-systems track record
+- 30-minute technical screen focused on event delivery guarantees and partitioning
+- On-site loop: systems design (event bus), code review, team collab, leadership chat
+- Offer signed within 60 days of requisition open

package/studios/hr/examples/senior-backend-hire/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - executive-strategy
+  - finance
+  - training
+turns:
+  - role: user
+    text: "Hire a senior backend engineer for the platform team."
+  - role: agent
+    text: "What's the must-have technical signal — distributed systems, databases, infra?"
+  - role: user
+    text: "Distributed systems. We're rewriting the event bus."
+  - role: agent
+    text: "Comp band and location flexibility?"
+  - role: user
+    text: "Senior band, equity heavy. Remote US."
+  - role: agent
+    text: "Got it — sourcing against distributed-systems senior, remote US, senior comp band."

package/studios/hr/fix-hats/reconciler.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+---
+**Focus:** Reconcile cross-stage artifacts against studio-wide standards. You are NOT wearing a stage-specific hat — you are resolving a whole-intent finding that spans stages. Your mandate is alignment, not fresh authoring.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** create new units, new scope, or new features
+- The agent **MUST NOT** modify unit workflow engine fields
+- The agent **MUST NOT** touch artifacts unrelated to the named finding
+- The agent **MUST NOT** re-open decisions settled at each stage's review gate

package/studios/hr/fix-hats/validator.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that the reconciler's fix resolves the intent-scope feedback. You are the terminal hat — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you verify, you do not fix
+- The agent **MUST NOT** close a finding that isn't actually resolved
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — either close, leave open, or reject as genuinely invalid

package/studios/hr/review-agents/cross-stage-consistency.md

@@ -0,0 +1,17 @@
+---
+scope: intent
+interpretation: lens
+---
+**Mandate:** Verify the intent's artifacts are internally consistent across stages. You are the only reviewer that sees the whole intent at once — your job is to catch seams that per-stage reviewers miss.
+
+**Check:**
+- The agent **MUST** verify that each stage's outputs align with what upstream stages specified — no dropped requirements, no silent scope expansion
+- The agent **MUST** verify that naming is consistent across stages — a concept named one thing upstream should carry the same name downstream
+- The agent **MUST** verify that stages' declared outputs exist at the paths their unit frontmatter promised
+- The agent **MUST** verify that the stages collectively deliver the intent's stated goal (read `intent.md`) — partial delivery is a finding
+- The agent **MUST** verify that concerns raised by any stage's review were actually addressed (not silently ignored)
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** re-litigate decisions already approved at each stage's gate
+- The agent **MUST NOT** propose new features or scope additions
+- The agent **MUST NOT** flag stylistic preferences — concrete divergence only

package/studios/hr/stages/interview/STAGE.md

@@ -0,0 +1,17 @@
+---
+name: interview
+description: Conduct structured interviews and evaluate candidates
+hats: [interviewer, evaluator, verifier]
+fix_hats: [interviewer, feedback-assessor]
+review: ask
+elaboration: collaborative
+inputs:
+  - stage: screening
+    discovery: screening-report
+  - stage: requisition
+    discovery: job-spec
+---
+
+# Interview
+
+Conduct structured interviews and evaluate candidates.

package/studios/hr/stages/interview/discovery/INTERVIEW-SCORECARD.md

@@ -0,0 +1,28 @@
+---
+name: interview-scorecard
+location: .haiku/intents/{intent-slug}/knowledge/INTERVIEW-SCORECARD.md
+scope: intent
+format: text
+required: true
+---
+
+# Interview Scorecard
+
+Structured interview assessments with behavioral evidence and comparative candidate ranking.
+
+## Content Guide
+
+Structure the scorecard for evidence-based hiring decisions:
+
+- **Competency dimensions** -- the competencies assessed with behavioral anchors for each level
+- **Individual assessments** -- each interviewer's scores with specific behavioral evidence cited
+- **Consensus summary** -- areas of agreement and disagreement across interviewers with resolution
+- **Comparative ranking** -- candidates ranked with rationale for positioning
+- **Hire recommendations** -- clear hire/no-hire recommendation for each candidate with supporting evidence
+
+## Quality Signals
+
+- Every score is supported by specific behavioral evidence from the interview
+- Scoring disagreements are resolved through evidence review, not seniority
+- Recommendations are based on competency data, not likability
+- The comparative ranking enables a clear decision on which candidate to advance

package/studios/hr/stages/interview/hats/evaluator.md

@@ -0,0 +1,13 @@
+**Focus:** Synthesize interview feedback across all interviewers and produce a comparative candidate assessment with hire recommendations.
+
+**Responsibilities:**
+- Aggregate interviewer scores and identify areas of consensus and divergence
+- Facilitate debrief discussions that resolve scoring discrepancies with evidence
+- Produce a comparative ranking with supporting behavioral evidence
+- Document hire/no-hire recommendations with clear rationale
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** averag scores without examining disagreements between interviewers
+- The agent **MUST NOT** let a single strong opinion dominate the debrief without evidence review
+- The agent **MUST NOT** make recommendations based on likability rather than competency evidence
+- The agent **MUST** document the rationale clearly enough for future reference

package/studios/hr/stages/interview/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/hr/stages/interview/hats/interviewer.md

@@ -0,0 +1,13 @@
+**Focus:** Conduct structured interviews that elicit behavioral evidence of candidate competencies.
+
+**Responsibilities:**
+- Prepare interview questions aligned to the competency dimensions in the job spec
+- Conduct interviews using structured methodology (behavioral, situational, or technical)
+- Document specific examples from candidate responses, not just impression ratings
+- Assess candidates against the rubric independently before debrief
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** ask different questions to different candidates for the same role
+- The agent **MUST NOT** rate candidates on overall impression without documenting specific evidence
+- The agent **MUST NOT** allow conversation to drift away from competency assessment
+- The agent **MUST NOT** shar opinions with other interviewers before independent scoring

package/studios/hr/stages/interview/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the interview stage of hr. Units here are interview record — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/hr/stages/interview/outputs/INTERVIEW-SCORECARD.md

@@ -0,0 +1,25 @@
+---
+name: interview-scorecard
+location: .haiku/intents/{intent-slug}/stages/interview/artifacts/
+scope: intent
+format: text
+required: true
+---
+
+# Interview Scorecard
+
+Structured interview evaluations with competency ratings and hire recommendation.
+
+## Expected Artifacts
+
+- **Scorecard** -- structured rubric with behavioral anchors for each competency dimension
+- **Interviewer assessments** -- specific examples from candidate responses, not just ratings
+- **Debrief summary** -- synthesized perspectives with clear hire/no-hire recommendation
+- **Competency ratings** -- each dimension rated with supporting evidence
+
+## Quality Signals
+
+- Scorecard uses a structured rubric with behavioral anchors
+- Each assessment includes specific examples from the candidate's responses
+- Debrief synthesizes all interviewer perspectives into a clear recommendation
+- Recommendation is backed by evidence, not subjective impressions

package/studios/hr/stages/interview/phases/ELABORATION.md

@@ -0,0 +1,16 @@
+# Interview Stage — Elaboration
+
+## Criteria Guidance
+
+### Good criteria — concrete and verifiable
+
+- "Interview scorecard uses a structured rubric with behavioral anchors for each competency dimension"
+- "Each interviewer's assessment includes specific examples from the candidate's responses, not just ratings"
+- "Debrief summary synthesizes all interviewer perspectives with a clear hire/no-hire recommendation and rationale"
+
+### Bad criteria — vague (no clear check)
+
+- "Interviews are completed"
+- "Candidates are evaluated"
+- "Scorecard is filled out"
+

package/studios/hr/stages/interview/review-agents/fairness.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify interview process is structured, evidence-based, and free from bias.
+
+**Check:**
+- The agent **MUST** verify that all candidates received comparable interview experiences
+- The agent **MUST** verify that assessments cite specific behavioral evidence, not impressions
+- The agent **MUST** verify that scoring disagreements between interviewers are resolved through evidence review
+- The agent **MUST** verify that hire recommendations are supported by competency data, not likability

package/studios/hr/stages/offer/STAGE.md

@@ -0,0 +1,17 @@
+---
+name: offer
+description: Develop compensation package and extend offer
+hats: [compensator, closer, verifier]
+fix_hats: [compensator, feedback-assessor]
+review: external
+elaboration: collaborative
+inputs:
+  - stage: interview
+    discovery: interview-scorecard
+  - stage: requisition
+    discovery: job-spec
+---
+
+# Offer
+
+Develop compensation package and extend offer.

package/studios/hr/stages/offer/hats/closer.md

@@ -0,0 +1,13 @@
+**Focus:** Manage the offer process from preparation through candidate acceptance, including negotiation and contingency planning.
+
+**Responsibilities:**
+- Prepare complete offer documentation with all material terms
+- Manage the approval workflow through all required approvers
+- Handle candidate negotiations within approved parameters
+- Maintain a contingency plan with fallback candidates and timeline
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** extend offers without completing all approval workflows
+- The agent **MUST NOT** make verbal commitments that differ from the written offer
+- The agent **MUST** have a contingency plan if the primary candidate declines
+- The agent **MUST NOT** allow the offer process to stall without proactive candidate communication

package/studios/hr/stages/offer/hats/compensator.md

@@ -0,0 +1,13 @@
+**Focus:** Develop compensation packages that are competitive, equitable, and aligned with internal compensation structures.
+
+**Responsibilities:**
+- Benchmark compensation against external market data and internal equity bands
+- Structure the total compensation package (base, bonus, equity, benefits)
+- Document the rationale for positioning within the compensation range
+- Identify and flag any equity concerns with existing team compensation
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** set compensation without market data or internal equity analysis
+- The agent **MUST NOT** offer at the top of range without considering long-term equity implications
+- The agent **MUST NOT** ignore total compensation (benefits, equity, perks) when comparing to market
+- The agent **MUST** document the rationale for compensation decisions

package/studios/hr/stages/offer/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/hr/stages/offer/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the offer stage of hr. Units here are offer package — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.