create-agentic-pdlc 2.3.0 → 3.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (64) hide show
  1. package/.agentic-pdlc/hooks/pdlc-stage-gate.sh +37 -10
  2. package/.agentic-pdlc/metrics/raw/2026-W22.jsonl +114 -0
  3. package/.claude/settings.json +18 -0
  4. package/.coderabbit.yaml +35 -0
  5. package/.github/ISSUE_TEMPLATE/bug.md +53 -0
  6. package/.github/ISSUE_TEMPLATE/feature.md +54 -0
  7. package/.github/ISSUE_TEMPLATE/task.md +33 -0
  8. package/.github/workflows/add-to-board.yml +1 -1
  9. package/.github/workflows/agent-trigger.yml +4 -4
  10. package/.github/workflows/ci.yml +1 -1
  11. package/.github/workflows/npm-publish.yml +2 -2
  12. package/.github/workflows/pdlc-health-check.yml +1 -1
  13. package/.github/workflows/pdlc-stage-gate.yml +2 -2
  14. package/.github/workflows/project-automation.yml +25 -40
  15. package/AGENTS.md +50 -8
  16. package/CLAUDE.md +3 -1
  17. package/README.md +33 -32
  18. package/SETUP.md +2 -1
  19. package/adapters/claude-code/skill.md +39 -14
  20. package/adapters/hooks/pdlc-stage-gate.sh +3 -8
  21. package/bin/cli.js +555 -194
  22. package/docs/pdlc.md +5 -5
  23. package/docs/superpowers/plans/2026-05-28-jules-label-pat-split.md +240 -0
  24. package/docs/superpowers/plans/2026-05-29-agentic-pulse-rework-taxonomy.md +474 -0
  25. package/docs/superpowers/plans/2026-05-29-qa-gate-enforcement.md +354 -0
  26. package/docs/superpowers/plans/2026-06-04-spec-format-issue-template.md +160 -0
  27. package/docs/superpowers/plans/2026-06-04-two-tier-installer.md +1056 -0
  28. package/docs/superpowers/specs/2026-05-29-agentic-pulse-rework-taxonomy-design.md +122 -0
  29. package/docs/superpowers/specs/2026-06-04-spec-format-issue-template-design.md +46 -0
  30. package/package.json +2 -2
  31. package/templates/.github/ISSUE_TEMPLATE/bug.md +53 -0
  32. package/templates/.github/ISSUE_TEMPLATE/feature.md +54 -0
  33. package/templates/.github/ISSUE_TEMPLATE/task.md +33 -0
  34. package/templates/.github/workflows/add-to-board.yml +4 -4
  35. package/templates/.github/workflows/agent-trigger.yml +22 -13
  36. package/{.agentic-pdlc/templates → templates}/.github/workflows/agentic-metrics.yml +150 -27
  37. package/templates/.github/workflows/ci.yml +1 -1
  38. package/templates/.github/workflows/pdlc-health-check.yml +1 -1
  39. package/templates/.github/workflows/pdlc-stage-gate.yml +2 -2
  40. package/templates/.github/workflows/project-automation.yml +71 -32
  41. package/templates/.github/workflows/qa-agent.yml +32 -18
  42. package/templates/.github/workflows/qa-gate.yml +51 -0
  43. package/templates/full/AGENTS.md +143 -0
  44. package/templates/full/CLAUDE.md +30 -0
  45. package/templates/{docs → full/docs}/pdlc.md +4 -4
  46. package/templates/lite/AGENTS.md +121 -0
  47. package/templates/lite/CLAUDE.md +44 -0
  48. package/tests/cli.test.js +32 -0
  49. package/.agentic-pdlc/templates/.github/CODEOWNERS +0 -5
  50. package/.agentic-pdlc/templates/.github/copilot-instructions.md +0 -12
  51. package/.agentic-pdlc/templates/.github/workflows/add-to-board.yml +0 -38
  52. package/.agentic-pdlc/templates/.github/workflows/agent-trigger.yml +0 -146
  53. package/.agentic-pdlc/templates/.github/workflows/auto-approve.yml +0 -16
  54. package/.agentic-pdlc/templates/.github/workflows/ci.yml +0 -54
  55. package/.agentic-pdlc/templates/.github/workflows/pdlc-health-check.yml +0 -121
  56. package/.agentic-pdlc/templates/.github/workflows/pdlc-stage-gate.yml +0 -51
  57. package/.agentic-pdlc/templates/.github/workflows/project-automation.yml +0 -274
  58. package/.agentic-pdlc/templates/.github/workflows/protect-workflows.yml +0 -21
  59. package/.agentic-pdlc/templates/.github/workflows/qa-agent.yml +0 -128
  60. package/.agentic-pdlc/templates/AGENTS.md +0 -104
  61. package/.agentic-pdlc/templates/docs/pdlc.md +0 -123
  62. package/.github/workflows/agentic-metrics.yml +0 -422
  63. package/.github/workflows/qa-agent.yml +0 -128
  64. package/templates/AGENTS.md +0 -115
@@ -0,0 +1,143 @@
1
+ # {{PROJECT_NAME}} — AI Agent Instructions
2
+
3
+ This template is the contract between the project and any external AI agent
4
+ (Claude Code, Cursor, Copilot, Jules, Codex, Sweep, etc.). Read this before committing any change.
5
+
6
+ ## Project Overview
7
+
8
+ {{PROJECT_DESCRIPTION}}
9
+
10
+ **Structure:**
11
+ {{PROJECT_STRUCTURE}}
12
+
13
+ ## Before Any Change
14
+
15
+ ```bash
16
+ git fetch origin && git checkout main && git pull
17
+ ```
18
+
19
+ Always start from the current `main` HEAD. Never work over stale snapshots.
20
+
21
+ ## Invariants / Non-negotiable business rules
22
+
23
+ {{INVARIANTS}}
24
+ <!-- Examples:
25
+ 1. **Human-in-the-Loop** — No external side-effect actions without explicit human approval.
26
+ 2. **Immutable Audit-Log** — It's strictly forbidden to UPDATE/DELETE on audit_log; INSERT only.
27
+ 3. **Credential Isolation** — Decryption occurs only in a specific service.
28
+ -->
29
+
30
+ ## Mandatory Workflow
31
+
32
+ 0. **Identity**: Always prefix your GitHub comments with `🤖 **Agent:** ` to distinguish yourself.
33
+ 1. **Stage Check**: Before applying any label or taking any action, run `gh issue view <N> --json labels,title` to determine the issue's current stage. State: *"Issue #N — [title] — is currently at `<stage>`. Requesting confirmation to advance to `<next>`."* Wait for an explicit stage-advancement signal in this conversation turn. A prioritization signal ("work on X", "tackle X next") does **not** count as confirmation — only an explicit signal counts (e.g. "start brainstorming", "yes advance", "go"). **Exceptions — skip this step and proceed directly**:
34
+ - `spec:approved` → begin implementation (gate already passed)
35
+ - `stage:development` or `stage:testing` → issue is owned by automation; do not intervene unless explicitly asked to fix a specific problem
36
+ - `stage:approval` → spec already written; wait for PM to add `spec:approved` before doing anything
37
+ 2. **Initial State**: Apply the `stage:brainstorming` label using the GitHub CLI (`gh issue edit <N> --add-label "stage:brainstorming"`). **Exception — pre-spec'd issue**: if the issue body already contains all required spec sections (`## Problem`, `## Solution`, `## Acceptance Criteria`, `## Edge Cases`, `## Out of Scope`, `## Files to Modify`) — all present and non-empty — apply `stage:approval` directly in a single call instead, skipping `stage:brainstorming` and `stage:detailing`.
38
+ 3. Read the issue entirely — understand its type (US/BUG/TASK/SPIKE) and the Acceptance Criteria.
39
+ 4. Read `docs/pdlc.md` — understand the PDLC and the Definition of Done in this project.
40
+ 5. Read all files mentioned in the issue's technical context.
41
+ 6. Implement the **minimum viable change** that satisfies the ACs — do not refactor beyond scope.
42
+ 7. Run tests: `{{TEST_COMMAND}}`
43
+ 8. Run typecheck (if applicable): `{{TYPECHECK_COMMAND}}`
44
+ 9. Create a Pull Request with `Closes #N` in the body — automation moves the board.
45
+
46
+ ## Spec Format
47
+
48
+ When writing or rewriting an issue body during detailing, include ALL sections below. Omitting any section blocks `stage:approval`.
49
+
50
+ **Destination: the issue body.** Write spec content to the issue body using `gh issue edit <N> --body "..."` — not to a file. A file is acceptable as optional reference only. Automation checks the issue body for `## Acceptance Criteria` and `## Files to Modify` to advance the stage; content that exists only in a file is invisible to it.
51
+
52
+ ```
53
+ ## Problem
54
+ [1-3 sentences. What fails. Who affected. Measured impact.]
55
+
56
+ ## Sprint Goal / Success Metrics
57
+ | Metric | Baseline | Target | When |
58
+ |--------|----------|--------|------|
59
+
60
+ ## Solution
61
+ [Behavioral description of what is built. No implementation details.]
62
+
63
+ ## Acceptance Criteria
64
+ **AC1 — [name]**
65
+ - Given [precondition]
66
+ - When [action]
67
+ - Then [outcome]
68
+
69
+ ## Edge Cases
70
+ - EC1: [condition] → [expected behavior]
71
+
72
+ ## Out of Scope
73
+ - [item] — reason
74
+
75
+ ## Non-Functional Requirements
76
+ - Performance: [metric with number]
77
+ - Security: [constraint]
78
+ - Reliability: [constraint]
79
+ > For pure docs/markdown issues with zero runtime behavior, include the NFRs section and state "N/A".
80
+
81
+ ## Files to Modify
82
+ - `path/to/file` — what changes
83
+ ```
84
+
85
+ ## Stage Transition Rules (non-negotiable)
86
+
87
+ MUST apply `stage:brainstorming` label immediately on starting work — before reading
88
+ any code, before invoking any skill. Then read context and present problem summary
89
+ + 2–3 solution options in a single message.
90
+
91
+ MUST NOT add `stage:detailing` label until the user has explicitly selected
92
+ an approach in the current conversation turn. Work done in a prior
93
+ planning session does NOT count as confirmation.
94
+
95
+ MUST NOT add `spec:approved` or `stage:development` — these represent final
96
+ human approval or automation output. Adding them manually triggers irreversible
97
+ automation (Jules dispatch, board move).
98
+
99
+ MUST NOT manually add `stage:approval` except via the pre-spec'd exception
100
+ below. In the standard flow, `stage:approval` is set after you write a complete
101
+ spec and the user confirms; it is not applied before the spec exists.
102
+
103
+ Each stage transition requires a fresh explicit signal from the user in the same
104
+ session where the transition happens. The pre-spec'd exception is the only
105
+ deviation from this rule.
106
+
107
+ **Pre-spec'd exception**: if the issue body already contains all required spec
108
+ sections (`## Problem`, `## Solution`, `## Acceptance Criteria`, `## Edge Cases`,
109
+ `## Out of Scope`, `## Files to Modify`) — all present and non-empty — apply
110
+ `stage:approval` directly in a single `gh issue edit` call, skipping
111
+ `stage:brainstorming` and `stage:detailing`. One label event eliminates the
112
+ race condition that causes the project board to land on the wrong column.
113
+
114
+ ## Pipeline Updates
115
+
116
+ To add or configure optional agents (Jules, QA Agent, Sentinel) at any time:
117
+
118
+ ```bash
119
+ npx create-agentic-pdlc --update
120
+ ```
121
+
122
+ Run this when the user says anything like "update the pipeline", "update the board", or "configure the agents". It detects what is already configured and interactively sets up what is missing — without touching this file or any user-owned config.
123
+
124
+ ## What NOT to do
125
+
126
+ - Never commit directly to `main`.
127
+ - Never open a PR without passing the tests.
128
+ - Never implement beyond the immediate scope of the issue.
129
+ - Never create future-proofing abstractions for hypothetical features.
130
+ - The agent MUST NOT apply these labels under any circumstances (PM only):
131
+ - `spec:approved`: triggers Jules dispatch + board move to Development.
132
+ - `qa:approved`: triggers board move to Code Review.
133
+ - `qa:needs-work`: signals the PR requires changes and halts the flow.
134
+ - Never add or remove stage:* labels manually, except: `stage:brainstorming` as the initial label when starting work, or `stage:approval` directly when applying the pre-spec'd exception. All other stage transitions are owned by GitHub Actions automation and the PM.
135
+ {{EXTRA_DONT}}
136
+
137
+ ## Project Standards
138
+
139
+ - **Tests:** `{{TEST_COMMAND}}`
140
+ - **Lint/Types:** `{{LINT_COMMAND}}`
141
+ - **Typecheck:** `{{TYPECHECK_COMMAND}}`
142
+ - **Build:** `{{BUILD_COMMAND}}`
143
+ {{EXTRA_PATTERNS}}
@@ -0,0 +1,30 @@
1
+ <!-- agentic-full -->
2
+ ## Multi-Agent Pipeline
3
+
4
+ This project uses automated agents beyond the spec gate:
5
+
6
+ | Agent | Role | Trigger |
7
+ |---|---|---|
8
+ | Implementation Agent (Jules or custom) | Implements spec after `spec:approved` | `agent-trigger.yml` |
9
+ | QA Agent | Verifies PR against ACs via GitHub Models | `project-automation.yml` Variant B |
10
+ | Sentinel | Architecture audit via Gemini Code Assist CI | `architecture-violation` label |
11
+
12
+ **QA Labels — automation-owned, never apply manually:**
13
+ - `qa:approved` — QA Agent passed; card moves to Code Review
14
+ - `qa:needs-work` — QA Agent found issues; PR flow halts
15
+ - `infra:qa-broken` — QA Agent error; requires manual review
16
+
17
+ **Board Automation:**
18
+ `project-automation.yml` moves cards between board columns based on labels and PR events.
19
+ Column Option IDs and Project IDs are documented in `docs/pdlc.md`.
20
+
21
+ Read `docs/pdlc.md` for the full board layout, column IDs, and label reference.
22
+
23
+ **Pipeline Updates:**
24
+ To add or configure optional agents (Jules, QA Agent, Sentinel):
25
+ ```bash
26
+ npx create-agentic-pdlc --update
27
+ ```
28
+
29
+ Run this when asked to "update the pipeline", "configure the agents", or "update the board".
30
+ It detects what is already configured and sets up what is missing — without touching user-owned files.
@@ -58,7 +58,7 @@ REPO = {{REPO_OWNER}}/{{REPO_NAME}}
58
58
  ```
59
59
  [icon] [PREFIX]: [short description, imperative tense]
60
60
 
61
- 👤 US: user story
61
+ feat: new feature or behavioral change
62
62
  🐛 BUG: bug
63
63
  🔧 TASK: operational task
64
64
  🔬 SPIKE: exploration/evaluation spike
@@ -77,7 +77,7 @@ REPO = {{REPO_OWNER}}/{{REPO_NAME}}
77
77
  | `qa:approved` | PR | Green | QA Agent passed — AC coverage verified |
78
78
  | `qa:needs-work` | PR | Red | QA Agent failed — PR needs changes |
79
79
  | `infra:qa-broken` | PR | Orange | QA Agent error — manual review required |
80
- | `type:us` | Issue | Blue | New feature or behavioral change — full flow |
80
+ | `type:feature` | Issue | Blue | New feature or behavioral change — full flow |
81
81
  | `type:task` | Issue | Yellow | Operational/non-functional change — full flow |
82
82
  | `type:bug` | Issue | Red | Something broken — full flow |
83
83
  | `type:spike` | Issue | Gray | Research/evaluation — never reaches Development |
@@ -98,12 +98,12 @@ The `type:*` label is the authoritative signal — set automatically by the agen
98
98
 
99
99
  | Label | Flow |
100
100
  |---|---|
101
- | `type:us` | brainstorming → Gate 1 → detailing → approval |
101
+ | `type:feature` | brainstorming → Gate 1 → detailing → approval |
102
102
  | `type:task` | brainstorming → Gate 1 → detailing → approval |
103
103
  | `type:bug` | brainstorming → Gate 1 → detailing → approval |
104
104
  | `type:spike` | brainstorming → Gate 1 → detailing → conclusion comment (never reaches Development) |
105
105
 
106
- If no `type:*` label present and agent confidence < 85%, defaults to `type:us` (safe fallback — never skips gates by omission).
106
+ If no `type:*` label present and agent confidence < 85%, defaults to `type:feature` (safe fallback — never skips gates by omission).
107
107
 
108
108
  ## Bypass Mechanism
109
109
 
@@ -0,0 +1,121 @@
1
+ # {{PROJECT_NAME}} — AI Agent Instructions
2
+
3
+ This is the contract between the project and any external AI agent
4
+ (Claude Code, Cursor, Copilot, Codex, Sweep, etc.). Read this before committing any change.
5
+
6
+ ## Project Overview
7
+
8
+ {{PROJECT_DESCRIPTION}}
9
+
10
+ **Structure:**
11
+ {{PROJECT_STRUCTURE}}
12
+
13
+ ## Before Any Change
14
+
15
+ ```bash
16
+ git fetch origin && git checkout main && git pull
17
+ ```
18
+
19
+ Always start from the current `main` HEAD. Never work over stale snapshots.
20
+
21
+ ## Invariants / Non-negotiable business rules
22
+
23
+ {{INVARIANTS}}
24
+ <!-- Examples:
25
+ 1. **Minimum viable change** — implement exactly what the spec says; no future-proofing.
26
+ 2. **Human-in-the-Loop** — No external side-effect actions without explicit human approval.
27
+ 3. **Immutable Audit-Log** — INSERT only on audit_log; never UPDATE/DELETE.
28
+ -->
29
+
30
+ ## Mandatory Workflow
31
+
32
+ 0. **Identity**: Always prefix your GitHub comments with `🤖 **Agent:** ` to distinguish yourself.
33
+ 1. **Stage Check**: Run `gh issue view <N> --json labels,title` to determine current stage.
34
+ - `spec:approved` → begin implementation (gate already passed)
35
+ - `stage:approval` → spec written; wait for PM to add `spec:approved`
36
+ - Otherwise → follow the stage gate below
37
+ 2. Apply `stage:brainstorming` before reading any code: `gh issue edit <N> --add-label "stage:brainstorming"`
38
+ 3. Read the issue entirely — understand type and Acceptance Criteria.
39
+ 4. Read all files mentioned in the issue's technical context.
40
+ 5. Present problem summary + 2–3 solution options. **Stop and wait for PM choice.**
41
+ 6. Once PM selects an approach, write the complete spec into the issue body. Advance to `stage:approval`.
42
+ 7. Wait for PM to add `spec:approved`. Then implement the **minimum viable change** that satisfies the ACs.
43
+ 8. Run tests: `{{TEST_COMMAND}}`
44
+ 9. Create a Pull Request with `Closes #N` in the body.
45
+
46
+ ## Spec Format
47
+
48
+ **Destination: the issue body.** Write spec content using `gh issue edit <N> --body "..."` — not to a file.
49
+ Automation checks the issue body for `## Acceptance Criteria` and `## Files to Modify`.
50
+
51
+ ```
52
+ ## Problem
53
+ [1-3 sentences. What fails. Who affected. Measured impact.]
54
+
55
+ ## Sprint Goal / Success Metrics
56
+ | Metric | Baseline | Target | When |
57
+ |--------|----------|--------|------|
58
+
59
+ ## Solution
60
+ [Behavioral description of what is built. No implementation details.]
61
+
62
+ ## Acceptance Criteria
63
+ **AC1 — [name]**
64
+ - Given [precondition]
65
+ - When [action]
66
+ - Then [outcome]
67
+
68
+ ## Edge Cases
69
+ - EC1: [condition] → [expected behavior]
70
+
71
+ ## Out of Scope
72
+ - [item] — reason
73
+
74
+ ## Non-Functional Requirements
75
+ - Performance: [metric with number]
76
+ - Security: [constraint]
77
+ - Reliability: [constraint]
78
+ > For pure docs/markdown issues with zero runtime behavior, include the NFRs section and state "N/A".
79
+
80
+ ## Files to Modify
81
+ - `path/to/file` — what changes
82
+ ```
83
+
84
+ ## Stage Gate Labels
85
+
86
+ | Label | Who sets it | Meaning |
87
+ |---|---|---|
88
+ | `stage:brainstorming` | Agent | Brainstorming started — first action before reading code |
89
+ | `stage:detailing` | Agent | Spec is being written |
90
+ | `stage:approval` | Agent | Spec complete, awaiting PM review |
91
+ | `spec:approved` | **PM only** | Gate cleared — implement |
92
+
93
+ **NEVER apply `spec:approved`, `stage:development`, or `qa:*`.** These are owned by the PM and automation.
94
+
95
+ ## Stage Transition Rules (non-negotiable)
96
+
97
+ MUST apply `stage:brainstorming` immediately on starting work — before reading any code,
98
+ before invoking any skill.
99
+
100
+ MUST NOT add `stage:detailing` until the user has explicitly selected an approach
101
+ in the current conversation turn.
102
+
103
+ MUST NOT add `spec:approved` or any approval-trigger label under any circumstances.
104
+
105
+ Each stage transition requires a fresh explicit signal from the user in the same session.
106
+
107
+ ## What NOT to Do
108
+
109
+ - Never commit directly to `main`.
110
+ - Never open a PR without `spec:approved` on the linked issue.
111
+ - Never implement beyond the immediate scope of the issue.
112
+ - Never create future-proofing abstractions for hypothetical features.
113
+ {{EXTRA_DONT}}
114
+
115
+ ## Project Standards
116
+
117
+ - **Tests:** `{{TEST_COMMAND}}`
118
+ - **Lint/Types:** `{{LINT_COMMAND}}`
119
+ - **Typecheck:** `{{TYPECHECK_COMMAND}}`
120
+ - **Build:** `{{BUILD_COMMAND}}`
121
+ {{EXTRA_PATTERNS}}
@@ -0,0 +1,44 @@
1
+ # {{PROJECT_NAME}}
2
+
3
+ **What it is:** {{PROJECT_DESCRIPTION}}
4
+
5
+ ## Non-Negotiable Invariants
6
+
7
+ 1. **Minimum viable change** — implement exactly what the spec says. No refactoring beyond scope, no future-proofing, no abstractions for hypothetical needs.
8
+ 2. **Spec before code** — never edit files, create branches, or commit unless the linked issue has label `spec:approved` (set by PM only) or the branch starts with `hotfix/`.
9
+
10
+ ## Stage Gate
11
+
12
+ Three labels gate every issue:
13
+
14
+ | Label | Who sets it | What it unlocks |
15
+ |---|---|---|
16
+ | `stage:brainstorming` | Agent (first action) | Reading code + presenting options |
17
+ | `stage:approval` | Agent (after spec is written) | Signals spec is ready for PM review |
18
+ | `spec:approved` | **PM only** | Clears agent to implement |
19
+
20
+ **NEVER apply `spec:approved`.** The PM sets it after reviewing the spec in the issue body. Applying it triggers irreversible automation.
21
+
22
+ ## Workflow
23
+
24
+ 1. Apply `stage:brainstorming` immediately — before reading code or invoking any tool.
25
+ 2. Read the issue. Present problem summary + 2–3 solution options. **Stop and wait for PM to choose.**
26
+ 3. Once PM selects an approach, write the complete spec into the issue body (`gh issue edit <N> --body "..."`). Advance to `stage:approval`.
27
+ 4. **Stop.** Wait for PM to add `spec:approved`.
28
+ 5. After `spec:approved`: create branch, implement minimum viable change, open PR with `Closes #N`.
29
+
30
+ ## Hook Behavior
31
+
32
+ A `PreToolUse` hook blocks `gh pr create` unless:
33
+ - The linked issue has `spec:approved`, **or**
34
+ - The branch name starts with `hotfix/`
35
+
36
+ If blocked: check the issue labels before retrying.
37
+
38
+ ## What NOT to Do
39
+
40
+ - Never commit to `main` directly.
41
+ - Never open a PR without `spec:approved` on the linked issue.
42
+ - Never implement beyond the immediate scope of the spec.
43
+ - Never add abstractions, error handling, or features for hypothetical future needs.
44
+ - Never apply `spec:approved`, `stage:development`, or `qa:*` — these are PM/automation only.
@@ -0,0 +1,32 @@
1
+ const { describe, it } = require('node:test');
2
+ const assert = require('node:assert/strict');
3
+
4
+ const { resolveMode } = require('../bin/cli.js');
5
+
6
+ describe('resolveMode', () => {
7
+ it('returns lite when no flags', () => {
8
+ assert.equal(resolveMode([]), 'lite');
9
+ });
10
+ it('returns full for --agentic', () => {
11
+ assert.equal(resolveMode(['--agentic']), 'full');
12
+ });
13
+ it('returns update for --update', () => {
14
+ assert.equal(resolveMode(['--update']), 'update');
15
+ });
16
+ it('returns upgrade for --upgrade-to-agentic', () => {
17
+ assert.equal(resolveMode(['--upgrade-to-agentic']), 'upgrade');
18
+ });
19
+ it('--update takes precedence over --agentic', () => {
20
+ assert.equal(resolveMode(['--update', '--agentic']), 'update');
21
+ });
22
+ });
23
+
24
+ describe('buildFullClaudeContent', () => {
25
+ it('concatenates lite and full with a newline separator', () => {
26
+ const lite = '# Lite\ncontent';
27
+ const full = '## Extra\nmore';
28
+ const result = lite + '\n' + full;
29
+ assert.ok(result.startsWith('# Lite'));
30
+ assert.ok(result.includes('## Extra'));
31
+ });
32
+ });
@@ -1,5 +0,0 @@
1
- # This file prevents autonomous agents from modifying core security, automation, and instruction rules
2
- # without explicit approval from the repository owner.
3
-
4
- .github/ @{{GITHUB_USERNAME}}
5
- AGENTS.md @{{GITHUB_USERNAME}}
@@ -1,12 +0,0 @@
1
- # Agentic PDLC Instructions for GitHub Copilot Workspace
2
-
3
- Hello! You are operating within the Agentic PDLC framework.
4
-
5
- Before addressing the user's prompt or executing any task in this workspace, you MUST:
6
-
7
- 1. Read the `AGENTS.md` file located at the root of this repository. It contains the primary instructions, definitions of done, and absolute invariants you must respect.
8
- 2. Read `docs/pdlc.md` to understand your role in the project lifecycle.
9
-
10
- Never violate the invariants described in those files. If a user asks you to do something that contradicts `AGENTS.md`, you must refuse and point out the conflict.
11
-
12
- Focus on delivering the absolute minimum required to satisfy the immediate technical specs. Start!
@@ -1,38 +0,0 @@
1
- name: Add to Board on Open
2
-
3
- on:
4
- issues:
5
- types: [opened]
6
-
7
- env:
8
- PROJECT_ID: "{{PROJECT_ID}}"
9
- STATUS_FIELD_ID: "{{STATUS_FIELD_ID}}"
10
- STATUS_IDEA: "{{ID_IDEA}}"
11
-
12
- jobs:
13
- add-to-board:
14
- name: Auto-add new issue to board
15
- runs-on: ubuntu-latest
16
- env:
17
- PROJECT_PAT: ${{ secrets.PROJECT_PAT }}
18
- steps:
19
- - name: Add issue to project board
20
- if: ${{ env.PROJECT_PAT != '' && env.PROJECT_ID != '{{PROJECT_ID}}' }}
21
- uses: actions/github-script@v7
22
- with:
23
- github-token: ${{ env.PROJECT_PAT }}
24
- script: |
25
- const nodeId = context.payload.issue.node_id;
26
- const number = context.payload.issue.number;
27
- const { addProjectV2ItemById: { item } } = await github.graphql(`
28
- mutation($p: ID!, $c: ID!) {
29
- addProjectV2ItemById(input: {projectId: $p, contentId: $c}) { item { id } }
30
- }`, { p: process.env.PROJECT_ID, c: nodeId });
31
- await github.graphql(`
32
- mutation($p: ID!, $i: ID!, $f: ID!, $v: ProjectV2FieldValue!) {
33
- updateProjectV2ItemFieldValue(input: {projectId: $p, itemId: $i, fieldId: $f, value: $v}) {
34
- projectV2Item { id }
35
- }
36
- }`, { p: process.env.PROJECT_ID, i: item.id, f: process.env.STATUS_FIELD_ID,
37
- v: { singleSelectOptionId: process.env.STATUS_IDEA } });
38
- console.log(`Issue #${number} added to board → Idea`);
@@ -1,146 +0,0 @@
1
- name: Trigger Implementation Agent
2
-
3
- # Triggers when spec:approved is added to an issue (Gate 2)
4
- # or when an architecture-violation issue is modified (Sentinel flow)
5
- on:
6
- issues:
7
- types: [labeled]
8
-
9
- jobs:
10
- trigger-implementation-agent:
11
- name: Trigger {{IMPLEMENTATION_AGENT_NAME}} for implementation
12
- # Runs only when spec:approved is added
13
- if: github.event.label.name == 'spec:approved'
14
- runs-on: ubuntu-latest
15
- permissions:
16
- issues: write
17
- pull-requests: write
18
- contents: read
19
- env:
20
- PROJECT_PAT: ${{ secrets.PROJECT_PAT }}
21
- PROJECT_ID: "{{PROJECT_ID}}"
22
- STATUS_FIELD_ID: "{{STATUS_FIELD_ID}}"
23
- STATUS_DEVELOPMENT: "{{ID_DEVELOPMENT}}"
24
- steps:
25
- - name: Update Labels
26
- uses: actions/github-script@v7
27
- with:
28
- github-token: ${{ secrets.GITHUB_TOKEN }}
29
- script: |
30
- const { owner, repo } = context.repo;
31
- const issue_number = context.payload.issue.number;
32
-
33
- try {
34
- await github.rest.issues.removeLabel({
35
- owner,
36
- repo,
37
- issue_number,
38
- name: 'stage:approval'
39
- });
40
- } catch (error) {
41
- console.log('Label stage:approval not found or could not be removed');
42
- }
43
-
44
- const agentLabel = '{{IMPLEMENTATION_AGENT_LABEL}}';
45
- const labelsToAdd = ['stage:development'];
46
- if (!agentLabel.includes('{{')) labelsToAdd.push(agentLabel, 'agent:working');
47
-
48
- await github.rest.issues.addLabels({
49
- owner,
50
- repo,
51
- issue_number,
52
- labels: labelsToAdd
53
- });
54
-
55
- - name: Move board card to Development
56
- if: ${{ env.PROJECT_PAT != '' && env.PROJECT_ID != '{{PROJECT_ID}}' }}
57
- continue-on-error: true
58
- uses: actions/github-script@v7
59
- with:
60
- github-token: ${{ env.PROJECT_PAT }}
61
- script: |
62
- const nodeId = context.payload.issue.node_id;
63
- const number = context.payload.issue.number;
64
- const { addProjectV2ItemById: { item } } = await github.graphql(`
65
- mutation($p: ID!, $c: ID!) {
66
- addProjectV2ItemById(input: {projectId: $p, contentId: $c}) { item { id } }
67
- }`, { p: process.env.PROJECT_ID, c: nodeId });
68
- await github.graphql(`
69
- mutation($p: ID!, $i: ID!, $f: ID!, $v: ProjectV2FieldValue!) {
70
- updateProjectV2ItemFieldValue(input: {projectId: $p, itemId: $i, fieldId: $f, value: $v}) {
71
- projectV2Item { id }
72
- }
73
- }`, { p: process.env.PROJECT_ID, i: item.id, f: process.env.STATUS_FIELD_ID,
74
- v: { singleSelectOptionId: process.env.STATUS_DEVELOPMENT } });
75
- console.log(`Issue #${number} → Development`);
76
-
77
- - name: Comment on issue to trigger agent and prevent race conditions
78
- if: ${{ !contains('{{IMPLEMENTATION_AGENT_LABEL}}', '{{') && vars.JULES_ENABLED == 'true' }}
79
- uses: actions/github-script@v7
80
- with:
81
- github-token: ${{ secrets.GITHUB_TOKEN }}
82
- script: |
83
- const issueNumber = context.payload.issue.number;
84
- const issueTitle = context.payload.issue.title;
85
-
86
- const body = [
87
- `🤖 **Agentic PDLC Orchestrator:** I have dispatched the implementation agent. Please wait for the Pull Request and avoid making concurrent commits on this task to prevent race conditions.`,
88
- '',
89
- `{{AGENT_HANDLE}} The spec for this issue has been approved. Please implement it exactly as described in the body above.`,
90
- '',
91
- '**Mandatory steps before you begin:**',
92
- '1. `git fetch origin && git checkout main && git pull` — always start from the current HEAD',
93
- '2. Read `AGENTS.md` — mandatory rules for agents in this repository',
94
- '3. Read `docs/pdlc.md` — Definition of Done and invariants reference',
95
- '',
96
- '**Rules:**',
97
- '- Implement strictly what the Acceptance Criteria describes',
98
- '- Run `{{TEST_COMMAND}}` before opening the Pull Request',
99
- `- Include \`Closes #${issueNumber}\` in the PR body`,
100
- '- Create a descriptive branch branching from `main`',
101
- ].join('\n');
102
-
103
- await github.rest.issues.createComment({
104
- owner: context.repo.owner,
105
- repo: context.repo.repo,
106
- issue_number: issueNumber,
107
- body,
108
- });
109
-
110
- trigger-agent-on-violation:
111
- name: Trigger {{IMPLEMENTATION_AGENT_NAME}} for architecture violation
112
- # Runs when architecture-violation is added (Sentinel flow)
113
- if: github.event.label.name == 'architecture-violation'
114
- runs-on: ubuntu-latest
115
- permissions:
116
- issues: write
117
- pull-requests: write
118
- contents: read
119
- steps:
120
- - name: Comment on issue to trigger agent
121
- if: ${{ !contains('{{IMPLEMENTATION_AGENT_LABEL}}', '{{') && vars.JULES_ENABLED == 'true' }}
122
- uses: actions/github-script@v7
123
- with:
124
- github-token: ${{ secrets.GITHUB_TOKEN }}
125
- script: |
126
- const issueNumber = context.payload.issue.number;
127
-
128
- const body = [
129
- `{{AGENT_HANDLE}} Please fix the architecture violation described in this issue.`,
130
- '',
131
- '**Mandatory steps before you begin:**',
132
- '1. `git fetch origin && git checkout main && git pull` — always start from the current HEAD',
133
- '2. Read `AGENTS.md` — mandatory rules for agents in this repository',
134
- '',
135
- '**Rules:**',
136
- '- Fix only what the violation points out — do not refactor unrelated code',
137
- '- Run `{{TEST_COMMAND}}` before opening the Pull Request',
138
- `- Include \`Closes #${issueNumber}\` in the PR body`,
139
- ].join('\n');
140
-
141
- await github.rest.issues.createComment({
142
- owner: context.repo.owner,
143
- repo: context.repo.repo,
144
- issue_number: issueNumber,
145
- body,
146
- });
@@ -1,16 +0,0 @@
1
- name: Auto Approve PRs
2
- on:
3
- pull_request:
4
- types: [opened, labeled, synchronize]
5
-
6
- permissions:
7
- pull-requests: write
8
-
9
- jobs:
10
- auto-approve:
11
- runs-on: ubuntu-latest
12
- if: contains(github.event.pull_request.labels.*.name, 'auto-approve')
13
- steps:
14
- - uses: hmarr/auto-approve-action@v4
15
- with:
16
- github-token: ${{ secrets.GITHUB_TOKEN }}