Prompt for Kiro

Create a steering file at .kiro/steering/project.md capturing how this repository works, based on what you find in the codebase.

INCLUDE
- Purpose: one paragraph on what this project does.
- Stack and versions, taken from the manifests you find.
- Directory map: what belongs where, and where new code should go.
- Commands: install, dev, build, test (whole suite and single test), lint, format.
- Conventions: naming, error handling, logging, state management, data access.
- Testing rules: what must have tests, what style, where they live.
- Guardrails: never edit [generated files / applied migrations], never commit secrets, ask before adding dependencies or changing schemas.
- Definition of done: build passes, tests pass, lint clean.

RULES
- Verify every command against the actual config files rather than assuming.
- Imperative voice, no filler sections, under 150 lines.
- Flag anything you could not confirm as "TODO: confirm".

GOAL: [user-visible outcome in one sentence].

READ FIRST: [file paths that matter]
FOLLOW THE PATTERN IN: [reference file]

BEHAVIOUR
- [Requirement 1 as observable behaviour]
- [Requirement 2]
- Edge cases: [empty state], [error from dependency], [permission denied]

CONSTRAINTS
- No new dependencies without asking.
- Do not change the public interface of [module].
- Match existing error handling and logging.
- Keep the diff minimal; no opportunistic refactors.

ACCEPTANCE CRITERIA
1. [Checkable]
2. [Checkable]
3. Existing tests still pass.

VERIFY BEFORE REPORTING DONE
- `[build command]`
- `[test command]`
- `[lint command]`

OUT OF SCOPE: [files or areas to leave alone]

Plan first: list the files you will touch and why, then implement.

I want a spec for [feature].

PROBLEM: [who has it, what it costs them today]
CURRENT BEHAVIOUR: [how the system works now, and which files own it]
DESIRED BEHAVIOUR: [what should be true afterwards]
NON-GOALS: [explicitly out of scope]
CONSTRAINTS: [performance budget, backwards compatibility, data migration limits, deadline]
USERS AFFECTED: [segments, and any permissions differences]

For requirements, cover the unhappy paths as well: [empty data], [concurrent edits], [offline], [rate limits].

For design, I want to see: the data model changes, the interfaces involved, where the logic lives, the migration path, and the rollback plan.

Ask me anything ambiguous before writing the design. Keep tasks small enough that each one can be verified on its own.

Explain how [feature/flow] works in this repository. Read the code before answering — do not generalise from the framework's usual patterns.

I NEED
1. Entry points: where a request or interaction starts, with file and line references.
2. The path it takes through the code, in order, naming each file.
3. Where state or data is persisted, and the shape of it.
4. Error handling: what happens when [dependency] fails.
5. Tests that cover this flow, and obvious gaps.
6. Anything surprising, risky or clearly legacy.

FORMAT
Numbered walkthrough with file:line references. Say explicitly when something is unclear from the code rather than guessing.

Create a Kiro hook that runs after a task is marked complete.

TRIGGER: task completion.
ACTION: run `[test command]` and then `[lint command]`.
BEHAVIOUR ON FAILURE: report the failing output so it can be fixed before I review.

Also suggest two more hooks that would help this project specifically, based on what you see in the repository — for example a format-on-save hook for [file types], or a check that [generated artefact] was regenerated when [source] changed. Explain the trigger, the action and why it is worth automating for each.