CI/CD AI Review Kit

# CI/CD AI Review Kit

AI Summary

Purpose:

• Capture durable facts about the LabradorLabs CI/CD AI Review Kit so human portfolio outputs stay grounded in the actual labrador-cicd-ai-review-kit Bitbucket repository.

Key points:

• Source Bitbucket repository: labradorlabs/labrador-cicd-ai-review-kit.
• The kit is a bootstrap kit for the development-completion flow, not a generic repo-standards document.
• It standardizes Jira, Bitbucket Pipelines, Docker image push, Claude-based AI PR review, and Slack notification routines across multiple Bitbucket repositories.
• Target repositories keep only thin wrappers/configuration; common behavior lives in the central kit repository.
• The standard flow is Jira issue/branch → local or branch-push validation → automatic PR creation → Claude-based AI PR review after tests and secret scan → Slack merge-ready notification → review/approval → main merge → main pipeline test → Docker image build/push → actual deployment system/Jira deployment event.
• The kit supports java-spring, go, python, js, and mixed profiles.
• mixed profile can test only components affected by changed paths and fails by default when a changed path is not mapped, reducing false-green risk.
• Production repositories pin the executed kit version by full commit SHA; moving refs like main are not trusted as execution anchors.
• PR event pipelines are not the core path. The branch-push pipeline creates the PR and continues into AI review; destination-branch policy matters only when PR-event execution happens.
• AI review first creates PR diff, runs secret scan, then calls Claude only when suspicious secrets are not found; raw secrets are not written to logs/artifacts.
• Bitbucket branch restrictions and merge checks are required for enforcement; copying kit files alone does not enforce merge policy.
• User-confirmed on 2026-07-22: the kit is currently applied and used. In crawler

repositories, spec.md is treated as the data-format/change contract so tests and AI review can flag implementation changes that drift from the expected output format.

Relevant when:

• Updating human/portfolio/items/ai-cicd-review-kit.html.
• Writing resume/portfolio material about CI/CD centralization, AI PR review, Bitbucket/Jira/Slack development workflow automation, and pipeline quality gates.

Do not read full document unless:

• Exact operational constraints, failure modes, or profile-level behavior are needed.

Linked documents:

• human/portfolio/items/ai-cicd-review-kit.html
• human/portfolio/index.html
• ai/wiki/projects/labrador-platform.md
• ai/sources/career/2026-07-22-spec-driven-crawler-review-clarification.md

Open Questions

• Quantitative adoption metrics such as number of repositories actually

onboarded are not confirmed here. Current operational use is user-confirmed, but no repository count should be claimed unless later verified.

• Runtime reduction or review-time reduction percentages are not confirmed and should not be invented.
• The number of data-format drift issues caught through spec.md review is not

measured and should not be invented.

Details

What the work was

The work was not simply adding an AI reviewer to CI. The stronger framing is that it created a central CI/CD execution kit for a repeatable development-completion routine across Bitbucket repositories.

The kit pulls common logic into one central repository and leaves target repositories with thin wrapper/configuration files. This avoids each repository growing a different copy of similar CI scripts.

Standard flow

The intended flow in the current kit repository is:

1. Jira issue and branch convention.
2. Local or pre-push validation.
3. Bitbucket branch push pipeline.
4. Automatic PR creation when branch validation succeeds.
5. Claude-based AI PR review after branch validation and secret scanning the diff.
6. Slack merge-ready or failure notification with short failure summary and pipeline/PR links.
7. Human review/approval and main merge.
8. Main pipeline test.
9. Docker image build/push.
10. Actual deployment system/Jira deployment automation reports completion separately.

Security and reliability points

• Target repositories pin the kit version with a full commit SHA.
• Branch-push pipelines are the normal automation path; PR-event handling, when used, must trust destination branch configuration rather than source branch configuration.
• The kit uses allowlist logic for the central kit repository/ref/profile boundary.
• Secret values are stored in Bitbucket Variables, not committed configuration files.
• AI review scans added diff lines for token/password/API key/webhook-like patterns before calling the external model API.
• Docker build success alone is not treated as a test pass unless an explicit test signal or build-only opt-in is present.
• mixed profile fails by default when changed files do not match known component/common/ignored paths.
• Bitbucket branch restrictions and merge checks remain the enforcement layer.

Spec-driven crawler validation

The user confirmed a concrete before/after operating change on 2026-07-22:

• Before a repository-level specification existed, a change made by another

crawler owner could unintentionally alter the produced data format.

• The current workflow uses spec.md as the expected change contract. Profile

tests and AI review read the contract and inspect the implementation diff for format drift and related violations.

• The kit is currently applied and used, but the number of participating repos,

caught issues, and time saved have not been measured.

Public wording should emphasize this qualitative operating evidence instead of inventing an adoption or accuracy metric.

Portfolio framing

Good public wording:

• “CI/CD 개발 완료 루틴 bootstrap kit”
• “중앙 실행형 Bitbucket Pipelines kit”
• “Claude 기반 AI PR 리뷰를 secret scan 이후에 실행”
• “Jira/Bitbucket/Slack/Docker로 이어지는 개발 완료 루틴 자동화”
• “full-SHA pinning, branch-push pipeline, false-green 방지”

Avoid or qualify:

• Do not say it fully automated production deployment; Docker image push and actual deployment completion are separate.
• Do not claim team-wide adoption counts or performance gains without verified numbers.
• Do not expose internal repository URLs, tokens, hostnames, customer names, or variable values in public portfolio pages.