Deterministic, verifiable rules that all SDLC workflow skills must follow. Every rule is pass/fail — not subjective. Each rule traces back to an existing instruction in a SKILL.md or CLAUDE.md file.
| # | Constraint | Source |
|---|---|---|
| 1.1 | plan-feature MUST NOT modify, create, or delete any source code files in any repository. |
plan-feature/SKILL.md — Guardrails |
| 1.2 | plan-feature MUST NOT use Edit, Write, or Bash tools to change files. Only read-only tools (Read, Glob, Grep, Serena search) are permitted. |
plan-feature/SKILL.md — Guardrails |
| 1.3 | plan-feature output goes to Jira (tasks, comments) — never to the filesystem. |
plan-feature/SKILL.md — Guardrails |
| 1.4 | implement-task MUST keep changes scoped to what the task describes — no unrelated refactoring. |
implement-task/SKILL.md — Important Rules |
| 1.5 | implement-task MUST NOT guess code structure — it must inspect code before modifying it using Serena or Read/Grep/Glob. |
implement-task/SKILL.md — Important Rules |
| 1.6 | implement-task MUST ask the user for clarification and stop execution when the structured description is incomplete — it MUST NOT draft an implementation plan or proceed with any subsequent steps until the user responds. |
implement-task/SKILL.md — Important Rules, Step 1 |
| 1.7 | define-feature MUST NOT modify, create, or delete any files in any repository. Only Jira MCP tools are permitted for output. |
define-feature/SKILL.md — Guardrails |
| 1.8 | define-feature MUST NOT fabricate content. All Feature description content must come from user input. |
define-feature/SKILL.md — Guardrails |
| 1.9 | define-feature MUST NOT create a Jira issue without showing a full preview and receiving explicit user approval. |
define-feature/SKILL.md — Important Rules |
| 1.10 | verify-pr MUST read PR reviews and comments to identify code change requests from reviewers. |
verify-pr/SKILL.md — Step 4a (orchestrator) |
| 1.11 | verify-pr MUST NOT modify code. It only verifies, creates sub-tasks, and reports. |
verify-pr/SKILL.md — Important Rules (orchestrator); verify-pr/intent-alignment.md, security.md, correctness.md, style-conventions.md — Constraints (all sub-agents) |
| 1.12 | verify-pr sub-tasks MUST follow the plan-feature task template structure and include Target PR and Review Context sections. |
verify-pr/SKILL.md — Step 4d (orchestrator) |
| 1.13 | verify-pr MUST NOT auto-merge. Merging is always a human decision. |
verify-pr/SKILL.md — Important Rules (orchestrator) |
| 1.14 | verify-pr root-cause tasks MUST target the workflow phase where the gap originated, not always the implementation phase. |
verify-pr/SKILL.md — Step 5b (orchestrator, root-cause) |
| 1.15 | implement-task MUST check out the existing PR branch (instead of creating a new one) when a Target PR section is present in the task description. |
implement-task/SKILL.md — Step 5 (Target PR flow) |
| 1.16 | verify-pr MUST flag repetitive test functions that could be parameterized as a WARN finding, applying the Meszaros heuristic as the decision boundary. |
verify-pr/style-conventions.md — Check 2 (style-conventions sub-agent) |
| 1.17 | verify-pr MUST flag test functions missing doc comments as a WARN finding. |
verify-pr/style-conventions.md — Check 3 (style-conventions sub-agent) |
| 1.18 | verify-pr test change classification sub-agent MUST operate in complete isolation — it MUST NOT receive or access the Jira task description, review comments, PR metadata, or outputs from other verify-pr steps. |
verify-pr/style-conventions.md — Check 4, Step 4b (style-conventions sub-agent) |
| 1.19 | verify-pr MUST classify REDUCTIVE and MIXED test changes as WARN (advisory). Test Change Classification MUST NOT elevate the overall result to FAIL. |
verify-pr/style-conventions.md — Check 4, Verdict (style-conventions sub-agent); verify-pr/SKILL.md — Step 14 (orchestrator) |
| 1.20 | verify-pr MUST classify new test files (not on base branch) as additive without sub-agent analysis. |
verify-pr/style-conventions.md — Check 4, Step 4a (style-conventions sub-agent) |
| 1.21 | verify-pr test change classification semantic assessment MUST override structural signals when they disagree. |
verify-pr/style-conventions.md — Check 4, Step 4d (style-conventions sub-agent) |
| 1.22 | verify-pr domain sub-agents MUST NOT perform Jira mutations (create sub-tasks, post comments, transition issues). |
verify-pr/SKILL.md — Important Rules (orchestrator); verify-pr/intent-alignment.md, security.md, correctness.md, style-conventions.md — Constraints |
| 1.23 | verify-pr domain sub-agents MUST NOT post PR comments or replies. |
verify-pr/SKILL.md — Important Rules (orchestrator); verify-pr/intent-alignment.md, security.md, correctness.md, style-conventions.md — Constraints |
| 1.24 | verify-pr domain sub-agents MUST return responses using the structured finding template (finding-template.md). |
verify-pr/intent-alignment.md, security.md, correctness.md, style-conventions.md — Output Format |
| 1.25 | verify-pr orchestrator MUST dispatch domain sub-agents in parallel. |
verify-pr/SKILL.md — Step 4d (Dispatch), Important Rules (orchestrator) |
| 1.26 | verify-pr root-cause investigation MUST receive aggregated findings from all domain sub-agents with source attribution. |
verify-pr/SKILL.md — Step 5 (orchestrator), Important Rules |
| 1.27 | plan-feature MUST determine the workflow mode (direct-to-main or feature-branch) during planning and record the decision on the feature issue. |
plan-feature/SKILL.md — Step 4.5 (Determine Workflow Mode) |
| 1.28 | verify-pr MUST detect eval result reviews in PR conversations by matching all three criteria: author is github-actions[bot], body contains ## Eval Results marker, and body contains sdlc-workflow/run-evals footer. |
verify-pr/SKILL.md — Step 4a.1 |
| 1.29 | verify-pr eval result detection MUST NOT produce false positives — non-eval reviews (human reviews, other bot comments) MUST NOT be identified as eval results. |
verify-pr/SKILL.md — Step 4a.1 (NFR 2) |
| 1.30 | verify-pr Test Quality verdict MUST incorporate eval results: PASS when all evals pass and no traditional test issues, WARN when any eval assertions fail, N/A only when neither traditional tests nor eval results are present. |
verify-pr/SKILL.md — Step 6a; verify-pr/style-conventions.md — Check 5 |
| 1.31 | verify-pr MUST autonomously create sub-tasks for eval assertion failures with labels ["ai-generated-jira", "eval-failure"], grouped by eval ID. |
verify-pr/SKILL.md — Step 6d |
| 1.32 | verify-pr eval failure sub-tasks MUST enter the existing root-cause investigation pipeline (Step 7). |
verify-pr/SKILL.md — Step 7 |
| 1.33 | plan-feature MUST post a description digest comment after creating each task per shared/description-digest-protocol.md. |
plan-feature/SKILL.md — Step 6a |
| 1.34 | implement-task MUST verify the description digest before proceeding and pause if a mismatch is detected. |
implement-task/SKILL.md — Step 1.5 |
| 1.35 | implement-task MUST skip digest verification with a warning when no digest comment exists (backward compatibility). |
implement-task/SKILL.md — Step 1.5 |
| 1.36 | verify-pr convention upgrade MUST validate convention file-type applicability per shared/convention-applicability-rules.md before upgrading a suggestion. |
verify-pr/style-conventions.md — Check 1 |
| 1.37 | triage-security MUST NOT modify, create, or delete any source code files — read-only source access only. |
triage-security/SKILL.md — Guardrails |
| 1.38 | triage-security MUST NOT perform any Jira mutation without explicit engineer confirmation. |
triage-security/SKILL.md — Guardrails, Important Rules §11 |
| 1.39 | triage-security MUST check ALL supported versions in the security-matrix.md, not just the version named in the issue. |
triage-security/SKILL.md — Important Rules §4 |
| 1.40 | triage-security MUST NOT assume PSIRT-assigned Affects Versions are correct — must verify against lock file evidence. |
triage-security/SKILL.md — Important Rules §3 |
| 1.41 | triage-security MUST use git show against pinned commits from security-matrix.md, not HEAD or branch tips, for released versions. |
triage-security/SKILL.md — Important Rules §13 |
| 1.42 | triage-security MUST detect and analyze the current development stream (unreleased Jira versions). |
triage-security/SKILL.md — Step 2.2, Important Rules §10 |
| 1.43 | triage-security MUST NOT create Vulnerability issues — PSIRT owns Vulnerability creation. The skill only creates remediation Tasks. Cross-stream impact is reported via comment. |
triage-security/SKILL.md — Important Rules §7, Step 8 |
| 1.44 | triage-security MUST present version impact table to engineer before making triage decisions. |
triage-security/SKILL.md — Step 2.4 |
| 1.45 | triage-security MUST skip retag versions (identical digest) and note them in the impact table. |
triage-security/SKILL.md — Important Rules §5 |
| 1.46 | triage-security remediation tasks MUST follow the task-description-template.md format. |
triage-security/SKILL.md — Important Rules §9, Remediation Task Creation |
| 1.47 | triage-security output goes to Jira only, with one exception: it may write to local security-matrix.md files in the project working directory for supportability matrix population. |
triage-security/SKILL.md — Guardrails, Step 2.1 |
| 1.48 | triage-security MUST read ecosystems, lock file paths, and check commands from security-matrix.md Ecosystem Mappings — MUST NOT hardcode language-specific logic. |
triage-security/SKILL.md — Step 1 (Ecosystem detection), Step 2.3 |
| 1.49 | triage-security MUST read the Component label pattern from Security Configuration — MUST NOT hardcode label prefixes. |
triage-security/SKILL.md — Step 0, Step 1 (Data Extraction) |
| 1.50 | report-bug MUST NOT modify, create, or delete any files in any repository. Only Jira MCP tools are permitted for output. |
report-bug/SKILL.md — Guardrails |
| 1.51 | report-bug MUST NOT fabricate content. All Bug description content must come from user input or structured input from calling skills. |
report-bug/SKILL.md — Guardrails |
| 1.52 | report-bug MUST NOT create a Jira issue without showing a full preview and receiving explicit user approval. |
report-bug/SKILL.md — Step 4 (Preview and Confirm) |
| 1.53 | triage-bug MUST NOT modify, create, or delete any source code files in any repository. Only read-only tools (Read, Glob, Grep, Serena search) are permitted for codebase investigation. |
triage-bug/SKILL.md — Guardrails |
| 1.54 | triage-bug output goes to Jira (tasks, comments, links) — never to the filesystem. |
triage-bug/SKILL.md — Guardrails |
| 1.55 | triage-bug MUST front-load the reproducer test as the first acceptance criterion and first test requirement in generated Tasks. |
triage-bug/SKILL.md — Step 5 (Front-load the reproducer test) |
| 1.56 | triage-bug MUST post a root cause analysis comment on the Bug issue before creating the fix Task. |
triage-bug/SKILL.md — Step 4 (Post root cause comment) |
| 1.57 | triage-bug MUST flag multi-root-cause bugs for decomposition rather than silently creating a single Task that bundles unrelated fixes. |
triage-bug/SKILL.md — Step 6 (Decomposition Guard) |
| 1.58 | triage-security MUST check existing issuelinks before creating sibling "Related" links — MUST NOT create a link if one already exists between the two issues. |
triage-security/jira-triage-operations.md — Step 4.2 |
| 1.59 | triage-security MUST search for related CVE Jiras by Upstream Affected Component (customfield_10632) in Step 4.3 and check existing remediation tasks before creating new ones. |
triage-security/jira-triage-operations.md — Step 4.3 |
| 1.60 | verify-pr MUST compare eval assertion failures against base branch eval baselines before creating subtasks — only regressions (assertions that pass at baseline but fail on the PR) trigger subtask creation. |
verify-pr/SKILL.md — Step 6d (Eval failure sub-tasks), verify-pr/style-conventions.md — Check 5 |
| 1.61 | triage-security MUST create proactive remediation tasks with security-preemptive label for affected streams without CVE Jiras (Step 8 Case B) and MUST reconcile when stream-specific CVE Jiras arrive by linking the CVE and removing the label (Step 4.4). |
triage-security/SKILL.md — Step 8 Case B, triage-security/jira-triage-operations.md — Step 4.4 |
| 1.62 | plan-feature MUST discover issue types dynamically from the Jira project, not hardcode type names or IDs. |
plan-feature/SKILL.md — Step 2.5 |
| 1.63 | plan-feature MUST map issue types to hierarchy roles by hierarchyLevel field, not by type name. |
plan-feature/SKILL.md — Step 2.5 |
| 1.64 | plan-feature MUST fall back to Feature → Task hierarchy when no level-1 type exists, without error. |
plan-feature/SKILL.md — Step 2.5 |
| 1.65 | triage-security MUST query MITRE CVE API and OSV.dev for structured version ranges in Step 1.5 and use them as the primary fix threshold source when available, falling back to Jira description data only when external APIs are unavailable. |
triage-security/SKILL.md — Step 1.5, triage-security/version-impact-analysis.md — Step 2.3 |
| 1.66 | triage-security MUST post a description digest comment on each remediation task immediately after creation per shared/description-digest-protocol.md, before creating issue links or other comments. |
triage-security/SKILL.md — Remediation Task Creation, triage-security/remediation-templates.md — Jira Issue Creation |
| 1.67 | triage-security MUST @mention the vulnerability issue's reporter in the Step 8 summary comment by default (no configuration required — uses the reporter field from the Jira issue). |
triage-security/SKILL.md — Post-Triage Summary |
| 1.68 | triage-security MUST @mention the configured ProdSec Jira account in Affects Versions correction (Step 3) and cross-CVE overlap (Step 4.3) comments when a ProdSec Jira account ID is present in Security Configuration, and MUST skip the mention silently when not configured. |
triage-security/SKILL.md — Step 0, triage-security/jira-triage-operations.md — Steps 3, 4.3 |
| 1.69 | triage-security discovery mode MUST run a third JQL query for triaged CVEs in pre-QA states, check linked remediation Task completion via "Depend" links, and present only issues with ALL Tasks Done/Closed as "Ready for QA" candidates with an ON_QA transition suggestion. |
triage-security/SKILL.md — Discovery mode |
| 1.70 | triage-security MUST present an embargo warning gate to the engineer after Step 1.5 when an Embargo policy URL is configured and the CVE severity is Critical or Important (CVSS >= 7.0), requiring explicit confirmation before proceeding. |
triage-security/SKILL.md — Step 1.7 |
| 1.71 | triage-security MUST skip the embargo warning gate silently when no Embargo policy URL is configured in Security Configuration (backward compatibility). |
triage-security/SKILL.md — Step 1.7 |
| 1.72 | define-feature MUST present priority and fixVersion as optional prompts that can be skipped. |
define-feature/SKILL.md — Step 3.5 |
| 1.73 | define-feature MUST NOT set priority or fixVersion on the created issue when the user skips the prompt. |
define-feature/SKILL.md — Step 6.2 |
| 1.74 | plan-feature MUST inherit priority and fixVersions from the parent Feature issue when set. |
plan-feature/SKILL.md — Step 1, Step 6 |
| 1.75 | plan-feature MUST respect fixVersion scope from Jira Field Defaults configuration — only propagating fixVersions to tasks when the scope includes "task" or "both". |
plan-feature/SKILL.md — Step 6 |
| 1.76 | plan-feature MUST NOT set priority on created tasks when the parent Feature has priority "Undefined" or unset. |
plan-feature/SKILL.md — Step 1, Step 6 |
| 1.77 | triage-security MUST extract the Deployment Context column from the Source Repositories table in Security Configuration and use it to annotate remediation task descriptions with context-appropriate coordination guidance (internal, upstream, or customer-shipped). |
triage-security/SKILL.md — Step 0, triage-security/remediation-templates.md — Coordination Guidance |
| 1.78 | triage-security MUST default all repositories to upstream deployment context when the Deployment Context column is absent from the Source Repositories table (backward compatibility). |
triage-security/SKILL.md — Step 0 |
| 1.79 | plan-feature MUST create Epics between Feature and Tasks when a level-1 issue type is discovered in Step 2.5. |
plan-feature/SKILL.md — Step 6, sub-step 6a.0 |
| 1.80 | plan-feature MUST fall back to Feature → Task hierarchy when no level-1 type exists, without error or user prompting. |
plan-feature/SKILL.md — Step 6, graceful degradation |
| 1.81 | plan-feature Epic grouping strategy MUST be configurable via interactive prompt or CLAUDE.md Hierarchy Configuration. |
plan-feature/SKILL.md — Step 5 |
| 1.82 | plan-feature parent issue linking MUST validate that the parent issue's hierarchyLevel is higher than the Feature's hierarchyLevel before setting the link. |
plan-feature/SKILL.md — Step 1.5 |
| 1.83 | plan-feature MUST generate a documentation task when the Feature description's "Documentation Considerations" section indicates doc impact (New Content, Updates, or Release Notes). |
plan-feature/SKILL.md — Step 5 (Documentation task generation) |
| 1.84 | plan-feature MUST NOT generate a documentation task when the Feature description has no "Documentation Considerations" section or states "No Doc Impact". |
plan-feature/SKILL.md — Step 5 (Documentation task generation) |
| 1.85 | plan-feature MUST generate testing tasks when a testing readiness template exists at docs/testing-readiness.md in the target repository, with one task per test category in the template. |
plan-feature/SKILL.md — Step 5 (Testing task generation) |
| 1.86 | plan-feature MUST NOT generate testing tasks when no testing readiness template exists in the target repository. |
plan-feature/SKILL.md — Step 5 (Testing task generation) |
| 1.87 | plan-feature testing tasks MUST depend on all implementation tasks. |
plan-feature/SKILL.md — Step 5 (Testing task generation) |
Implements the zero-trust inter-agent principle from fullsend's security-threat-model.md §Zero Trust Between Agents as a content-level detection mechanism. Fullsend handles stale workflow state preventively (clearing labels between phases — architecture.md §Stale State Clearing); this constraint addresses stale data content detectively (comparing hashes). The temporal split-payload attack pattern (security-threat-model.md §Temporal Split-Payload) further motivates cross-phase integrity verification.
Net-new; no fullsend counterpart. Fullsend's closest concept — independent tier classification by review agents (intent-representation.md §Independent Tier Classification) — addresses scope assessment, not file-type applicability of convention guidance. This constraint addresses a gap specific to sdlc-plugins' CONVENTIONS.md-driven convention application.
| # | Constraint | Source |
|---|---|---|
| 2.1 | Every commit MUST reference a Jira issue ID in the footer (e.g., Implements TC-123). |
implement-task/SKILL.md — Step 9; methodology.md — Traceable Implementation |
| 2.2 | Commit messages MUST follow the Conventional Commits specification (<type>[optional scope]: <description>). |
implement-task/SKILL.md — Step 9 |
| 2.3 | Every commit MUST include --trailer="Assisted-by: Claude Code" to attribute AI assistance. |
implement-task/SKILL.md — Step 9 |
| # | Constraint | Source |
|---|---|---|
| 3.1 | The feature branch MUST be named after the Jira issue ID (e.g., TC-123). |
implement-task/SKILL.md — Step 5 |
| 3.2 | After opening a PR, its link MUST be posted as a comment on the Jira task. | implement-task/SKILL.md — Step 10; methodology.md — Pull Request Workflow |
| 3.3 | gh pr create MUST always specify --base <target-branch> matching the task's Target Branch value. |
implement-task/SKILL.md — Step 10 (Default flow) |
| 3.4 | Feature branches MUST be named after the feature issue ID (e.g., TC-4418), not the task issue ID. |
implement-task/SKILL.md — Step 5 (Create-branch bookend flow); plan-feature/SKILL.md — Step 5 (Bookend task generation) |
| # | Constraint | Source |
|---|---|---|
| 4.1 | Every generated task description MUST include a Repository section (single repository per task). | plan-feature/SKILL.md — Task Description Template |
| 4.2 | Every generated task description MUST include a Description section. | plan-feature/SKILL.md — Task Description Template |
| 4.3 | Every generated task description MUST include an Acceptance Criteria section. | plan-feature/SKILL.md — Task Description Template |
| 4.4 | Every generated task description MUST include a Test Requirements section. | plan-feature/SKILL.md — Task Description Template |
| 4.5 | Sections that do not apply (e.g., API Changes for a pure UI task, Documentation Updates when no docs are impacted) MUST be omitted rather than left empty. | plan-feature/SKILL.md — Template rules |
| 4.6 | File paths in tasks MUST be real paths discovered during repository analysis, not guessed. | plan-feature/SKILL.md — Template rules |
| 4.7 | Implementation Notes MUST reference existing patterns found in the code, not abstract guidance. | plan-feature/SKILL.md — Template rules |
| 4.8 | Every task created in Jira MUST include the ai-generated-jira label. |
plan-feature/SKILL.md — Step 6a |
| 4.9 | Tasks that change public APIs, configuration, setup steps, or architectural patterns SHOULD include an optional Documentation Updates section listing which docs need updating and what content to add or revise. | plan-feature/SKILL.md — Template rules |
| 4.10 | Tasks SHOULD include a Reuse Candidates section when overlapping code (domain logic, components, utilities, or patterns) was found during repository analysis, listing file paths, symbol names, and relevance descriptions. | plan-feature/SKILL.md — Task Description Template |
| 4.11 | When a task's scope matches a convention from CONVENTIONS.md (e.g., migrations with FK columns requiring indexes), the Implementation Notes MUST include explicit guidance referencing the convention by section name with a concrete example file. | plan-feature/SKILL.md — Step 5 (Convention-aware task enrichment) |
| 4.12 | Every generated task description MUST include a Target Branch section. The value is main for direct-to-main mode, or the feature issue ID for feature-branch mode intermediate tasks. |
plan-feature/SKILL.md — Step 5 (Target Branch assignment); task-description-template.md — Rules |
| 4.13 | plan-feature convention-aware enrichment MUST validate convention file-type applicability per shared/convention-applicability-rules.md before including a convention in Implementation Notes. |
plan-feature/SKILL.md — Step 5 |
Net-new; no fullsend counterpart. Fullsend's closest concept — independent tier classification by review agents (intent-representation.md §Independent Tier Classification) — addresses scope assessment, not file-type applicability of convention guidance. This constraint addresses a gap specific to sdlc-plugins' CONVENTIONS.md-driven convention application.
| # | Constraint | Source |
|---|---|---|
| 5.1 | Changes MUST be scoped to the files listed in Files to Modify and Files to Create — no unrelated files. | implement-task/SKILL.md — Step 6, Important Rules |
| 5.2 | Code MUST NOT be modified without first inspecting it (via Serena or Read/Grep/Glob). | implement-task/SKILL.md — Step 4, Important Rules |
| 5.3 | Implementation MUST follow the patterns referenced in the task's Implementation Notes. | implement-task/SKILL.md — Important Rules |
| 5.4 | Code MUST NOT duplicate existing functionality — reuse or extend existing utilities, helpers, and shared modules when equivalent logic exists. | implement-task/SKILL.md — Step 4, Step 6, Step 9 |
| 5.5 | AI MUST NOT start work autonomously — a human must trigger it. | methodology.md — Core Principles (Human Driven Workflow) |
| 5.6 | After implementation, each new feature MUST be traced through its complete data-flow lifecycle (input → processing → output) — incomplete paths must be fixed before committing. | implement-task/SKILL.md — Step 9 |
| 5.7 | Modified or created code that implements an interface, trait, or type contract MUST have all required methods, properties, and type signatures verified as complete before committing. | implement-task/SKILL.md — Step 9 |
| 5.8 | Modified or created code MUST be compared against sibling implementations for parity on cross-cutting concerns (capabilities, error handling, logging, configuration) — gaps must be fixed or explicitly approved by the user before committing. | implement-task/SKILL.md — Step 9 |
| 5.9 | implement-task SHOULD prefer parameterized tests when multiple test cases exercise the same behavior with different inputs, applying the Meszaros heuristic as the decision boundary. | implement-task/SKILL.md — Step 7 |
| 5.10 | implement-task MUST NOT introduce parameterized test patterns if sibling test analysis shows the project does not use them. | implement-task/SKILL.md — Step 7 |
| 5.11 | implement-task MUST add a doc comment to every test function it creates, regardless of sibling test documentation patterns. |
implement-task/SKILL.md — Step 7 |
| 5.12 | implement-task MUST add given-when-then inline comments to non-trivial test functions (tests with distinct setup, action, and assertion phases). |
implement-task/SKILL.md — Step 7 |
| 5.13 | implement-task MUST NOT add given-when-then comments to trivial tests (single assertion, no distinct setup phase). |
implement-task/SKILL.md — Step 7 |
Each constraint above references its source. The full source files are:
plugins/sdlc-workflow/skills/plan-feature/SKILL.md— Guardrails (§1.1–1.3), Step 1 Priority/fixVersion extraction (§1.74, §1.76), Step 1.5 Parent linking (§1.82), Step 2.5 Discover Project Issue Types (§1.62–1.64), Step 4.5 Determine Workflow Mode (§1.27), Step 5 Epic grouping (§1.79, §1.81), Step 5 Convention-aware task enrichment (§4.11, §4.13), Step 5 Target Branch assignment (§4.12), Step 5 Bookend task generation (§3.4), Step 5 Documentation task generation (§1.83, §1.84), Step 5 Testing task generation (§1.85–1.87), Step 6 sub-step 6a.0 Epic creation (§1.79), Step 6 graceful degradation (§1.80), Step 6 Priority/fixVersion inheritance (§1.74, §1.75, §1.76), Step 6a Digest posting (§1.33), Task Description Template (§4.1–4.10)plugins/sdlc-workflow/skills/implement-task/SKILL.md— Important Rules (§1.4–1.6, §5.1–5.3), Step 1 (§1.6), Step 1.5 Digest verification (§1.34, §1.35), Step 4/6/9 (§5.4), Step 5 (§1.15, §3.1, §3.4), Step 7 (§5.9–5.13), Step 9 (§2.1–2.3, §5.6–5.8), Step 10 (§3.2, §3.3)plugins/sdlc-workflow/shared/task-description-template.md— Rules (§4.12)plugins/sdlc-workflow/shared/description-digest-protocol.md— Digest format and verification procedure (§1.33, §1.34, §1.35)plugins/sdlc-workflow/shared/convention-applicability-rules.md— File-type applicability matching logic (§1.36, §4.13)plugins/sdlc-workflow/skills/verify-pr/SKILL.md— Step 4a (§1.10), Step 4a.1 (§1.28, §1.29), Step 4d (§1.12, §1.25), Important Rules (§1.11, §1.13, §1.22, §1.23, §1.25, §1.26), Step 5b (§1.14), Step 5 (§1.26), Step 6a (§1.30), Step 6d (§1.31, §1.60), Step 7 (§1.32), Step 14 (§1.19)plugins/sdlc-workflow/skills/verify-pr/intent-alignment.md— Constraints (§1.11, §1.22, §1.23), Output Format (§1.24)plugins/sdlc-workflow/skills/verify-pr/security.md— Constraints (§1.11, §1.22, §1.23), Output Format (§1.24)plugins/sdlc-workflow/skills/verify-pr/correctness.md— Constraints (§1.11, §1.22, §1.23), Output Format (§1.24)plugins/sdlc-workflow/skills/verify-pr/style-conventions.md— Check 1 Convention applicability (§1.36), Check 2 (§1.16), Check 3 (§1.17), Check 4 (§1.18, §1.19, §1.20, §1.21), Check 5 (§1.30, §1.60), Constraints (§1.11, §1.22, §1.23), Output Format (§1.24)plugins/sdlc-workflow/skills/define-feature/SKILL.md— Guardrails (§1.7–1.8), Important Rules (§1.9), Step 3.5 Select Priority and Fix Version (§1.72), Step 6.2 Create Feature Issue (§1.73)plugins/sdlc-workflow/skills/report-bug/SKILL.md— Guardrails (§1.50–1.51), Step 4 Preview and Confirm (§1.52)plugins/sdlc-workflow/skills/triage-bug/SKILL.md— Guardrails (§1.53–1.54), Step 5 Front-load reproducer test (§1.55), Step 4 Post root cause comment (§1.56), Step 6 Decomposition Guard (§1.57)plugins/sdlc-workflow/skills/triage-security/SKILL.md— Guardrails (§1.37, §1.38, §1.47), Step 0 (§1.49, §1.68), Step 0 Deployment Context (§1.77, §1.78), Step 1 Ecosystem detection (§1.48), Step 1 Data Extraction (§1.49), Step 1.5 External CVE Data Enrichment (§1.62), Step 1.7 Embargo Check (§1.70, §1.71), Discovery mode (§1.69), Step 2.1 (§1.47), Step 2.2 (§1.42), Step 2.3 (§1.48), Step 2.4 (§1.44), Step 8 (§1.43), Step 8 Case B (§1.61), Post-Triage Summary (§1.67), Important Rules (§1.38–§1.43, §1.45, §1.46), Remediation Task Creation (§1.46, §1.66)plugins/sdlc-workflow/skills/triage-security/version-impact-analysis.md— Step 2.3 enriched fix threshold (§1.62)plugins/sdlc-workflow/skills/triage-security/remediation-templates.md— Jira Issue Creation digest comment (§1.66)plugins/sdlc-workflow/skills/triage-security/jira-triage-operations.md— Step 3 ProdSec @mention (§1.68), Step 4.2 Idempotent sibling linking (§1.58), Step 4.3 Cross-CVE overlap detection (§1.59), Step 4.3 ProdSec @mention (§1.68), Step 4.4 Proactive reconciliation (§1.61)docs/methodology.md— Core Principles (§2.1, §3.2, §5.5)