adk-adlc

Complete bug-fix workflow - gather symptoms, attempt to reproduce, wait for user confirmation before fixing, implement/fix in a loop until quality is met, then report, capture knowledge, and produce a postmortem. Fully technology-agnostic - invokes whichever technical skills the task needs. Works for any project or stack.

Connects Claude Code to the project's code host - GitHub or GitLab - through the vendor's MCP server, and defines the code-host operations the kit's SDLC uses (read a pull/merge request and its diff, post a review finding on a line, keep one summary comment up to date, find or open a pull/merge request) with each provider's tool for each. Use when the user asks to connect GitHub or GitLab, set up the GitHub or GitLab MCP server, or make the kit work with their code host; and read by other skills (independent-review, project-setup) before they touch a pull or merge request. Not for databases (toolbox-connections) or for writing a new MCP server (mcp-developer).

Objective code-review checklist to run before reporting work complete - general conventions, clean-code, plus a per-technology checklist for whatever was actually used. This is the SELF-CHECK step Claude ALWAYS proactively runs as the last step before reporting done on any change involving code - no separate user request needed. Do NOT use this when the user actively requests a diff/PR review ("review this", "/code-review") - use the built-in `code-review`/`review` skill for that case.

End-to-end workflow for building a new feature - requirements analysis, solution proposal, implement/test/fix loop until quality bar is met, then reporting and knowledge capture. Fully technology-agnostic - invokes whichever technical skills the task needs. Works for any project or stack.

Reviews a pull request or branch diff as an INDEPENDENT reviewer - a session that did not write the code - against the change's own intent and plan (`docs/intents/`, `docs/plans/`), for correctness using `code-review-skill`'s checklist, and ends with a risk summary for the human who approves. Read-only - never edits, pushes, or approves. Runs in CI through this kit's review pipeline (GitHub Actions or GitLab CI, `ci/review.sh`), or locally when the user explicitly asks for an independent review or a check of a PR/branch against its intent or plan. Do NOT use as the self-check at the end of your own change - that is `code-review-skill`; and not for a generic "review this" with no independence or intent angle - the built-in `code-review` covers that.

Captures an idea, problem, or request that is NOT yet being built as a version-controlled `docs/intents/<slug>.md` - the problem, who it hurts and the evidence, the desired outcome and how success would be observed, non-goals, affected systems, constraints, open questions - with no solution design and no code. Use when the user has an idea, a pain point, user complaints, or an alert/incident worth following up, or says "capture/record/write up this idea", "write an intent", "add this to the backlog", "we should...", "what if we..."; also to review the intent backlog or record a decision on one ("what intents are open", "accept/reject intent X"). Do NOT use when the user wants the change built now - that goes to `workflow-router`, which takes an existing intent as its input; and not for a document arguing an already-chosen technical approach to approvers - that is `technical-proposal-writer`.

Sets up a project repository for this kit and the AI-native SDLC in one pass - a one-page CLAUDE.md built from the repo's real commands and layout, a REVIEW.md the independent reviewer reads, a CODEOWNERS for the policy files, a committed .claude/settings.json (secret-file deny rules, lockfile protection, the kit enabled for every teammate), a quality-check config whose skill_map matches the stack and whose checks run the project's own linters and rules on every file Claude writes, the code host's MCP server in .mcp.json, and the independent-review CI job for GitHub Actions or GitLab CI. Detects what exists first, shows the plan, never overwrites - existing files only receive additions. Use when the user asks to set up, bootstrap, onboard, or "install the kit into" a project, or to add the playbook files (CLAUDE.md, REVIEW.md, CODEOWNERS, settings) to a repo. Not for configuring Claude Code's own personal settings (that is update-config) and not for writing application code.

The fast path for a small, local code change with one obvious form - a typo or message fix, a rename inside one module, a small bug whose fix is plain, a config value, a test to add - done directly with the machine checks still on (owning skill read, the project's convention checks, tests run, self-review), and no analyst, architect, plan document or Checkpoint. workflow-router sends a change here only when it meets every entry criterion, and a Stop hook sends it back when the diff outgrows them. Not for anything with a decision in it, a public contract, a schema or migration, security, auth, money, a new dependency, or more than a few files - those go to feature-development, bug-fix or refactor.

Code-refactoring workflow - improve structure/performance/maintainability WITHOUT changing external behavior (API responses, side effects, output must stay 100% identical). Use when the request is to clean up/restructure/improve code quality, not to add a new feature or fix wrong behavior. Fully technology-agnostic - invokes whichever technical skills the task needs.

Keeps a personal profile of how the user works - how they weigh tradeoffs, design, write code, review and want to be worked with - learned from their corrections, Checkpoint choices, rewrites of agent-written code and review comments, and loaded into every session from their own private repository. Sets the profile up on a machine, notes a signal as it happens, and consolidates signals into profile changes the user approves one by one. Use when the user says "reflect", "learn from this", "remember that I prefer...", "what do you know about how I work", "set up my profile", or after a workflow's knowledge capture when new signals are waiting. Not for a project's conventions (CLAUDE.md, REVIEW.md and checks - the workflows' learning loop owns those) and never for anything outside work style.

Generates test files, creates mocking strategies, analyzes code coverage, designs test architectures, and produces test plans and defect reports across functional, performance, and security testing disciplines. Use when writing unit tests, integration tests, or E2E tests; creating test strategies or automation frameworks; analyzing coverage gaps; performance testing with k6 or Artillery; security testing with OWASP methods; setting up Testcontainers for integration tests (container lifecycle, wait strategies, CI); debugging flaky tests; or working on QA, regression, test automation, quality gates, shift-left testing, or test maintenance.

Use FIRST for any request asking Claude to WRITE OR CHANGE code - new feature, bug fix, refactor, enhancement, "improve", "add capability", etc. Classifies the request as feature-development, bug-fix, or refactor by its true nature (does external behavior change, and if so is it fixing a defect or adding/changing capability?), asking the user only if genuinely ambiguous, and picks the depth the change deserves - quick-change for a small change with nothing to decide, light or full process otherwise - then hands off. Skip when the request type is already obvious. Also the entry point for "implement/build/fix docs/intents/<slug>.md". Do NOT use for no-code-change requests - pure questions/explanations, read-only exploration, or explicit review requests ("review this PR/diff") - handle those directly instead; and not for recording an idea to build later - that is `intent-capture`.