Vigilante issue implementation on github actions

Vigilante GitHub Actions Issue Implementation

Focus

• Read the prompt for detected tech stacks, process hints, and security guidance before changing workflow files.
• Keep changes scoped to the issue and do not broaden into unrelated workflow or repository changes.
• Treat .github/workflows/ as a security-sensitive surface. Every workflow edit should consider permissions, secret exposure, and supply-chain risk.

Workflow File Conventions

• Use .yml or .yaml consistently with the repository's existing convention. Do not mix extensions within the same repository.
• Validate workflow syntax before committing. Use actionlint when it is available in the repository or installed locally. If actionlint is not available, note its absence and continue — do not fabricate output.
• Keep workflow files readable: use clear job and step names, add inline comments for non-obvious logic, and prefer reusable workflows or composite actions over duplicated step blocks.

Pinned Actions

• Pin third-party actions to full commit SHAs, not mutable tags or branch references. Example: uses: actions/checkout@<full-sha> with a trailing version comment.
• When updating an action version, verify the new SHA corresponds to a reviewed release or tag.
• First-party GitHub actions (actions/*) should also be pinned to SHAs for consistency and supply-chain safety.
• When adding a new third-party action, prefer well-maintained actions with high community adoption. Avoid actions that request broad permissions or lack clear provenance.

Least-Privilege Permissions

• Always declare a top-level permissions: block in workflow files. Default to the most restrictive set needed.
• Use read-only contents: read unless the workflow must write (e.g., creating releases, pushing tags, commenting on PRs).
• Scope token permissions per job when different jobs need different access levels.
• Never use permissions: write-all or leave permissions unspecified, which defaults to broad access in some repository configurations.

Secret and Credential Safety

• Never echo, log, or interpolate secrets directly in run: shell commands. Pass secrets through environment variables.
• Use ::add-mask:: to mask dynamic values that may appear in logs.
• Prefer OIDC-based authentication (e.g., aws-actions/configure-aws-credentials with role-to-assume) over long-lived cloud credentials stored as repository secrets.
• Do not store secrets, tokens, or credentials in workflow files or committed configuration.
• When a workflow needs elevated access, document why in a comment and scope the access as narrowly as possible.

Safe Workflow Authoring

• Never interpolate untrusted event data (such as ${{ github.event.pull_request.title }} or ${{ github.event.issue.body }}) directly into run: shell scripts. Use an intermediate environment variable to prevent script injection.
• Prefer pull_request over pull_request_target unless cross-fork access is explicitly required and the workflow is hardened against injection.
• Use concurrency groups to prevent redundant or conflicting workflow runs.
• Set appropriate timeout-minutes on jobs to prevent hung runners from consuming resources.

Reusable Workflows and Composite Actions

• Prefer the repository's existing reusable workflows and composite actions over duplicating logic.
• When creating new reusable workflows, define clear inputs and secrets contracts.
• Respect the repository's branch-protection rules and required status checks when adding or modifying workflows.

Mixed-Stack Repositories

• A repository with GitHub Actions workflows often also contains application code in Go, Node.js, Python, or other languages.
• Scope workflow-specific guidance to .github/workflows/ and related CI/CD configuration only. Do not apply workflow linting or hardening rules to application source code.
• When an issue touches both workflow files and application code, validate each side with its appropriate toolchain.
• Check the prompt for additional detected tech stacks and follow their respective guidance for non-workflow changes.

Workflow

• Follow the base vigilante-issue-implementation workflow for issue comments, validation, push, and PR creation, including stacked base-branch detection (Base branch: directive in the issue body).
• Use vigilante commit for all commit-producing operations. Do not use git commit or GitHub CLI commit flows directly.
• Any commit or amend must preserve the user's existing git author, committer, and signing configuration. Commit on behalf of the user and do not overwrite git config with a coding-agent identity.
• Do not add Co-authored by: trailers or any other agent attribution for Codex, Claude, Gemini, or similar coding-agent identities.
• Repository-specific instructions (AGENTS.md, README.md, CI config) remain authoritative when they are more specific than the generic GitHub Actions guidance in this skill.