a9s

Recipe for adding a list-view attention column to a resource type — handles Tier A (existing field), Tier B (computed/Wave-2), and the FieldUpdates promotion path. Optimized to avoid the rediscovery overhead that plagued the first Tier A sweep.

Bug-hunting workflow for a9s using real AWS data, grounded in docs first, then live behavior, then code. Use for EC2-detail and related-view QA where existing tests may be misleading.

Shared rules for all a9s agents — shell rules, package access, build/test commands

Create or update the single-source fixture file for a resource type under `core/demo/fixtures/<shortName>.go`. Use when the coder is given a fixture-creation task during phase 6 of `a9s-implement-resource`, or any time a resource type needs new demo/test data (new states, new edge cases, new spec coverage). Takes a plain-language fixture list (typically from `docs/resources/<shortName>-impl-plan.md` §2) and produces realistic, graph-connected AWS SDK typed fakes that both `./a9s --demo` and the unit test suite import. Cross-references sibling fixture files so every related-panel pivot renders a non-zero count. Never creates orphan fixtures — a DB instance fixture without matching KMS keys, security groups, alarms, and CloudTrail events is a bug, not a feature. Adversarial / malformed fixtures (nil pointers, error cases) stay inline in tests and are explicitly out of scope for this skill.

End-to-end workflow for implementing a GitHub issue — from analysis through QA stories, design, scoped tasks, implementation, pre-release checks, and release prep. Use for any issue that is NOT a new-resource or child-view (those have their own skills).

Implement (or re-implement) an a9s resource type from its golden UX/UI spec at `docs/resources/<shortName>.md`. Use whenever the user asks to "implement", "wire up", "finish", "fix", or "rebuild" a resource that already has a spec doc — including cases where partial, stubbed, or buggy code exists and must be replaced. Treats the spec doc as the contract and the existing implementation as disposable. Reads ONLY the spec doc and four contract-surface files (`<shortName>_interfaces.go`, `<shortName>_related.go`, `<shortName>_issue_enrichment.go`, `<shortName>_detail_enrichment.go`); never reads existing tests or fetchers. Dispatches `a9s-qa` and `a9s-coder` with scoped file lists. Cleans up stubs and "pretend to work" code tied to TBDs. Trigger this for any request that names a resource shortName and asks for implementation, tests, fixtures, or cleanup — even if the user doesn't explicitly mention the spec doc.

Blueprint for adding a new child view to a9s — 3-phase workflow (scope -> QA tests -> coder implement) with exact file manifests and hard-won lessons

Blueprint for adding related-resource views to an a9s resource type -- split into CODER steps (1-7) and QA steps (8-12) with templates

Blueprint for adding a new AWS resource type to a9s — split into CODER steps (1-8) and QA steps (9-13) with templates

Bubble Tea v2 / Lipgloss v2 / Bubbles v2 API patterns for TUI-touching agents

Run the a9s TUI smoke test — tmux-driven, real binary, rendered-surface assertions. Use whenever the user says "смоук"/"smoke", asks to verify the app end to end, after any UI-affecting change, or before a push (the demo smoke is part of `make ready-to-push`). Covers the scripted BASE walk plus checks you compose for whatever THIS session changed.

Full live traversal of the a9s TUI against a real *readonly* AWS account — every resource type walked end to end. Use when the user asks to "traverse", "walk everything", "full sweep", "check all types live", or wants a comprehensive audit that main-menu issue counts match the lists, every detail opens with a working related panel, related pivots drill correctly, and no error surfaces anywhere. Broader and more exhaustive than `a9s-smoke` (which samples a few types).

Generate a uniform, implementation-blind specification for a single a9s resource type. Use whenever the user asks to "spec", "document", or "describe" a resource by its shortName (e.g. "spec ec2", "write the resource doc for dbi", "generate the lambda spec", "create docs/resources/s3.md"), or asks for the contract, related panel, issues algorithm, or Wave 1/Wave 2 behavior for a named AWS resource type in the a9s codebase. Reads only the four golden docs in docs/ — never source code — and writes docs/resources/<shortName>.md following a strict template so all resource specs are diff-able and can drive test and fixture generation. Trigger this skill for any request that names an a9s resource shortName and asks for a doc, spec, contract, or behavior summary.

Use for any question about a codebase, its architecture, file relationships, or project content — especially when graphify-out/ exists, where the question should be treated as a graphify query first. Turns any input (code, docs, papers, images, videos) into a persistent knowledge graph with god nodes, community detection, and query/path/explain tools.