AICodingFlow

Generate a local static interactive D3 walkthrough of a pull request. Use when the user wants a zoomable PR map, graph/canvas PR orientation, or alternate visualization of PR system components, data flow, code dependencies, and user actions.

Bootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate `.github/issue-triage/config.json` and `.github/CODEOWNERS`. Use when setting up triage automation on a new or existing repository for the first time.

Compare a pull request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during PR review when approved or repository spec context is available.

Create a product spec from a GitHub issue in this repository by applying the local shared `write-product-spec` workflow with issue context and output paths. Use when an issue should be turned into a product spec artifact stored under `specs/issue-<issue-number>/product.md` and the agent should prepare file changes only, without creating commits or pull requests itself.

Create a technical spec from a GitHub issue in this repository by applying the local shared `write-tech-spec` workflow with issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/issue-<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or pull requests itself.

Repo-specific dedupe guidance . Only the categories declared overridable by the core dedupe-issue skill may be specialized here.

Detect duplicate GitHub issues by comparing the incoming issue's title and description against issue candidates provided by the workflow.

Implement a GitHub issue in this repository by applying the local shared `implement-specs` workflow with repository-specific issue, spec-context, and summary-file handling. Use when issue details are provided in the prompt and the agent should produce the implementation diff and handoff metadata without creating pull requests itself.

Implement an approved feature from the repository's product and tech specs, keeping specs and code aligned in the same change as implementation evolves. Use after the product and tech specs are approved and the next step is building the feature.

Generate product change reports under `docs/updates/` from recent code changes. Use when asked to summarize shipped changes, run scheduled product update reports, or analyze recent commits for reportable product and engineering updates.

Decide whether an issue or implementation PR changes long-term product knowledge, update docs/product when needed, and produce a structured docs sync decision for workflow automation.

Maintain the product LLM Wiki under docs/product/wiki, including raw-doc ingestion, compiled summaries and concepts, query guidance, structural lint rules, and staged review handling for uncertain product knowledge.

Repo-specific companion guidance for the core review-pr workflow. Do not use as the primary review entrypoint.

Review a GitHub pull request from pinned `pr_description.txt`, `pr_diff.txt`, and optional `spec_context.md` snapshots, then write and validate `review.json`. Use when a CI job or bot needs offline PR review comments without posting to GitHub.

Repo-specific companion guidance for the core review-spec workflow. Do not use as the primary spec review entrypoint.

Review a spec-only GitHub pull request from pinned `pr_diff.txt` and `pr_description.txt` snapshots, then write and validate `review.json` with document-quality findings.

Audit a pull request diff for common security concerns (input validation, sanitization, authentication and authorization, secrets management, unsafe dependencies, and related risks) and fold findings into the same review.json produced by the base PR review. Use as a supplement to `review-pr` whenever a code PR is being reviewed.

Audit a product or tech spec pull request diff for high-level security concerns (threat surface, authentication and authorization model, trust boundaries, sensitive data handling, secrets and key management, dependency posture, and abuse or misuse cases) and fold findings into the same review.json produced by the base spec review. Use as a supplement to `review-spec` whenever a spec PR is being reviewed.

Repo-specific triage guidance. Only the categories declared overridable by the core triage-issue skill may be specialized here.

Triage a newly filed GitHub issue in this repository by analyzing the report, inspecting relevant code, estimating reproducibility, suggesting the likely root cause, and returning structured triage output without mutating GitHub directly.

Learn repo-local duplicate issue guidance from recent maintainer duplicate closures and propose updates to the dedupe companion skill.

Improve repo-local PR review companion skills from human feedback on bot reviews. Use when updating review guidance from recent GitHub PR review feedback.

Learn repo-local issue triage guidance from recent maintainer triage corrections and propose updates to the triage companion skill or label config.

Run the repository PR review workflow locally from the current branch using temporary-directory snapshots and the same review.json contract as CI.

Run the repository spec review workflow locally from the current branch using temporary-directory snapshots and the same review.json contract as CI.

Create or update a GitHub pull request from a pushed branch after local review, base-branch sync, validation, and issue linking.

Create a GitHub issue from the current conversation or user-provided request by selecting the best `.github` issue template, filling it conservatively, and submitting it with GitHub CLI.

Diagnose CI failures for a PR, branch, run ID, or GitHub Actions run URL using the GitHub CLI, extract error logs, and generate a plan to fix them. Use when the user asks to check CI status, pull CI issues, triage test failures, or investigate PR build failures.

Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context. Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts, when `git status` shows unmerged paths, or when files contain conflict markers.

Create repository-compliant branches with efficient issue naming, base selection, and safety checks.

Create clean, repo-aware commits from real diffs with focused inspection, selective staging, and minimal tool calls.

Push committed branch work to the correct remote branch with minimal checks and no unsafe force pushes.

Create isolated Git worktrees for parallel branch work with efficient naming, base selection, and safety checks.

Drive a spec-first workflow for substantial features by writing a product spec before implementation, writing a tech spec when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.

Write a product spec for a significant user-facing feature in this repository, focused on detailed behavior and validation. Use when the user asks for a product spec, desired behavior doc, or PRD, wants to define feature behavior before implementation, or when the feature is substantial or behaviorally ambiguous enough that a written spec would improve implementation or review.

Write a tech spec for a significant feature in this repository after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.