Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 37 additions & 23 deletions skills/sdlc-agentic-pipeline/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -154,14 +154,14 @@ See `references/templates/mcp-settings.json` for the template.
| 0 PM + Frontend/Backend/DevOps Onboarding: auto-provision agents, Opt A (existing repo, PM read-only) or Opt B (new repo, parallel Backend+Frontend build, DevOps configs) |
| 1 PM Requirement breakdown, PRD, batch Jira task creation (hyperlinks to user) |
| 1b Frontend/Backend Requirement review (PARALLEL via Jira async dispatch) |
| 2 PM Sprint start (Jira Agile API) + SDD setup (direct push, no PR) |
| 2 PM + Developer Sprint start (Jira Agile API) + SDD setup (developer agent: docs branch + PR to dev) |
| 3 Frontend/Backend Code dev (PARALLEL via Jira async), Semgrep pre-scan, branching, PR, tests |
| 4 Code Reviewer PR review (batch), secret scanning (batch), GitHub approval |
| 5 Tester + PM + Dev E2E testing + auto-merge feature PRs (5b merged into 5) + CI/CD auto-triggers |
| 6 DevOps CI/CD (auto-triggered, cached) + JFrog verify + SonarCloud QG (combined) |
| 7 PM+Developer Release review (PM: sign-offs+approval) + merge (Developer: PR create+merge, simplified conflict resolution) |
| 8 PM+DevOps Deploy auth (PM: human approval) + execution (DevOps: SSH+docker pull+run) |
| 9 PM+Developer Sprint close, retro, HTML report, direct push to GitHub (no PR) |
| 9 PM+Developer Sprint close, retro, HTML report, docs branch + PR to GitHub |
+---------------------------------------------------------------------------+
```

Expand All @@ -170,8 +170,9 @@ See `references/templates/mcp-settings.json` for the template.
1. **Parallel dispatch via Jira async**: Backend + Frontend agents work simultaneously
(Steps 0, 1b, 3). PM dispatches via Jira comments, both agents pick up independently.
2. **Batch Jira operations**: Bulk create API for tasks (Step 1), batch transitions.
3. **Direct push for docs/reports**: `.opencode/**`, `docs/**`, `reports/**` paths
exempt from PR requirement via GitHub path-based branch protection (Steps 2, 9).
3. **PR-based flow for docs/reports**: `.opencode/**`, `docs/**`, `reports/**` paths
use a docs branch + PR targeting `dev` (GitHub branch protection applies to the whole
branch, not individual paths, so a PR is required even for documentation changes).
Comment thread
coderabbitai[bot] marked this conversation as resolved.
4. **Auto-trigger CI/CD**: `on: push` to `dev` branch. No manual DevOps trigger (Step 5->6).
5. **Cached builds**: pip, node_modules, Docker layers cached in GitHub Actions (Step 6).
6. **Combined CI/CD + verification**: JFrog artifact check + SonarCloud QG
Expand Down Expand Up @@ -361,7 +362,7 @@ summarizing the entire process, operations, and actions taken during the flow.
- GitHub: `https://github.com/{GITHUB_OWNER}/{GITHUB_REPO}`
- PRs: `https://github.com/{GITHUB_OWNER}/{GITHUB_REPO}/pull/{PR_NUMBER}`
- SonarCloud: `https://sonarcloud.io/project/overview?id={SONAR_PROJECT_KEY}`
- JFrog: `https://{JFROG_PLATFORM_URL}/ui/repos/tree/General/{JFROG_REPO_KEY}`
- JFrog: `{JFROG_PLATFORM_URL}/ui/repos/tree/General/{JFROG_REPO_KEY}`
- GitHub Actions: `https://github.com/{GITHUB_OWNER}/{GITHUB_REPO}/actions`
- Contents (single-page scrollable report):
- Header: project name (linked to GitHub repo), sprint name, date range, overall status badge
Expand Down Expand Up @@ -483,24 +484,25 @@ main (production-ready - only released code, deploy from here)
└── docs/sdd-<feature_name>
```

- **`main`**: Production branch. Only updated via `dev` → `main` merge at release time (Step 8).
- **`main`**: Production branch. Only updated via `dev` → `main` merge at release time (Step 7).
Branch protection rules MUST be enabled (no direct pushes).
- **`dev`**: Integration branch. All feature, fix, and docs PRs target `dev` as base.
Multiple feature branches merge here for integration testing before release.
- **Feature/fix/bug/docs branches**: Created from `dev`, merged back to `dev` via PR.

> **Option A (Existing Repo):** The user's existing branch strategy takes precedence.
> During onboarding (Step 0.A.6), the PM Agent asks the user which branch strategy to
> use (existing `develop`, GitFlow `dev`, trunk-based, or custom). Branches are only
> created by developer agents, never by the PM Agent. The pipeline adapts to the
> user's chosen strategy for all PR targets.
> use (existing `develop`, GitFlow `dev`, trunk-based, or custom). The selected branch
> is persisted and passed to all downstream agents (Backend, Frontend, DevOps) for
> CI/CD triggers, feature merges, and release PRs. Branches are only created by
> developer agents, never by the PM Agent.

### Release Merge: `dev` → `main`

At Step 7 (Release Review), after all feature PRs are merged into `dev` and all
gates pass, the PM Agent authorizes and the developer agent (Backend if both active,
otherwise sole developer) creates and merges `dev` into `main` via GitHub MCP.
This is the only way code reaches `main`. Deployment (Step 9) always pulls from `main`.
This is the only way code reaches `main`. Deployment (Step 8) always pulls from `main`.

## Branch Naming Convention

Expand Down Expand Up @@ -594,9 +596,14 @@ The pipeline requires explicit human approval at these points:
> crashes. Requires Project Administrator permissions.
> 2. **Jira direct REST API 401**: Direct calls to `{site}.atlassian.net` with
> Basic auth return 401. Must use the Atlassian API gateway
> (`api.atlassian.com/ex/jira/{cloudUuid}/rest/...`). Discover the cloud UUID
> by calling `atlassian-rovo-mcp_getVisibleJiraProjects` and extracting it
> from the `self` URL in the response.
> (`api.atlassian.com/ex/jira/{cloudUuid}/rest/...`) with the `Authorization`
> header from `.codeartsdoer/mcp/mcp_settings.json`
> (`mcpServers["atlassian-rovo-mcp"].headers.Authorization`). Any other auth
> token will fail. Discover the cloud UUID by calling
> `atlassian-rovo-mcp_getVisibleJiraProjects` and extracting it from the `self`
> URL in the response. On Windows, the CodeArts Bash tool strips `$` from
> inline PowerShell — always write a `.ps1` script file first, then execute
> with `powershell -NoProfile -ExecutionPolicy Bypass -File`.
> 3. **Jira sprint name length**: Must be shorter than 30 characters or the API
> returns 400.
> 4. **Sprint field value type**: `customfield_10020` (Sprint) must be a number,
Expand All @@ -607,6 +614,13 @@ The pipeline requires explicit human approval at these points:
> NOT support partial updates. Sending only `{"state": "closed"}` returns 400.
> Must `GET /sprint/{id}` first to fetch existing `name` and `startDate`, then
> `PUT` with complete body: `{state, name, startDate, endDate, goal}`.
> 6b. **Sprint close must use gateway URL + MCP auth**: Direct site URL
> (`{site}.atlassian.net`) always returns 401. Must use the Atlassian API gateway
> (`https://api.atlassian.com/ex/jira/{cloudUuid}/rest/agile/1.0`) with the
> `Authorization` header from `.codeartsdoer/mcp/mcp_settings.json`
> (`mcpServers["atlassian-rovo-mcp"].headers.Authorization`). On Windows, the
> CodeArts Bash tool strips `$` from inline PowerShell — always write a `.ps1`
> script file first, then execute with `powershell -File`.
> 7. **JFrog Docker repository naming**: Do NOT use underscores in repository names
> (DNS limitation). Use hyphens (e.g., `docker-dev-local` not `docker_dev_local`).
> 8. **JFrog build API requires project param**: `GET /artifactory/api/build/{name}`
Expand All @@ -619,8 +633,8 @@ The pipeline requires explicit human approval at these points:
> must go through a feature/docs branch and PR targeting `dev`. Enable GitHub branch
> protection rules on both `main` and `dev` (Settings > Branches > Branch protection
> rules) to enforce this. `main` is only updated via `dev` → `main` merge at release
> time (Step 7). SDD docs use direct push (no PR needed, path-based branch protection
> gates); code changes require the full PR Merge Gate (5 sign-offs).
> time (Step 7). SDD docs use a docs branch + PR targeting `dev` (GitHub branch protection
> applies to the whole branch, so a PR is required); code changes require the full PR Merge Gate (5 sign-offs).
Comment on lines +636 to +637

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Resolve the MD027 blockquote warning.

These wrapped lines contain multiple spaces immediately after >, which markdownlint flags. Reflow the blockquote so each marker has a single following space while preserving the warning’s list structure.

🧰 Tools
🪛 markdownlint-cli2 (0.23.0)

[warning] 636-636: Multiple spaces after blockquote symbol

(MD027, no-multiple-space-blockquote)


[warning] 637-637: Multiple spaces after blockquote symbol

(MD027, no-multiple-space-blockquote)

🪛 SkillSpector (2.3.11)

[warning] 619: [E1] External Transmission: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Remediation: Verify the destination URL is trusted and necessary. Remove or replace with documented APIs. Ensure no secrets, tokens, or PII are transmitted.

(Data Exfiltration (E1))


[warning] 27: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.

Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content.

(Memory Poisoning (MP2))


[warning] 562: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.

Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content.

(Memory Poisoning (MP2))


[warning] 567: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.

Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content.

(Memory Poisoning (MP2))


[warning] 568: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.

Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content.

(Memory Poisoning (MP2))


[warning] 570: [MP2] Context Window Stuffing: Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.

Remediation: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content.

(Memory Poisoning (MP2))


[error] 216: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.

(Privilege Escalation (PE3))


[error] 144: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.

(Privilege Escalation (PE3))

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@skills/sdlc-agentic-pipeline/SKILL.md` around lines 636 - 637, Reflow the
wrapped blockquote in the Step 7 documentation so every `>` marker is followed
by exactly one space, eliminating the MD027 warning while preserving the
existing text and list structure.

Source: Linters/SAST tools


## Config Templates

Expand Down Expand Up @@ -677,9 +691,9 @@ Ready-to-fill templates are in `references/templates/`:
analysis. Use Semgrep MCP for local scanning.
- CI/CD is **auto-triggered** on push to `dev` (not manual). This ensures
only reviewed, tested code enters the pipeline immediately after merge.
- All SDD documents (`spec.md`, `design.md`, `tasks.md`) are pushed DIRECTLY to GitHub
(no PR needed - `.opencode/**` exempt via path-based branch protection). Developer agent
pushes directly to `dev`.
- All SDD documents (`spec.md`, `design.md`, `tasks.md`) are pushed to GitHub
via a developer agent on a docs branch + PR targeting `dev` (GitHub branch protection
applies to the whole branch, so a PR is required).
Comment thread
coderabbitai[bot] marked this conversation as resolved.
- **Step 5 (E2E + Auto-Merge):** Tester runs E2E, then PM verifies gates +
asks human approval, developer agent merges feature PRs into `dev`. CI/CD
auto-triggers on dev push (no separate Step 5b or manual CI/CD trigger).
Expand All @@ -688,15 +702,15 @@ Ready-to-fill templates are in `references/templates/`:
artifact verification, SonarCloud QG check. DevOps
reads final pipeline status (1 API call instead of 8+ separate verification calls).
- **Step 7 (Release Merge):** PM Agent authorizes (sign-offs + human approval),
developer agent (Backend if both active, otherwise sole developer) creates and merges
the `dev` -> `main` PR via GitHub MCP. Simplified conflict resolution: default
"prefer dev" strategy (4 steps), full domain-owner resolution only if CI/CD fails.
developer agent (Backend if both active, otherwise sole developer) creates and merges
the `dev` -> `main` PR via GitHub MCP. Conflict resolution uses domain-owner strategy
(each agent resolves its own files; do NOT blanket-accept dev for all files).
- **Step 8 (Deployment):** PM Agent authorizes (human approval), DevOps Agent
executes (SSH into Huawei Cloud ECS, docker pull, docker run, health check,
rollback on failure).
- **Step 9 (Report Push):** PM Agent generates HTML report, developer agent
(Backend if both active, otherwise sole developer) pushes DIRECTLY to `dev`
(no PR - `reports/**` exempt via path-based branch protection).
(Backend if both active, otherwise sole developer) creates a docs branch + PR
targeting `dev` and merges it (GitHub branch protection applies to the whole branch).
Comment thread
coderabbitai[bot] marked this conversation as resolved.

## Sharing This Skill

Expand Down
38 changes: 17 additions & 21 deletions skills/sdlc-agentic-pipeline/references/agents/backend-agent.md
Original file line number Diff line number Diff line change
Expand Up @@ -118,10 +118,11 @@ When the Backend Agent is the primary PR operator, it handles:
```
- If the MCP returns a **422** or "already exists" error, report back to the
PM Agent who will ask the user for a different name and retry.
- **Clone the newly created repo** to the local working directory:
- **Clone the newly created repo** to the local working directory (use credential helper — never embed PAT in URL):
```bash
git clone "https://<GITHUB_PAT>@github.com/<GITHUB_OWNER>/<NEW_REPO_NAME>.git"
git clone "https://github.com/<GITHUB_OWNER>/<NEW_REPO_NAME>.git"
```
The GitHub MCP Bearer token is used for authentication via the configured credential helper. Do NOT pass the PAT as a URL parameter — it would be exposed in command history, process arguments, and tool logs.
- Analyze the backend requirements to identify modules, API endpoints, and data models
- Create the complete backend directory structure:
- `backend/app/` - main application code
Expand Down Expand Up @@ -369,16 +370,11 @@ Before merging any feature PR, verify ALL of the following:

### 7.3 Merge Conflict Resolution (Simplified)

If the `dev` -> `main` merge encounters conflicts (simplified - default `prefer dev`):
If the `dev` -> `main` merge encounters conflicts:

1. **Create resolution branch**: `git checkout -b fix/backend/resolve-release-conflict dev`
2. **Merge main into resolution branch**: `git merge main` (conflicts appear)
3. **Accept dev version for ALL conflicts** (dev has latest tested code)
4. **Commit and push resolution**
5. **Run CI/CD on resolution branch** (delegate to DevOps Agent for trigger)
6. **If CI/CD passes** -> create PR to `main` and merge (DONE - 4 steps, not 18)
7. **If CI/CD fails** -> THEN do full domain-owner conflict resolution:
- Classify conflicting files by ownership:
3. **Resolve each conflict by domain ownership** (do NOT blanket-accept dev for all files — main may contain production hotfixes not in dev):
- `backend/**` -> Backend Agent resolves
- `frontend/**` -> Delegate to Frontend Agent via Jira comment
- `docker-compose.yml`, `**/Dockerfile`, `.github/workflows/**` -> Delegate to DevOps Agent via Jira comment
Expand Down Expand Up @@ -416,18 +412,18 @@ If the `dev` -> `main` merge encounters conflicts (simplified - default `prefer
git commit -m "docs: add SDLC process report"
git push origin docs/sdlc-reports
```
4. DIRECT PUSH to `dev` (no PR - `reports/**` exempt via path-based branch protection):
```
github_create_pull_request(
owner="<GITHUB_OWNER>",
repo="<GITHUB_REPO>",
title="docs: SDLC process report",
head="docs/sdlc-reports",
base="dev"
)
```
5. Report commit URL to PM Agent
6. Report PR link to PM Agent: `@agent:pm Report PR created and merged: <PR_URL>`
4. Create PR to `dev` and merge it:
```
github_create_pull_request(
owner="<GITHUB_OWNER>",
repo="<GITHUB_REPO>",
title="docs: SDLC process report",
head="docs/sdlc-reports",
base="dev"
)
```
5. After PR is created, merge it via `github_merge_pull_request`
6. Report commit URL and merged PR link to PM Agent: `@agent:pm Report published and merged: <PR_URL>`

---

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,9 @@ avatar: avatar1
> on throwback.
>
> **Branch strategy:** All PRs target `dev` as the base branch (not `main`).
> The `dev` → `main` merge happens later at Step 7 (Release Review) by the PM Agent.
> The `dev` → `main` merge happens later at Step 7 (Release Review) and is
> performed by the developer agent (Backend if both active, otherwise sole developer).
> The PM Agent does NOT create or merge PRs.

### 4.1 Task Discovery
- Discover review tasks via JQL: `labels = agent:code-reviewer AND status = "In Review"`
Expand Down
Loading