witness
Sign, verify, and track fix-marker regressions over time using a deterministic Ed25519 witness manifest. Works in any project — clone the toolkit, run init, register fixes, regen on each release.
What this skill does
# Witness — cryptographic fix-regression tracking
The witness toolkit lets you ship every release with a *signed* manifest
that lists every documented fix in your codebase along with a sha256 +
marker substring. Anyone with the same git commit can re-derive the
public key and verify the signature without a committed private key.
A temporal history (JSONL) tracks how the fix population evolves across
releases — so when a regression appears, you can pinpoint *the commit
that introduced it*, not just "it's broken now."
This skill works two ways:
1. **Inside ruflo** — used by ruflo's own CI to gate publishes (see
`.github/workflows/v3-ci.yml` job `witness-verify`).
2. **In your own project** — copy `plugins/ruflo-core/scripts/witness/`
into your repo, run `init.mjs`, register your fixes in
`witness-fixes.json`, and call `regen.mjs` from your release pipeline.
## Quick start (any project)
```bash
# One-time bootstrap — creates verification.md.json,
# verification-history.jsonl, and witness-fixes.json template
node plugins/ruflo-core/scripts/witness/init.mjs --root .
# Edit witness-fixes.json: add { id, desc, file, marker } per fix.
# A "marker" is a distinctive substring that MUST appear in `file`
# while the fix is present. If someone reverts the fix, the marker
# disappears and `verify` reports it as `regressed`.
# Regenerate the manifest (signs with Ed25519 from current gitCommit)
npm i @noble/ed25519
node plugins/ruflo-core/scripts/witness/regen.mjs \
--manifest verification.md.json \
--history verification-history.jsonl \
--fixes witness-fixes.json
# Verify markers are present in the live tree
node plugins/ruflo-core/scripts/witness/verify.mjs \
--manifest verification.md.json
```
## Temporal queries (ADR-103)
```bash
# Latest snapshot vs. previous
node plugins/ruflo-core/scripts/witness/history.mjs \
--history verification-history.jsonl summary
# For each currently-regressed fix, find the commit that introduced it
node plugins/ruflo-core/scripts/witness/history.mjs \
--history verification-history.jsonl regressions
# Status timeline for a specific fix
node plugins/ruflo-core/scripts/witness/history.mjs \
--history verification-history.jsonl timeline --id F1
# Machine-readable for CI
node plugins/ruflo-core/scripts/witness/history.mjs \
--history verification-history.jsonl summary --json
```
`summary` exits non-zero if any fix newly regressed since the last
snapshot — drop it in CI as a soft pre-merge gate.
## Anti-patterns
- **Hand-editing `verification.md.json`** — always regenerate via `regen.mjs`,
otherwise the signature breaks.
- **Markers that are too generic** (`'function'`, `'import'`) — pick something
unique enough that `grep` doesn't false-positive against unrelated code.
- **Skipping the history append** — without `--history`, you lose the
ability to bisect when a regression was introduced.
- **Committing one without the other** — `verification.md.json` and
`verification-history.jsonl` belong in the same commit; the JSONL is
what lets future you verify the signed manifest is the latest in the line.
## Files
- `scripts/witness/lib.mjs` — shared regenerate / history logic.
- `scripts/witness/regen.mjs` — CLI: sign + append history.
- `scripts/witness/history.mjs` — CLI: query the temporal log.
- `scripts/witness/init.mjs` — CLI: bootstrap into a fresh project.
- `scripts/witness/verify.mjs` — CLI: validate signature + markers.
## In ruflo's CI
`v3-ci.yml` job `witness-verify` runs after the behavioral smoke tests
and before `publish`. Failure modes:
| Failure | Cause |
|---|---|
| `signatureValid: no` | manifest hand-edited; re-run regen |
| `regressed: > 0` | a documented fix lost its marker since issuance |
| `missing: > 0` | a cited dist file no longer exists; rebuild or remove the entry |
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.