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.
- package/.agentic-pdlc/hooks/pdlc-stage-gate.sh +37 -10
- package/.agentic-pdlc/metrics/raw/2026-W22.jsonl +114 -0
- package/.claude/settings.json +18 -0
- package/.coderabbit.yaml +35 -0
- package/.github/ISSUE_TEMPLATE/bug.md +53 -0
- package/.github/ISSUE_TEMPLATE/feature.md +54 -0
- package/.github/ISSUE_TEMPLATE/task.md +33 -0
- package/.github/workflows/add-to-board.yml +1 -1
- package/.github/workflows/agent-trigger.yml +4 -4
- package/.github/workflows/ci.yml +1 -1
- package/.github/workflows/npm-publish.yml +2 -2
- package/.github/workflows/pdlc-health-check.yml +1 -1
- package/.github/workflows/pdlc-stage-gate.yml +2 -2
- package/.github/workflows/project-automation.yml +25 -40
- package/AGENTS.md +50 -8
- package/CLAUDE.md +3 -1
- package/README.md +33 -32
- package/SETUP.md +2 -1
- package/adapters/claude-code/skill.md +39 -14
- package/adapters/hooks/pdlc-stage-gate.sh +3 -8
- package/bin/cli.js +555 -194
- package/docs/pdlc.md +5 -5
- package/docs/superpowers/plans/2026-05-28-jules-label-pat-split.md +240 -0
- package/docs/superpowers/plans/2026-05-29-agentic-pulse-rework-taxonomy.md +474 -0
- package/docs/superpowers/plans/2026-05-29-qa-gate-enforcement.md +354 -0
- package/docs/superpowers/plans/2026-06-04-spec-format-issue-template.md +160 -0
- package/docs/superpowers/plans/2026-06-04-two-tier-installer.md +1056 -0
- package/docs/superpowers/specs/2026-05-29-agentic-pulse-rework-taxonomy-design.md +122 -0
- package/docs/superpowers/specs/2026-06-04-spec-format-issue-template-design.md +46 -0
- package/package.json +2 -2
- package/templates/.github/ISSUE_TEMPLATE/bug.md +53 -0
- package/templates/.github/ISSUE_TEMPLATE/feature.md +54 -0
- package/templates/.github/ISSUE_TEMPLATE/task.md +33 -0
- package/templates/.github/workflows/add-to-board.yml +4 -4
- package/templates/.github/workflows/agent-trigger.yml +22 -13
- package/{.agentic-pdlc/templates → templates}/.github/workflows/agentic-metrics.yml +150 -27
- package/templates/.github/workflows/ci.yml +1 -1
- package/templates/.github/workflows/pdlc-health-check.yml +1 -1
- package/templates/.github/workflows/pdlc-stage-gate.yml +2 -2
- package/templates/.github/workflows/project-automation.yml +71 -32
- package/templates/.github/workflows/qa-agent.yml +32 -18
- package/templates/.github/workflows/qa-gate.yml +51 -0
- package/templates/full/AGENTS.md +143 -0
- package/templates/full/CLAUDE.md +30 -0
- package/templates/{docs → full/docs}/pdlc.md +4 -4
- package/templates/lite/AGENTS.md +121 -0
- package/templates/lite/CLAUDE.md +44 -0
- package/tests/cli.test.js +32 -0
- package/.agentic-pdlc/templates/.github/CODEOWNERS +0 -5
- package/.agentic-pdlc/templates/.github/copilot-instructions.md +0 -12
- package/.agentic-pdlc/templates/.github/workflows/add-to-board.yml +0 -38
- package/.agentic-pdlc/templates/.github/workflows/agent-trigger.yml +0 -146
- package/.agentic-pdlc/templates/.github/workflows/auto-approve.yml +0 -16
- package/.agentic-pdlc/templates/.github/workflows/ci.yml +0 -54
- package/.agentic-pdlc/templates/.github/workflows/pdlc-health-check.yml +0 -121
- package/.agentic-pdlc/templates/.github/workflows/pdlc-stage-gate.yml +0 -51
- package/.agentic-pdlc/templates/.github/workflows/project-automation.yml +0 -274
- package/.agentic-pdlc/templates/.github/workflows/protect-workflows.yml +0 -21
- package/.agentic-pdlc/templates/.github/workflows/qa-agent.yml +0 -128
- package/.agentic-pdlc/templates/AGENTS.md +0 -104
- package/.agentic-pdlc/templates/docs/pdlc.md +0 -123
- package/.github/workflows/agentic-metrics.yml +0 -422
- package/.github/workflows/qa-agent.yml +0 -128
- 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
|
-
|
|
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:
|
|
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:
|
|
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:
|
|
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,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 }}
|