@pieerry/harness-kit 3.0.0

package/.claude/plugins/product-manager/sensors/prd-structure.md

@@ -0,0 +1,39 @@
+# Sensor: PRD Structure
+
+Type: deterministic
+Mode: hard gate
+
+## Required sections (all must be present, in order)
+
+- Problem and Hypothesis
+- Customers
+- Scope and Non-Goals
+- Solution Overview
+- Success Metrics
+- Rollout
+- Risks
+- Owners and Open Questions
+
+## Forbidden sections
+
+- Implementation Details
+- Code
+- API Schema
+
+## Forbidden tokens
+
+- lorem
+- TODO
+- FIXME
+- xxx
+- placeholder
+
+## Markdown rules
+
+- exactly 1 H1 heading
+- no em-dash
+- no ASCII box-drawing
+
+## On failure
+
+Block publish. Return list of missing sections, forbidden tokens, rule violations. Agent regenerates only failed parts.

package/.claude/plugins/product-manager/sensors/prp-context-quality.md

@@ -0,0 +1,42 @@
+# Sensor: PRP Context Quality
+
+Type: deterministic plus heuristic
+Mode: hard gate
+
+A PRP must give an executor enough context to ship without coming back to ask.
+
+## Required sections
+
+- Context
+- Implementation blueprint
+- What
+
+## Checks within Context
+
+File paths referenced. Repos and files touched table must reference at least 2 real file paths. A file path has `/` and a known extension (java, kt, ts, tsx, js, jsx, vue, py, sql, yaml, yml, md, sh, gradle).
+
+Patterns with concrete examples. Patterns to follow must have at least 1 pattern. Each pattern must include an `Example in codebase:` line pointing to a concrete path.
+
+Known gotchas. Subsection `### Known gotchas` must exist with at least 1 bullet.
+
+External documentation. Subsection `### External documentation` must exist. Either URLs or explicit "none".
+
+## Checks within Implementation blueprint
+
+Numbered steps in a fenced code block.
+
+At least 1 numbered step references a class, file, or command (uppercase or path-shaped token).
+
+## Checks within What
+
+Success criteria must include at least 1 line matching:
+- Given / When / Then pattern, or
+- measurable comparison (less than, greater than, <, >, =, drops to, stays below)
+
+## Open gaps budget
+
+Count of `NEEDS REVIEW`, `NOT FOUND`, or `TBD` markers must be 5 or fewer.
+
+## On failure
+
+Block publish. Return specific feedback (missing paths, missing examples, etc). Agent regenerates failed parts only.

package/.claude/plugins/product-manager/sensors/prp-links.md

@@ -0,0 +1,24 @@
+# Sensor: PRP Links
+
+Type: deterministic
+Mode: warn-then-gate
+
+Implemented in scripts/link-validator.py. Same rules when agent self-checks.
+
+## Hard checks (block)
+
+Source PRD resolvable. The "Source PRD:" line must point to a path that exists under outputs/prd/, relative to the PRP file, or relative to the repo root.
+
+No localhost URLs. `http://localhost` or `http://127.0.0.1` not allowed as pinned references.
+
+GitHub permalinks. Links like `github.com/.../blob/{main|master|develop}/...` not allowed. Use commit SHA or tag.
+
+## Soft checks (warn)
+
+Path format. Inline code spans that look like file paths (have `/` and end with extension) should end in a recognized extension.
+
+URL syntax. http/https URLs must be syntactically valid.
+
+## On failure
+
+Hard-check failures block publish. Soft-check warnings surface for review but do not block.

package/.claude/plugins/product-manager/sensors/prp-structure.md

@@ -0,0 +1,52 @@
+# Sensor: PRP Structure
+
+Type: deterministic
+Mode: hard gate
+
+## Required sections (all must be present, in order)
+
+- Goal
+- Why
+- What
+- Context
+- Implementation blueprint
+- Validation gates
+- Rollout
+- Open items
+- References
+
+## Forbidden tokens
+
+- lorem
+- FIXME
+- xxx
+- placeholder
+
+## Markdown rules
+
+- exactly 1 H1 heading
+- no em-dash
+- no ASCII box-drawing
+
+## Required metadata
+
+Document header must declare:
+- Source PRD
+- Target executor
+- Squad
+- Tech lead
+- Date
+
+## Validation gates block
+
+Validation gates section must include at least one fenced bash or sh code block.
+
+## Sub-sections in Context
+
+Context must contain:
+- `### Repos and files touched`
+- `### Patterns to follow`
+
+## On failure
+
+Block publish. Return missing sections, missing metadata, missing fenced code blocks. Agent regenerates failed parts only.

package/.claude/plugins/product-manager/skills/prd/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: prd
+description: Generate a Product Requirements Document for an team squad. Business-facing artifact. Sensors and evals gate.
+user_invocable: true
+---
+
+Generate a PRD. Follow guides/pipeline.md for retry, approval, and publish.
+
+Ask once if missing: squad, problem in 1-2 sentences, customers, hypothesis, bet link, stage.
+
+Compute feature_id = {YYYY-MM-DD}-{squad}-{slug}. Before generating, write the phase start marker:
+
+```
+outputs/.markers/{feature_id}.prd-generate.start
+```
+
+Content: `{"timestamp": "<ISO-8601 UTC now>", "session_id": ""}`
+
+Read:
+- guides/product-guidelines.md
+- guides/prd-guidelines.md
+- guides/writing-style.md
+- guides/templates/prd.md
+- guides/pipeline.md
+- guides/examples/good-prd-example.md
+
+Save to outputs/prd/{feature_id}.md.
+
+Sensors: sensors/prd-structure.md, sensors/prd-acceptance-criteria.md.
+
+Evals: evals/prd-quality.md, evals/prd-readiness.md.
+
+After save reply: PRD saved at {path}. Score: {N}/10.

package/.claude/plugins/product-manager/skills/prp/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: prp
+description: Generate a Product Requirements Prompt for engineering handoff. Needs an approved PRD. Sensors, link validation, and eval gates.
+user_invocable: true
+---
+
+Generate a PRP. Follow guides/pipeline.md for retry, approval, and publish.
+
+Source PRD: if user passes a path, use it. Else pick the most recent in outputs/prd/. None found, abort. Tell user to run /product-manager:prd first. hooks/pre-prp-check.sh blocks if the PRD lacks the approved marker.
+
+Compute feature_id from the source PRD filename (basename without .md). Save the PRP to outputs/prp/{feature_id}.md so it matches.
+
+Before generating, write the phase start marker:
+
+```
+outputs/.markers/{feature_id}.prp-generate.start
+```
+
+Content: `{"timestamp": "<ISO-8601 UTC now>", "session_id": ""}`
+
+Read:
+- the source PRD
+- guides/prp-guidelines.md
+- guides/writing-style.md
+- guides/templates/prp.md
+- guides/pipeline.md
+- guides/examples/good-prp-example.md
+
+Explore target repos. Ask user for repo paths if not provided. Use Grep and Read to map files. Capture file:line. Never invent paths.
+
+Save to outputs/prp/{feature_id}.md.
+
+Sensors: sensors/prp-structure.md, sensors/prp-context-quality.md, sensors/prp-links.md.
+
+Evals: evals/prp-quality.md, evals/prp-context-readiness.md.
+
+After save reply: PRP saved at {path}. Score: {N}/10. Ready for handoff.

package/.claude/plugins/staff-software-engineer/README.md

@@ -0,0 +1,90 @@
+# Staff Software Engineer Plugin
+
+Native Claude Code plugin for the engineering team. Drives plan, dev, test, and pr stages across backend, web, mobile, and devops. Per-project conventions in each repo's `.claude/conventions/` override plugin defaults.
+
+## Slash commands
+
+- `/sse:plan`: generate an implementation plan from an approved PRP
+- `/sse:dev`: implement the plan in code, run convention gates
+- `/sse:test`: run the project test suite
+- `/sse:pr`: open the draft PR
+- `/sse:run`: full pipeline, plan to pr
+
+Also invokable as sub-agent via Task tool with `subagent_type: "staff-software-engineer"`.
+
+## Tree
+
+```
+.claude/plugins/staff-software-engineer/
+├── .claude-plugin/plugin.json
+├── agents/staff-software-engineer.md sub-agent
+├── commands/
+│ ├── plan.md /sse:plan
+│ ├── dev.md /sse:dev
+│ ├── test.md /sse:test
+│ ├── pr.md /sse:pr
+│ └── run.md /sse:run
+├── skills/
+│ ├── backend/SKILL.md Java/Spring defaults
+│ ├── web/SKILL.md Vue defaults
+│ ├── mobile/SKILL.md iOS/Android defaults
+│ └── devops/SKILL.md CI/IaC defaults
+├── hooks/ phase markers, sensor gates
+├── scripts/ symlinks to product-manager scripts
+├── guides/
+│ ├── pipeline.md retry, approval, token accounting
+│ ├── coding-style.md team code style
+│ ├── commit-style.md Conventional Commits with TICKET
+│ └── conventions-override.md how project overrides work
+├── sensors/ plan structure, code conventions, test coverage
+├── evals/ plan quality rubric
+└── outputs/
+ ├── plan/ generated plans
+ ├── dev/ dev summaries
+ ├── test/ test results
+ ├── pr/ opened PR records
+ ├── tokens/ per-feature phase tokens JSON
+ └── .markers/ phase start/end markers (transient)
+```
+
+## How conventions work
+
+The plugin holds team defaults per area. Each project repo can override by adding:
+
+```
+{repo-root}/.claude/conventions/{area}.md
+```
+
+Example for the `recon-service` repo:
+
+```
+recon-service/.claude/conventions/backend.md
+```
+
+Plugin skills read both. Project rules win. See `guides/conventions-override.md`.
+
+## Where to edit
+
+| Change | File |
+|--------|------|
+| Pipeline order | guides/pipeline.md |
+| Retry count | guides/pipeline.md (Max attempts) |
+| Plan template/rules | skills/backend/SKILL.md (etc per area), commands/plan.md |
+| Eval threshold | evals/plan-quality.md (Threshold) |
+| Code style | guides/coding-style.md |
+| Commit format | guides/commit-style.md |
+| Test command detection | commands/test.md |
+| PR template | commands/pr.md, hooks/post-eval-pr.sh |
+| Sensors | sensors/*.md |
+
+## Connects to PM plugin
+
+`/sse:run` reads the latest approved PRP from `.claude/plugins/product-manager/outputs/prp/`. The feature_id flows through: PM plugin creates `2026-05-12-billing-tz-fix`, SSE plugin reuses the same id and writes its phases to the same `outputs/tokens/{feature_id}.json` file (per `guides/pipeline.md`).
+
+Full lifecycle in one JSON: PRD generate, PRD validate, PRP generate, PRP validate, plan generate, plan validate, dev, test, pr.
+
+## Setup
+
+Hooks registered in `.claude/settings.json` under PostToolUse. Token script reused from the PM plugin via symlinks in `scripts/`.
+
+PR opening requires the `gh` CLI authenticated. `pr.md` command details ticket detection and template.

package/.claude/plugins/staff-software-engineer/evals/plan-quality.md

@@ -0,0 +1,48 @@
+# Eval: Plan Quality
+
+Type: LLM-judge
+Mode: quality gate
+Threshold: weighted total >= 8.0
+
+Score each dimension 0-10. Cite line numbers when below 7. Weighted total = sum(score x weight%) / 100.
+
+## Rubric
+
+### Scope clarity (weight 20%)
+Is what is being built clear? Tied to the source PRP?
+
+### Files touched specificity (weight 20%)
+Are the files and modules concrete? Real paths, not placeholders?
+
+### Execution flow (weight 20%)
+Are the steps actionable in order? Could a fresh engineer follow them?
+
+### Risk awareness (weight 15%)
+Are real risks called out with mitigations?
+
+### Rollout (weight 15%)
+Is there a phased plan or feature flag strategy?
+
+### Tests (weight 10%)
+Does the plan name the test cases to cover?
+
+## On failure (total below 8.0)
+
+Retry. Regenerate weakest section only. Max 3 attempts.
+
+## Output
+
+```json
+{
+  "scores": {
+    "scope_clarity": 0,
+    "files_touched": 0,
+    "execution_flow": 0,
+    "risk_awareness": 0,
+    "rollout": 0,
+    "tests": 0
+  },
+  "weighted_total": 0.0,
+  "feedback": ["dimension: specific issue with line ref"]
+}
+```

package/.claude/plugins/staff-software-engineer/guides/coding-style.md

@@ -0,0 +1,51 @@
+# Coding Style
+
+How code reads . Applies to all areas unless a `{repo}/.claude/conventions/{area}.md` says otherwise.
+
+## Principles
+
+- Read before write. At least 3 similar files in the repo before producing new code.
+- Match repo conventions. Do not mix stacks (no JPA in repos using AbstractRepository, no Composition API in Vue 2 repos).
+- Pragmatic over perfect. Small PRs, 1-4 files, under 100 lines ideal.
+- Test service logic always. Feature or bugfix without tests is incomplete.
+- Clean dead code when touching related files. Do not leave commented-out blocks.
+- Temp code marked: `// please remove me` so reviewers catch it.
+- Revert if issues, investigate second.
+- Defensive: null-safe, guards, edge cases.
+- No speculative abstraction. Three similar lines beats premature DRY.
+
+## Never invent
+
+If a class, helper, or pattern is not in the repo, do not fabricate it.
+
+Java/Kotlin:
+```java
+// TBD - verify with tech lead: {what you searched, where, what is missing}
+```
+
+Vue:
+```vue
+<!-- TBD - verify with tech lead: {what is missing} -->
+```
+
+A TODO with context beats fabricated code.
+
+## Backend defaults (Java/Kotlin/team)
+
+See skills/backend/SKILL.md.
+
+## Web defaults (Vue/team)
+
+See skills/web/SKILL.md.
+
+## Mobile defaults
+
+See skills/mobile/SKILL.md.
+
+## DevOps defaults
+
+See skills/devops/SKILL.md.
+
+## Project overrides
+
+A repo can override any rule via `.claude/conventions/{area}.md`. See guides/conventions-override.md.

package/.claude/plugins/staff-software-engineer/guides/commit-style.md

@@ -0,0 +1,44 @@
+# Commit Style
+
+Conventional Commits with team ticket prefix.
+
+## Format
+
+```
+{type}({TICKET}): {description} (#PR)
+```
+
+Types: feat, fix, chore, refactor, build, docs, test.
+
+Examples:
+- `feat(PROJ-123): adding timezone-aware deadline check (#456)`
+- `fix(PROJ-42): correcting late flag for region-1 customers`
+- `chore(PROJ-7): updating Spring Boot to 2.7`
+- `refactor(PROJ-91): extracting DeadlineEvaluator from OrderService`
+
+## Description
+
+- Imperative/gerund mood. "Adding", "Removing", "Enhancing", "Fixing".
+- Single line. Under 70 characters.
+- PR number when available.
+
+## Body (optional)
+
+- Why, not what. Diff already shows what.
+- Reference linked tickets or related PRs.
+- Mention breaking changes explicitly with `BREAKING CHANGE:` footer.
+
+## Bad
+
+- "WIP", "fixes", "more changes", "asdf"
+- Ticket missing
+- Description that just repeats the type ("fix(...): fix the bug")
+- Multi-line title
+
+## Co-author
+
+When pairing or AI-assisted:
+
+```
+Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
+```

package/.claude/plugins/staff-software-engineer/guides/conventions-override.md

@@ -0,0 +1,79 @@
+# Conventions Override
+
+How project-specific conventions override the plugin defaults.
+
+## Path
+
+Each repo can have its own conventions file per area:
+
+```
+{repo-root}/
+└── .claude/
+ └── conventions/
+ ├── backend.md
+ ├── web.md
+ ├── mobile.md
+ └── devops.md
+```
+
+Only the files you need. If you do not have web work in this repo, do not create web.md.
+
+## How it works
+
+When a skill or command generates code:
+
+1. Read the plugin's default conventions from `skills/{area}/SKILL.md`.
+2. Check if `cwd/.claude/conventions/{area}.md` exists.
+3. If yes, read it. Rules in this file override or add to the defaults.
+4. If a rule conflicts, project wins.
+5. If no project file, use plugin defaults only.
+
+## What goes in a project conventions file
+
+The DIFFERENCES from defaults, not the full rule set. Examples:
+
+```markdown
+# Backend conventions for recon-service
+
+Stack overrides:
+- Java 17 (not 8 or 11)
+- Spring Boot 3.x (not Spring 4.3 no-Boot)
+- Spring Data JPA repositories (not AbstractRepository)
+- MapStruct for mappers (not Orika)
+- JUnit 5 + Mockito (not JUnit 4)
+- Deploy as container, not WAR
+- Package: br.com.team.recon
+
+Project-specific patterns:
+- All entities in br.com.team.recon.domain
+- Service layer in .service, repositories in .repository
+- Use Records for DTOs
+
+Forbidden in this repo:
+- Lombok (we use Records and explicit constructors)
+- @Component annotation on classes (always @Service, @Repository, @Configuration)
+```
+
+Keep it short. Document what is DIFFERENT, not what is shared with defaults.
+
+## Avoiding drift
+
+If a convention you wrote for the repo also applies to others, consider promoting it to the plugin defaults (skills/{area}/SKILL.md). Per-repo files should hold genuine repo-specific decisions.
+
+## Versioning
+
+Track conventions changes in git. When a rule changes, the commit message and PR description explain why.
+
+## Example structure for recon-service
+
+```
+recon-service/
+├── .claude/
+│ └── conventions/
+│ ├── backend.md
+│ └── devops.md
+├── src/...
+└── pom.xml
+```
+
+Web and mobile files absent because recon-service has no web or mobile work.

package/.claude/plugins/staff-software-engineer/guides/pipeline.md

@@ -0,0 +1,69 @@
+# Pipeline
+
+Shared rules for plan, dev, test, pr stages. Edit retry, approval, publish, and token accounting here.
+
+## Stages
+
+1. plan: generate a technical plan from the source PRP. Apply sensors, eval, retry up to 3.
+2. dev: implement the plan in code. Run lint and convention gates after each step. Retry until clean.
+3. test: run the project test suite. Capture results.
+4. pr: open a draft PR with the standard template.
+
+## Retry policy
+
+Max attempts per stage: 3.
+
+Trigger on:
+- any sensor returns non-zero
+- eval weighted total below threshold (default 8.0 for plan)
+- test command exit code != 0 (dev/test only)
+
+Strategy:
+1. Read the feedback.
+2. Regenerate or fix only the failed parts.
+3. Re-run gates.
+
+Hard stop after 3 attempts: return blocker, do not proceed.
+
+## Approval marker
+
+Each artifact gets:
+```
+<!-- approved: {YYYY-MM-DD} score={N} -->
+```
+
+Plan and PR also accept variants with `ready-for-handoff: true`.
+
+Triggers hooks/post-eval-{stage}.sh.
+
+## Token accounting
+
+Phases tracked per feature_id (matches PRD/PRP feature_id from the PM plugin):
+- plan-generate, plan-validate
+- dev
+- test
+- pr
+
+Markers in outputs/.markers/{feature_id}.{phase}.{start|end}, each `{"timestamp": ISO, "session_id": ""}`. Skills write .start; hooks write .end. After each phase ends, the publish hook calls scripts/token-phase.py.
+
+Tokens land in a shared file with the PM plugin: `outputs/tokens/{feature_id}.json`. The same file collects both PM phases (prd-generate, prd-validate, prp-generate, prp-validate) and SSE phases (plan-generate, plan-validate, dev, test, pr). Totals cover the full feature lifecycle.
+
+To merge with the PM tokens file, the SSE token-phase.py writes to the same path under this plugin's outputs/tokens/, then a small step in commands/run.md syncs (or symlinks) with the PM tokens dir. For simplicity v1, SSE keeps its own outputs/tokens/{feature_id}.json. v2: merge.
+
+## Orchestrator order
+
+1. plan: stages 1-4.
+2. dev: stages 1-4 (with code-conventions gate).
+3. test: runs repo test suite.
+4. pr: opens draft PR.
+
+## Stop conditions
+
+- 3 failed attempts on the same stage
+- tests fail after dev
+- gh CLI not available for pr stage
+- missing required input after one clarification
+
+## Conventions override
+
+Before any code generation, read `guides/conventions-override.md` and check `cwd/.claude/conventions/{area}.md`. Project-specific rules win over plugin defaults.

package/.claude/plugins/staff-software-engineer/hooks/post-eval-plan.sh

@@ -0,0 +1,43 @@
+#!/bin/bash
+# After Edit appends approval marker to plan, close phases, run token accounting.
+
+set -euo pipefail
+
+FILE_PATH="${CLAUDE_TOOL_FILE_PATH:-}"
+PLUGIN_DIR="$(cd "$(dirname "$0")/.." && pwd)"
+
+case "$FILE_PATH" in
+  *.claude/plugins/staff-software-engineer/outputs/plan/*.md) ;;
+  *) exit 0 ;;
+esac
+
+if ! grep -q "<!-- approved:" "$FILE_PATH"; then
+  exit 0
+fi
+
+if grep -q "<!-- published:" "$FILE_PATH"; then
+  exit 0
+fi
+
+FEATURE_ID="$(basename "$FILE_PATH" .md)"
+MARKERS_DIR="$PLUGIN_DIR/outputs/.markers"
+mkdir -p "$MARKERS_DIR"
+NOW="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
+
+if [ -f "$MARKERS_DIR/${FEATURE_ID}.plan-validate.start" ]; then
+  printf '{"timestamp":"%s"}\n' "$NOW" > "$MARKERS_DIR/${FEATURE_ID}.plan-validate.end"
+fi
+
+python3 "$PLUGIN_DIR/scripts/token-phase.py" \
+  --feature-id "$FEATURE_ID" \
+  --phase "plan-generate" \
+  --plugin-dir "$PLUGIN_DIR" >&2 || true
+
+python3 "$PLUGIN_DIR/scripts/token-phase.py" \
+  --feature-id "$FEATURE_ID" \
+  --phase "plan-validate" \
+  --plugin-dir "$PLUGIN_DIR" >&2 || true
+
+printf '\n<!-- published: %s -->\n' "$NOW" >> "$FILE_PATH"
+echo "[hook] Plan approved + token accounting done" >&2
+exit 0