القائمة
Shared rules for all a9s agents — shell rules, package access, build/test commands
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
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
| name | a9s-common |
| description | Shared rules for all a9s agents — shell rules, package access, build/test commands |
Project rules (TDD, version bumps, lint, pre-push checklist, docs sync) live in
CLAUDE.md. This skill covers agent-specific operational details only.
core/aws/ — ADD new fetcher files. Do NOT modify existing fetchers.core/aws/catalog_<category>.go — ADD new catalog.ResourceTypeDef entries to the category slice only. Do NOT modify existing entries.core/config/defaults_<category>.go — ADD new default view definitions only. Do NOT modify existing entries.core/fieldpath/ — FROZEN. Never modify.internal/tui/ — Modify views, styles, layout, keys as needed; message types live in core/runtime/messages/.CI and CodeQL workflows skip docs-only changes via paths-ignore. The website has its own deploy workflow
triggered by website/** changes. Release workflow triggers only on v* tags.
| Workflow | Trigger |
|---|---|
| CI (lint, test, build, security, verify-readonly, install-test) | Code changes to main or PRs |
| CodeQL | Code changes to main or PRs, plus weekly schedule |
| Deploy Website | website/** changes pushed to main |
| Release (GoReleaser) | v* tag push only |