This file provides guidance to AI coding assistants when working with this repository.
This repository contains reusable AI coding workflows and focused skills that can be installed globally or per-project in any environment (Cursor, Claude Code, Gemini, Codex). Each package is a self-contained directory with structured markdown files that AI agents can read and execute.
Current simple skills:
- report-bug — Configurable, evidence-based Jira Bug reporting with explicit confirmation
Current workflows:
- ai-ready — Codebase scanning and AGENTS.md generation (update)
- bugfix — Systematic bug resolution (assess, reproduce, diagnose, fix, test, review, document, pr)
- code-review — AI-driven code review with human-in-the-loop decisions (start, continue, clean)
- cve-fix — Automated CVE remediation from Jira tickets (start, scan, patch, validate, pr, backport, close | standalone: report)
- design — Design-and-decompose workflow (ingest, research, draft, decompose, revise, publish, respond, sync)
- docs-writer — Documentation creation workflow (gather, plan, draft, validate, apply, mr)
- e2e — Story-to-tests workflow for [QE] stories (ingest, plan, revise, code, validate, publish, respond)
- implement — Story-to-code workflow (ingest, plan, revise, code, validate, publish, respond)
- kcs — KCS Solution article workflow (gather, draft, validate, handoff)
- prd — Requirements-to-PRD workflow (ingest, clarify, draft, revise, publish, respond)
- rebase-stack — Rebase a stacked-branch chain with conflict guidance, per-branch validation, and push (start, continue, validate, push)
- sizing — Pre-cycle Feature sizing with T-shirt sizes and team effort breakdowns (ingest, assess, apply)
- skill-reviewer — Meta-workflow that audits AI skill directories
- triage — Bulk Jira bug triage with AI-driven categorization and HTML reports
Every workflow follows this canonical structure:
workflow-name/
SKILL.md # Entry point with YAML frontmatter (name, version, description)
guidelines.md # Behavioral rules: principles, hard limits, safety, quality
README.md # Human-readable documentation (prerequisites, artifacts, usage)
skills/
controller.md # Optional discovery and ambiguous-input router
dispatch.md # Optional lightweight explicit-phase dispatcher
completion.md # Optional centralized next-step guidance
phase-name.md # Implementation for each phase
commands/
phase-name.md # Thin wrappers that invoke a controller, dispatcher, SKILL.md, or phase
scripts/ # Optional — deterministic operations invoked by skills
prompts/ # Optional — prompt templates for sub-agent delegation
Simple skills live at skills/{skill-name}/ with a SKILL.md entry point and
only the references, scripts, or assets they need.
skills/
skill-name/
SKILL.md # Entry point with YAML frontmatter
references/ # Optional conditional instructions and schemas
templates/ # Optional generated-content templates
scripts/ # Optional deterministic implementation helpers
Simple skills are focused capabilities, not phase-based workflows. Add only the resources required by the skill; they do not need a controller, commands, guidelines, README, or artifact lifecycle by default.
Key architectural principles:
- Auto-discovery: The installer discovers top-level
*/SKILL.mdworkflows andskills/*/SKILL.mdsimple skills; package names must be globally unique - Progressive disclosure: SKILL.md is thin (under 30 lines); details live in workflow guidelines/phases or a simple skill's references
- Relative paths: All file references must be relative to the file's location (for symlink compatibility)
- Phase-based execution: Most workflows operate through discrete phases with explicit transitions
- Shared resources: Cross-cutting concerns live in
_shared/and are referenced by relative path from workflows or simple skills - Phase overrides: Projects can override individual phases by placing a replacement skill file at
.workflows/{workflow}/skills/{phase}.mdin their repo root. The controller or lightweight dispatcher checks for this override before falling back to the built-in default. See CONTRIBUTING.md for details.
_shared/
provenance-schema.md # Provenance contract for planning docs (footer + session log)
content-rules.md # Shared generated-content rules for all workflows
review-protocol.md # Shared code review criteria, finding format, severity definitions
sizing-rubric.md # Shared sizing definitions (T-shirt sizes, heuristics, team effort guidance)
scripts/
provenance.py # Capture/render CLI (used by prd and design provenance recipes)
recipes/
capture-provenance-event.md # Append session-local provenance on doc-mutating phases
phase-override-resolution.md # Project-level phase override lookup and activation
record-manual-edit.md # Tier 3 manual-edit attribution (wraps capture recipe)
render-provenance-footer.md # Render durable footer into docs-repo markdown before commit
self-review-gate.md # Pre-PR self-review quality gate (used by bugfix, implement, e2e, cve-fix)
validation-gate.md # Pre-commit build/test/lint discovery gate (used by bugfix)
Recipes are self-contained, parameterized procedures that packages reference via relative path (e.g., ../../_shared/recipes/self-review-gate.md from a workflow phase). Workflows and simple skills may also reference shared files from guidelines, phases, references, templates, prompts, scripts, and other behavioral files — all such references count as consumers for the shared-file cascade (see Package Versioning). The prd and design workflows use the provenance recipes on /draft, /revise, /respond (capture) and /publish plus docs-sync paths (render). See _shared/provenance-schema.md for the published footer format.
Critical for symlink resolution:
commands/*.mdreference../skills/controller.md,../skills/dispatch.md,../SKILL.md, or../skills/phase-name.md; dispatchers identify the target with an explicit phase parameterskills/controller.md,skills/dispatch.md, andskills/completion.mdreference sibling skills asphase-name.md(notskills/phase-name.md)SKILL.mdreferencesguidelines.mdand optionallyskills/controller.md(same directory)skills/{skill-name}/SKILL.mdreferences its resources relative to the simple skill directory (for example,references/rendering.md)
- No IDE-specific syntax: All workflow and simple-skill content is plain markdown
- Relative paths only: For symlink compatibility across install scopes
- Progressive disclosure: SKILL.md stays under 30 lines
- No auto-advance in attended mode: Workflows wait for user input between phases unless an explicit unattended mode is documented for that workflow
- Artifact persistence: Significant workflow outputs are saved to
.artifacts/{workflow-name}/{context}/; simple skills persist artifacts only when their contract explicitly requires it - Read-only reviews: skill-reviewer never modifies target skill files during review
- Artifact isolation:
.artifacts/{workflow-name}/is each workflow's private state. Other workflows must never read from or write to another workflow's artifact directory. The shared interfaces between workflows are: Jira (canonical source for issue data), published docs repo files (PRDs, designs, testplans), and workspace-level config at.artifacts/config.json
When modifying a committed workflow or simple skill, update the version in that
package's SKILL.md frontmatter following semver. A new, uncommitted package may
remain at its initial 0.1.0 while it is being developed:
- PATCH (0.1.0 → 0.1.1): Typo fixes, wording clarification without behavioral change, formatting
- MINOR (0.1.0 → 0.2.0): Adding/changing/reordering behavior, modifying rules, changing templates, or adding workflow phases
- MAJOR (0.1.0 → 1.0.0): Removing or renaming public phases, commands, configuration keys, or other package interfaces; incompatible restructuring
Behavioral files (the AI reads and executes these):
SKILL.md body, guidelines.md, skills/*.md, commands/*.md,
templates/*, prompts/*, scripts/*, _shared/**/*.md, and
root-level .md files in workflow directories that are read during
execution (e.g., design/decomposition-review.md). For simple skills, this
includes skills/{skill-name}/SKILL.md, references/*, templates/*,
prompts/*, scripts/*, and other files read or executed by the skill.
Non-behavioral files (no bump needed): README.md, GUIDE.md
When you modify a file in _shared/, also PATCH-bump every workflow or simple skill
that references it — including references in templates, prompts, scripts,
and other behavioral markdown listed under "Which files require a version
bump". Find affected workflows by searching for the basename (e.g.,
self-review-gate for _shared/recipes/self-review-gate.md, or
content-rules for _shared/content-rules.md):
grep -rl "<basename-without-extension>" \
*/SKILL.md \
*/guidelines.md \
*/skills/*.md \
*/commands/*.md \
*/templates/*.md \
*/prompts/*.md \
*/scripts/* \
2>/dev/null | sed 's|/.*||' | sort -u
grep -rl "<basename-without-extension>" \
skills/*/SKILL.md \
skills/*/references/*.md \
skills/*/templates/* \
skills/*/prompts/*.md \
skills/*/scripts/* \
2>/dev/null | sed -E 's|^(skills/[^/]+)/.*|\1|' | sort -uAlso check simple-skill references/templates/scripts and root-level workflow
.md files read during execution (e.g., design/decomposition-review.md). The CI script
.github/scripts/validate-versions.sh applies this full set of patterns.
Bump each discovered consuming package's SKILL.md version (PATCH increment).
Include the version bump in the same commit as the behavioral change. Do not make a separate commit for the version bump.
Install with ./install.sh <target> (targets: cursor, claude, gemini,
codex, all). See README.md for scopes, options, and uninstall instructions.
See CONTRIBUTING.md for workflow and simple-skill structure conventions, path rules, testing, and installation internals.
ai-workflows/
├── _shared/ # Cross-cutting shared resources
│ ├── provenance-schema.md # Planning-doc provenance contract (footer + session log)
│ ├── content-rules.md # Shared generated-content rules for all workflows
│ ├── review-protocol.md # Shared code review criteria and finding format
│ ├── sizing-rubric.md # Shared sizing definitions and heuristics
│ ├── scripts/
│ │ └── provenance.py # Capture/render CLI for prd/design provenance
│ └── recipes/
│ ├── capture-provenance-event.md
│ ├── phase-override-resolution.md # Project-level phase override lookup
│ ├── record-manual-edit.md
│ ├── render-provenance-footer.md
│ ├── self-review-gate.md # Pre-PR self-review quality gate
│ └── validation-gate.md # Pre-commit build/test/lint discovery gate
├── ai-ready/ # Workflows (auto-discovered via SKILL.md)
├── bugfix/
├── code-review/
├── cve-fix/
├── design/
├── docs-writer/
├── e2e/
├── implement/
├── kcs/
├── prd/
├── rebase-stack/
├── sizing/
├── skill-reviewer/
│ ├── prompts/
│ └── scripts/
├── triage/
├── skills/ # Focused skills (auto-discovered via SKILL.md)
│ └── report-bug/
│ ├── SKILL.md
│ ├── references/
│ ├── scripts/
│ └── templates/
├── install.sh # Installer with auto-discovery
├── uninstall.sh # Removal script
├── AGENTS.md # AI assistant guidance (this file)
├── CLAUDE.md # Claude Code reference (points to AGENTS.md + install.sh appends here)
├── CONTRIBUTING.md # Workflow development guide
├── README.md # User-facing documentation
└── .gitignore # Excludes .cursor/, .claude/, .artifacts/, etc.
When a workflow or simple skill invokes commands that could affect shared systems:
- Git operations: Always verify with
git statusbefore destructive operations - PR/MR creation: Confirm branch and base before pushing
- Jira writes: cve-fix
/close, design/sync, sizing/apply, andreport-bugmay write to Jira; all require explicit approval.report-bugmay create only the fully previewed issue and approved follow-up links/attachments - Documentation changes: Run Vale validation before applying changes to repository files