Sample investigation
A fictional example of a repository investigation and its expected result.
This fictional example shows what an investigation task can contain. It does not describe a real release or a repository ShipFoundry has inspected.
Recommendation
A product uses an authentication SDK. A release note describes a change to sign-in redirects. The project may need an update, but the relevant code has not been checked yet.
| Field | Example |
|---|---|
| Brief type | Engineering Spike |
| Readiness | Needs Repo Check |
| Question | Does this product depend on the redirect behavior described in the release note? |
| Known context | The product uses the SDK for sign-in and has a callback route. |
| Missing evidence | Installed version, callback implementation and test coverage. |
| Expected result | A finding about applicability, with file references and a proposed next step. |
An actual brief would include the source URL and available repository references. This example deliberately has neither.
Agent handoff
# Investigate the sign-in redirect change
## Inputs
- Read the release note linked in the ShipFoundry recommendation.
- Confirm the project and repository before starting.
- Use the brief's update ID when recording the result.
## Inspect
1. Check the installed SDK version in the lockfile.
2. Find the sign-in and callback code that uses the SDK.
3. Compare the current redirect handling with the documented change.
4. Inspect the relevant tests and run them if the environment permits.
## Scope
- Investigate only. Do not change code or provider settings.
- Do not include secrets or raw environment values in the report.
- If the release note or repository is unavailable, report that blocker.
## Return
- Whether the update applies, and why.
- Files inspected and evidence supporting the finding.
- Tests run, their results, and any checks not run.
- Remaining uncertainty.
- Proposed change and verification steps, if a change is needed.
Stop after the investigation. Implementation requires a separate instruction.Record the result
Record investigated with the inspected paths and findings. If a change is needed but postponed, record deferred with the reason. If the match was wrong, record false_positive and explain the mismatch.
Use adopted only after the change has been made and verified. Include the changed files, test results and a PR or commit URL when available.
See brief types and agent workflows for implementation handoffs and recurring reviews.