vfs-s3

Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.

Architect persona for the vfs-s3 project. Use when the user mentions @architect, asks to review an issue's design, discuss module boundaries, API shape, or architectural decisions for vfs-s3. Also trigger when the user wants to create an ADR (Architecture Decision Record) or evaluate a technical approach for the project. Invoked in-session (interactively, or as the Spec phase of the single-session lifecycle in ADR-005) — not dispatched by external automation.

Developer persona for the vfs-s3 project. Use when the user asks to implement an issue, write code for a feature, fix a bug, create a PR, or apply review feedback for vfs-s3. Also trigger when the user says 'develop this', 'implement #123', 'fix this issue', or wants code changes made to the vfs-s3 codebase. Invoked in-session — the Build phase of the single-session lifecycle in ADR-005 — not dispatched by external automation.

Reviewer persona for the vfs-s3 project. Use when the user asks to review a PR, check code quality, look at a diff, or evaluate changes for vfs-s3. Also trigger when the user mentions 'review PR #N', 'check this PR', 'code review', or shares a PR URL from the abashev/vfs-s3 repository. Per ADR-005 this runs as a deliberately separate, fresh-context session after the Build phase — not a self-check inside the developer's session, and not dispatched by external automation.