reproduce-and-fix-issues

Files (4)

• SKILL.md
• feature-map.example.md · references/
• verification-adapter.md · references/
• verify-existing-fix.md · references/

SKILL.md (first lines)

# Reproduce and fix issues

The run prompt carries the intake binding: the source item, the source thread, the verdict location, and the adapter that reads and posts. Read the binding contract and the adapter notes in [`../../references/intake-binding.md`](../../references/intake-binding.md) before the first source read or post.

The event either names one report through the binding or asks for a sweep (`{"sweep": true}`). On a sweep, the binding names the source collection and the adapter; scan it for the oldest report that carries a trusted triage marker from the binding's trusted verdict identity, has no repro reply yet, and is still inside the configured verdict budget. Run that one report. Stop cleanly when there is none; a sweep that finds nothing is not a failure.

Wait for a trusted triage marker in the source thread. Reproduce the exact symptom through the target app's real UI. Verify an existing fix when one exists. Attempt a bounded fix only after a confirmed repro.

Load the external Benny configuration supplied by the run. If the config, the binding, the adapter, the verification skill, or the completed feature map is missing, stop without posting or writing to the source.

## Hard safety rules

- Exactly one verdict per run, posted at the binding's verdict location through the binding's adapter.
- Never open a new top-level post for the report.
- The binding's source coordinates are immutable.
- Preflight the source item before every source-thread post.
- The coordinator is the only adapter poster.
- Delegated analysis workers are read-only and return findings or media notes.
- A fix-phase code worker may edit only when its environment provably excludes adapter credentials and every adapter write action. Otherwise the coordinator edits.
- Every child prompt must forbid every adapter write, naming the concrete actions from the adapter contract.
- Never give a child adapter credentials, posting instructions, source coordinates for posting, or permission to report externally.
- If a child needs adapter write access to run, do not launch it.
- Utility bots are evidence sources. They do not own the fix unless a person explicitly delegated the fix to them.
- The exact discriminating symptom must appear twice through real UI interaction.
- State inspection may confirm an observation. It must not inject or force the symptom.
- No confirmed repro means no authored fix.
- Existing pull requests or commits switch the run to verify mode. Do not author over them.
- Use `github.com` pull request links.
- Keep captures, recordings, logs, and tokens out of source control.
- Fail closed when the binding, the adapter, the verification skill, or the completed feature map is missing or uncertain.
- Use pstack's `principle-guard-the-context-window` for delegated analysis.
- Apply pstack's `principle-sequence-verifiable-units`, `principle-fix-root-causes`, and `principle-prove-it-works` through repro, fix, and verification.

## Subagents on pi

Spawn delegated workers with pi-pstack's `subagent` tool and `readonly: true`, which pins `read`, `grep`, `find`, and `ls`. A subagent is a separate pi process that inherits the parent environment, so never export an adapter credential into an environment a worker will run in. Keep the coordinator as the only poster.

## 1. Freeze the binding

Before making a work list or delegating:

1. Read the source item, source thread, and verdict location from the binding.
2. Require all three to be nonempty and consistent with the event or the sweep result.
3. Store them as SOURCE_ITEM, SOURCE_THREAD, and VERDICT_LOCATION, fixed for the run.
4. Read the source thread through the binding's adapter and verify that its root is the source item.
5. Fetch the source permalink through the adapter.

Never replace these values with a reply, operations, or status-message coordinate.

Before every source post:

1. Read the source thread by the fixed coordinates through the adapter.
2. Confirm the source item exists, is not deleted, and still belongs to the source thread.
3. Post only through the binding's adapter, at the verdict location.
4. Read the source thread again and verify the new message is at the verdict location.

If any check fails, post nothing. Never retry at the source root or in a fallback location.

## 2. Wait for the triage contract

Watch the source thread through the adapter for the configured verdict budget. Stay silent while waiting.

Accept a verdict only when:

- Its author matches the binding's trusted verdict identity.
- It is at the verdict location under the source thread.
- It contains exactly one configured marker.

Public marker forms:

```text
[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]
```

Proceed only for `bug` or `performance`. Capture the optional tracker URL. Stop silently for `other`, a missing verdict, an untrusted author, conflicting markers, or a timeout.

This marker replaces private bot identities and free-form verdict matching.

## 3. Apply ownership and fix-artifact gates

Re-read the source thread through the adapter immediately before starting work.

### Someone is explicitly fixing it

Stop when a person clearly claims the fix, gives a concrete implementation plan, or asks another agent to implement, patch, fix, or open a pull request.

Do not treat these as fix ownership:

- A bot summarizes evidence.
- A tool looks up logs or tickets.
- Someone asks a bot to diagnose, explain, inspect, or reproduce.
- A bot posts a cause hypothesis without agreeing to implement it.

Judge the requested action, not the presence of a bot.

### A fix artifact already exists

If an open pull request or merged commit plausibly fixes this report, switch to `references/verify-existing-fix.md`.

An artifact may come from the source thread, tracker issue, repository history, or pull request search. A claim without a commit or pull request is not a fix artifact.

If a person owns the work but has not produced an artifact, stop. Do not race them.

## 4. Use the optional operations location

When the binding names a separate operations location, such as an operations thread, the coordinator may create one root status message there. This is the only allowed top-level post in the repro workflow. Store its coordinates as OPERATIONS_LOCATION and never confuse them with the source coordinates.

When the binding names the run output, keep detailed status there and post no status message. Never substitute a source-thread root post.

Use the configured plain Unicode status strings. Keep status text short:

- Reproducing
- Could not reproduce
- Blocked
- Reproduced

From gh0stwin/pi-pstack, MIT.

More from gh0stwin/pi-pstack