AGENTS.md git:20261104.acd24f3A

Immutable. This exact content never changes and is served at /api/v1/blob/3ff64437ebe0d9de.

# SICTIC-AI agent instructions

## Using the toolkit

Apply this section when running skills or providing their outputs to users.

### Emailing individual insights

When a user requests an individual insight, their email address is provided,
and `gws` is available, ask once whether they want this and future insights
emailed to them. Remember and follow their answer within the conversation,
unless they change it.

If accepted, use the
[send_gmail](skills/send_gmail/SKILL.md) skill to send the
complete requested insight in the email body. This includes deep-dive
invitations. Send only the requested insights, not the dependencies a
workflow produced on the way. Application-feedback reviewer emails follow
the separately configured rule in application_feedback.

### Pitch deck review emails (`gws` on the VPS)

Product emails for completed reviews are separate from insight emails. They are
sent by the review API when `SPIKE_EMAIL_REPORTS=1`, using `gws gmail +send`.
Setup (install, OAuth export, Cursor Cloud notes) lives in
[spike/SETUP.md](spike/SETUP.md#email-reports-via-gws-optional-testing).

## Developing the toolkit

Apply this section when creating, modifying or reviewing repository code,
configuration or skill instructions.

### Read the standards first

Before modifying code, read
`skills/standards_and_architecture/SKILL.md`
and the documentation for the affected skills.

The standards skill is the authoritative reference for repository
conventions. Do not duplicate or redefine those conventions here.

### Scope and approval

Clarify unresolved requirements before editing. Ask before changing
skills outside the agreed scope or changing established contracts.
Approval already given does not need to be requested again.

### Preserve existing contracts

A request to add or fix functionality does not authorize changing
established conventions.

Preserve person identity and matching, filenames, storage layout,
manual-input precedence, cache behavior, public APIs, and registry
orchestration unless the user explicitly authorizes a change.

Before editing:

- Inspect the canonical shared implementation and its callers.
- Inspect a comparable existing skill and relevant tests.
- Check Git history when the intended convention is unclear.

If documentation and established behavior conflict, explain the
specific conflict before changing the affected contract. Do not
silently choose a new convention.

### Reuse shared implementations

Use the repository's existing abstractions for identity, matching,
paths, insight lifecycle, configuration, and orchestration.

Do not introduce local replacements, alternate discovery paths,
filename variants, or generation modes without checking how they
interact with existing consumers and caches.

### Verify compatibility

Run tests appropriate to the changed behavior.

Put lasting regression coverage in pytest rather than leaving temporary
verification scripts.

For changes affecting shared contracts, add or retain regression
coverage based on the established behavior. Do not change test
expectations merely to make a new implementation pass.

Review the complete diff before finishing. Check for unintended
changes to conventions, callers, configuration, and documentation.

Report what changed, what was verified, and any remaining
compatibility risks.