chat

Imported from strands-compose/chat (AGENTS.md). Install upstream with npx skills add strands-compose/chat. Copyright stays with the author.

strands-compose-chat — Agent Instructions

This is strands-compose-chat: a chat UI for strands-compose with the strands-compose-agentcore AWS Bedrock AgentCore adapter.

Communication Style — MANDATORY

Executive summary only. Answer in the first line. 1-3 sentences for a direct question; yes/no starts with yes or no. Bullets or a table over prose.

Detail, rationale, and background ONLY if the user explicitly asks.

Forbidden unless requested: multi-section reports, headers, narrating what you read or searched, recapping earlier turns, storytelling, praise, filler, end-of-task summaries of a visible diff.

Never cut: uncertainty, verified-vs-assumed, corrections that change a decision, risk warnings before destructive actions.

Read the Skill First — MANDATORY

Before touching any code, load the skill for the area you are working in. Skills are the authoritative source for conventions, mental models, patterns, dependency rules, and file placement. Everything language- or framework-specific lives there, not here.

If you work on the backend, read the backend skill. If you work on the frontend, read the frontend skill. If you work on both in one task, read both. No exceptions.

The skills describe the target standard — follow them, not whatever pattern happened to be written before the skill existed.

Core Principles — Apply Everywhere

These values guide every decision across both backend and frontend. When in doubt, apply them in order.

1. SDK-first — always check what strands-compose / strands-compose-agentcore already provides before implementing anything from scratch. Use the SDK directly; never re-implement what it exports.
2. Explicit over implicit — no hidden magic, no auto-registration, no global singletons. Wire things by hand and make dependencies obvious.
3. Simple over clever — the dullest solution that correctly solves the problem is the right one. Readable and maintainable beats terse and "efficient".
4. Transparency over performance — prefer code that clearly shows what it does over code that squeezes out speed at the cost of legibility. Optimize only when you have measured evidence that it matters.
5. Composition over inheritance — build big things out of small, focused pieces that compose. Prefer functions, small modules, and thin wrappers over deep class hierarchies.
6. Single responsibility — each file, module, component, and function does one thing. When something grows a second job, split it.
7. One-way dependencies — inner layers never import outward. The dependency direction for each area is defined in its skill.

Behaviour Rules — Apply Everywhere

• Smallest reasonable change. Don't refactor unrelated code to land a feature. Touch only what the task requires.
• Read before writing. Before editing a file, read it. Before creating something new, read a sibling that plays the same role and match its shape.
• No hardcoded secrets. All credentials and sensitive config come from environment variables.
• Comments explain what and why, never when or how something changed. No temporal context ("recently refactored", "moved from …") in comments.
• If you find something broken in the area you're working, fix it. Don't leave broken or commented-out code behind.
• Never add files or change code outside the scope of the task.