jira-issue-use-aws

/jira-issue-use-aws — file a groomed Jira issue with an AWS-traced diagnosis

Arguments: $ARGUMENTS — parsed exactly like /jira-issue (see jira-issue.md in this commands directory): breadcrumb first, optional model:/effort: tokens anywhere, the rest is the description. The filing flow — codebase recon, duplicate check (JQL), groomed anatomy, fields, report — is /jira-issue's, unchanged. This command adds one phase: an AWS deep-dive between recon and drafting, run against the operator's current AWS CLI session. (Tracking work in GitHub instead? Use /gh-issue-use-aws.)

The AWS deep-dive

The point: many symptoms ("the tile shows zero", "downloads 403", "the pipeline never finishes") can't be root-caused from code alone — the answer lives in CloudWatch logs, resource configuration, IAM, or event history. An issue that ships with the cloud-traced root cause ("the Lambda's env var is missing on the deployed function — ARN ..., confirmed via get-function-configuration") is dispatchable without the implementer re-deriving the diagnosis with their own (possibly absent) AWS access.

Ground rules — read-only means read-only

• Identity first. Run aws sts get-caller-identity and note account + assumed role; state the account/region every finding came from. If the session's account doesn't plausibly match the environment the operator described, say so and stop the deep-dive — evidence from the wrong account is worse than none.
• Allowed operations: get-*, describe-*, list-*, lookup-events (CloudTrail), filter-log-events / tail (CloudWatch Logs), and the Logs Insights pair start-query/get-query-results (sanctioned despite the start- prefix — it reads, it doesn't change state; keep queries time-bounded, scanning costs money).
• Forbidden, no exceptions: anything that creates, updates, deletes, puts, attaches, modifies, tags, invokes, starts (other than start-query), stops, reboots, or terminates. lambda invoke counts as forbidden — executing code is not reading state.
• Secrets stay sealed. Diagnose with metadata (describe-secret, parameter descriptions, key existence) — never get-secret-value or get-parameter --with-decryption. If a diagnosis genuinely hinges on a secret's value, report that to the operator as an operator-action item instead of reading it.
• Use the session as-is. No --profile switching unless the operator named one. The session's permissions are the boundary — an AccessDenied is a finding ("diagnosis needs X permission"), not an obstacle to work around.
• Only sts get-caller-identity, log reads, and CloudTrail lookups are pre-approved above; other read calls will prompt per the project's permission settings. Adopting projects that use this command often should allowlist their common read patterns in .claude/settings.json rather than blanket-granting aws:* — the narrow grant is what keeps "read-only" enforceable.