| Change |
One unit of work going round the loop. Identified by a folder name like 2026-06-02-claims-status-self-service under sdlc/changes/. |
| intent.md |
Stage 1 file. The problem, the desired outcome, who is affected, constraints, out of scope, open questions. Written with Claude in the originator’s own words. Accepted by the product owner. |
| spec.md |
Stage 2 file. Requirements and design produced by Claude from the accepted intent, under the organisation’s policy skills. Starts with Flagged concerns. Accepted by the product owner (and a tech lead if high risk). |
| plan.md |
Stage 3 file. Files that change, order of work, risks, options not taken, proof. Produced in plan mode with the engineer, who accepts it before any code is written. |
| Accepted |
A human decision recorded in the repository: the file’s status: is set to accepted and the pull request is merged. Claude never sets it. |
| Gate |
A point where a named person decides: accept an intent, accept a spec, accept a plan, approve a PR, authorise production, triage an incident. |
| Hook |
A small script that runs automatically before or after Claude acts and can allow, ask, or block. Hooks enforce protected paths, keep secrets out, freeze tests during a bug fix, keep plan.md in sync, and gate production. |
| Skill |
A short instruction file Claude loads when relevant. Commands like /sdlc:intent are skills; policies (security, compliance, brand, UX) are skills too. Advisory: they make Claude apply the policy; a hook makes violation impossible. |
| Subagent |
A helper Claude runs with a fresh memory and limited tools, e.g. the verifier that checks a change works without having written it. |
| Plan mode |
A Claude Code mode in which Claude can read the codebase but cannot change files until the engineer accepts the plan. |
| Flagged concern |
A row at the top of spec.md where a policy conflicts with the intent or another policy. Claude flags; the product owner resolves it with the named policy owner. |
| Risk: routine / high |
Frontmatter field. High = money movement, authentication, personal data, regulated data, infrastructure or migrations. High-risk artifacts need a tech lead’s approval too. |
| Code owner |
The human whose approval a pull request needs (branch protection). Claude’s review informs this person; it does not replace them. |
| REVIEW.md |
The review policy Claude applies to every pull request: passes (bugs, security, compliance), what counts as Important vs a Nit, what to skip. Owned by the tech lead. |
| CLAUDE.md |
One page per repository telling Claude what a new joiner needs: commands, conventions, architecture, mistakes to avoid. Owned by the team. |
| Eval |
A regression test for Claude’s configuration (CLAUDE.md, skills, hooks, REVIEW.md): a realistic prompt plus deterministic checks. Every production incident becomes one. |
| Control band |
A statistical band around a metric’s normal behaviour. A deterministic script watches it; at 2σ Claude diagnoses read-only, at 3σ it may open a PR or trigger an approved runbook. |
| Release authorization |
The named release manager’s approval, present as RELEASE_APPROVAL and as the CI environment approval. Without it, production commands are blocked. |
| Source of truth |
For each artifact, which system is authoritative: the repository (repo), the tracker such as Jira or YouTrack (tracker), or both cross-linked (linked). |
| MCP connector |
A connection that lets Claude read from and write to another system (GitHub, GitLab, Jira, YouTrack, RingCentral, Figma, Sentry, Grafana) with your permissions. |
| sdlc.config.json |
The one configuration file per repository: commands, protected paths, environments, tracker, chat, monitoring. Owned by the platform team. |
.sdlc/ |
Local, uncommitted markers: the active change, the fix lock, the gate log. |