pi-pipelines 0.1.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/CHANGELOG.md +29 -0
- package/LICENSE +21 -0
- package/README.md +367 -0
- package/extensions/config-loader.ts +444 -0
- package/extensions/index.ts +447 -0
- package/extensions/pipeline-runner.ts +1346 -0
- package/extensions/subagent-bridge.ts +291 -0
- package/extensions/tui-widgets.ts +68 -0
- package/extensions/types.ts +153 -0
- package/extensions/utils.ts +15 -0
- package/package.json +79 -0
- package/pipelines/dev-sprint.pipeline.yaml +104 -0
- package/pipelines/hello-world.pipeline.yaml +25 -0
- package/pipelines/refactor.pipeline.yaml +59 -0
- package/pipelines/release-check.pipeline.yaml +60 -0
- package/pipelines/tdd-review.pipeline.yaml +78 -0
- package/skills/pi-pipelines/SKILL.md +575 -0
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
name: dev-sprint
|
|
2
|
+
description: "Complete development cycle: plan → TDD with review gates → test → project review and next actions."
|
|
3
|
+
report:
|
|
4
|
+
agent: planner
|
|
5
|
+
focus: "development cycle outcomes, current project state, and next actions"
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
stages:
|
|
9
|
+
- id: plan
|
|
10
|
+
agent: planner
|
|
11
|
+
task: >
|
|
12
|
+
Analyze the codebase and create a detailed implementation plan for: {task}.
|
|
13
|
+
Include acceptance criteria, test strategy, architecture decisions,
|
|
14
|
+
likely files to change, dependencies, risks, and verification plan.
|
|
15
|
+
If the task is ambiguous, state what needs clarification.
|
|
16
|
+
|
|
17
|
+
- id: write-tests
|
|
18
|
+
agent: worker
|
|
19
|
+
task: >
|
|
20
|
+
Write comprehensive tests for: {task}.
|
|
21
|
+
Follow the plan: {outputs.plan}.
|
|
22
|
+
Use the project's test framework and conventions.
|
|
23
|
+
Cover: happy paths, error paths, edge cases, integration points.
|
|
24
|
+
Do not modify production code in this stage.
|
|
25
|
+
|
|
26
|
+
gate:
|
|
27
|
+
type: review-loop
|
|
28
|
+
maxRounds: 3
|
|
29
|
+
targetScore: 9
|
|
30
|
+
reviewers:
|
|
31
|
+
- focus: "Test completeness: are all scenarios, acceptance criteria, and edge cases from the plan covered?"
|
|
32
|
+
- focus: "Test quality: are tests isolated, deterministic, maintainable, and following project conventions?"
|
|
33
|
+
- focus: "Edge cases: are boundary values, error states, unusual inputs, and integration points tested where relevant?"
|
|
34
|
+
|
|
35
|
+
- id: implement
|
|
36
|
+
agent: worker
|
|
37
|
+
task: >
|
|
38
|
+
Implement the code to pass the tests: {outputs.write-tests}.
|
|
39
|
+
Follow the plan: {outputs.plan}.
|
|
40
|
+
Keep code clean, focused, and well-structured.
|
|
41
|
+
Do not modify tests unless a test is clearly invalid; if you modify a test, explain why.
|
|
42
|
+
|
|
43
|
+
gate:
|
|
44
|
+
type: review-loop
|
|
45
|
+
maxRounds: 3
|
|
46
|
+
targetScore: 8
|
|
47
|
+
reviewers:
|
|
48
|
+
- focus: "Does the implementation satisfy ALL acceptance criteria and make the intended tests pass?"
|
|
49
|
+
- focus: "Is the code simple, readable, maintainable, and consistent with existing project patterns?"
|
|
50
|
+
- focus: "Does the implementation handle errors and edge cases without overengineering?"
|
|
51
|
+
|
|
52
|
+
- id: verify
|
|
53
|
+
agent: worker
|
|
54
|
+
task: >
|
|
55
|
+
Run the full project test suite using the existing package manager or test scripts.
|
|
56
|
+
Report:
|
|
57
|
+
- Pass/fail counts
|
|
58
|
+
- Any regressions
|
|
59
|
+
- Coverage if available
|
|
60
|
+
- Commands attempted and blockers
|
|
61
|
+
- Stability assessment
|
|
62
|
+
Implementation context: {outputs.implement}
|
|
63
|
+
|
|
64
|
+
- id: project-review
|
|
65
|
+
parallel:
|
|
66
|
+
- id: code-health
|
|
67
|
+
agent: oracle
|
|
68
|
+
task: >
|
|
69
|
+
Review the overall project state after this change for: {task}.
|
|
70
|
+
Consider the verification results: {outputs.verify}.
|
|
71
|
+
What technical debt exists? What should be addressed soon?
|
|
72
|
+
Return concise sections: Debt, Soon, Risks.
|
|
73
|
+
|
|
74
|
+
- id: next-priorities
|
|
75
|
+
agent: planner
|
|
76
|
+
task: >
|
|
77
|
+
Based on the project state, verification results: {outputs.verify},
|
|
78
|
+
and this work, what are the 3 most impactful things to work on next for: {task}?
|
|
79
|
+
Prioritize by user value, risk reduction, and maintainability.
|
|
80
|
+
Return exactly 3 prioritized next tasks with rationale.
|
|
81
|
+
|
|
82
|
+
- id: quality-assessment
|
|
83
|
+
agent: reviewer
|
|
84
|
+
task: >
|
|
85
|
+
Assess the overall quality of the project implementation for: {task}.
|
|
86
|
+
Consider the verification results: {outputs.verify}.
|
|
87
|
+
What risks, bottlenecks, or areas need attention before continuing?
|
|
88
|
+
Return a concise quality/risk report.
|
|
89
|
+
|
|
90
|
+
- id: synthesize
|
|
91
|
+
agent: planner
|
|
92
|
+
task: >
|
|
93
|
+
Synthesize the project review findings into a clear action plan.
|
|
94
|
+
|
|
95
|
+
Code Health: {outputs.code-health}
|
|
96
|
+
Next Priorities: {outputs.next-priorities}
|
|
97
|
+
Quality Assessment: {outputs.quality-assessment}
|
|
98
|
+
Verification Results: {outputs.verify}
|
|
99
|
+
|
|
100
|
+
Output a structured proposal with:
|
|
101
|
+
1. What was accomplished
|
|
102
|
+
2. Current project state
|
|
103
|
+
3. Top 3 recommended next tasks with rationale
|
|
104
|
+
4. Any blocking issues or risks
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
name: hello-world
|
|
2
|
+
description: "Smoke-test pipeline: explore relevant project areas, then produce a concise action plan."
|
|
3
|
+
report:
|
|
4
|
+
agent: planner
|
|
5
|
+
focus: "quick overview and recommended next action"
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
stages:
|
|
9
|
+
- id: explore
|
|
10
|
+
agent: scout
|
|
11
|
+
task: >
|
|
12
|
+
Explore the codebase for: {task}.
|
|
13
|
+
Return a concise structured summary with:
|
|
14
|
+
1. Relevant files and directories
|
|
15
|
+
2. Likely tech stack and test commands
|
|
16
|
+
3. Obvious risks, assumptions, or missing context
|
|
17
|
+
If the task is too broad, say what needs clarification.
|
|
18
|
+
|
|
19
|
+
- id: plan
|
|
20
|
+
agent: planner
|
|
21
|
+
task: >
|
|
22
|
+
Based on this exploration: {outputs.explore},
|
|
23
|
+
create a simple action plan for: {task}.
|
|
24
|
+
Keep it concise — 3-5 bullet points.
|
|
25
|
+
Include: next action, likely files to change, and verification step.
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
name: refactor
|
|
2
|
+
description: "Safe refactoring pipeline — understand, plan, refactor with review gate, verify no regressions."
|
|
3
|
+
report:
|
|
4
|
+
agent: planner
|
|
5
|
+
focus: "refactoring results, regression risk, and next steps"
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
stages:
|
|
9
|
+
- id: understand
|
|
10
|
+
agent: scout
|
|
11
|
+
task: >
|
|
12
|
+
Analyze the codebase to understand the current state of: {task}.
|
|
13
|
+
Find all relevant files, data flow, dependencies, and existing tests.
|
|
14
|
+
Identify risks, unknowns, and safe refactoring boundaries.
|
|
15
|
+
Return a concise map of what should and should not be changed.
|
|
16
|
+
|
|
17
|
+
- id: plan
|
|
18
|
+
agent: planner
|
|
19
|
+
task: >
|
|
20
|
+
Create a refactoring plan for: {task}.
|
|
21
|
+
Based on the codebase analysis: {outputs.understand}.
|
|
22
|
+
Include:
|
|
23
|
+
- Files to change
|
|
24
|
+
- Order of changes (to avoid breaking state)
|
|
25
|
+
- Test strategy
|
|
26
|
+
- Rollback plan
|
|
27
|
+
- Risk mitigation steps
|
|
28
|
+
|
|
29
|
+
- id: refactor
|
|
30
|
+
agent: worker
|
|
31
|
+
task: >
|
|
32
|
+
Implement the refactoring according to this plan: {outputs.plan}.
|
|
33
|
+
Codebase context: {outputs.understand}.
|
|
34
|
+
Make incremental, verifiable changes.
|
|
35
|
+
Preserve behavior; do not add unrelated features.
|
|
36
|
+
If tests reveal a behavior mismatch, stop and report it clearly.
|
|
37
|
+
|
|
38
|
+
gate:
|
|
39
|
+
type: review-loop
|
|
40
|
+
maxRounds: 3
|
|
41
|
+
targetScore: 8
|
|
42
|
+
reviewers:
|
|
43
|
+
- focus: "Does the refactored code preserve the original behavior? Are there behavior changes or missing cases?"
|
|
44
|
+
- focus: "Is the refactored code simpler, cleaner, and easier to maintain without unnecessary changes?"
|
|
45
|
+
- focus: "Are there any breaking changes, regressions, or risky edits that should block this refactor?"
|
|
46
|
+
|
|
47
|
+
- id: verify
|
|
48
|
+
agent: worker
|
|
49
|
+
task: >
|
|
50
|
+
Run the full test suite to verify no regressions after refactoring: {outputs.refactor}.
|
|
51
|
+
Report any failures, flaky tests, coverage impact if available, and commands attempted.
|
|
52
|
+
|
|
53
|
+
- id: summary
|
|
54
|
+
agent: planner
|
|
55
|
+
task: >
|
|
56
|
+
Summarize the refactoring done for: {task}.
|
|
57
|
+
Explain what changed, why it improved the codebase, and any follow-up work needed.
|
|
58
|
+
Test results: {outputs.verify}.
|
|
59
|
+
Include changed files if they are known from the refactor output.
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
name: release-check
|
|
2
|
+
description: "Pre-release quality gate — parallel code review, security audit, stability verification, and readiness decision."
|
|
3
|
+
report:
|
|
4
|
+
agent: scout
|
|
5
|
+
focus: "release readiness assessment and blocked issues"
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
stages:
|
|
9
|
+
- id: checks
|
|
10
|
+
parallel:
|
|
11
|
+
- id: code-review
|
|
12
|
+
agent: reviewer
|
|
13
|
+
task: >
|
|
14
|
+
Perform a thorough code review of recent changes for: {task}.
|
|
15
|
+
Check for bugs, correctness, readability, architecture fit, error handling,
|
|
16
|
+
test coverage, and adherence to project standards.
|
|
17
|
+
Return a concise report starting with `### Code Review`:
|
|
18
|
+
findings, severity, affected files, and recommended fixes.
|
|
19
|
+
|
|
20
|
+
- id: security-audit
|
|
21
|
+
agent: reviewer
|
|
22
|
+
task: >
|
|
23
|
+
Security audit focused on: {task}.
|
|
24
|
+
Check for:
|
|
25
|
+
- Injection vulnerabilities
|
|
26
|
+
- Authentication/authorization issues
|
|
27
|
+
- Sensitive data exposure
|
|
28
|
+
- Dependency vulnerabilities
|
|
29
|
+
- Unsafe code patterns
|
|
30
|
+
Return a concise report starting with `### Security Audit`:
|
|
31
|
+
vulnerabilities, severity, evidence, and remediation priority.
|
|
32
|
+
|
|
33
|
+
- id: stability-check
|
|
34
|
+
agent: worker
|
|
35
|
+
task: >
|
|
36
|
+
Run the full project test suite using the existing package manager or test scripts.
|
|
37
|
+
Report:
|
|
38
|
+
- Total tests passed/failed
|
|
39
|
+
- Any flaky or slow tests
|
|
40
|
+
- Test duration
|
|
41
|
+
- Code coverage if available
|
|
42
|
+
- Commands attempted and blockers
|
|
43
|
+
Project context: {task}
|
|
44
|
+
Return a concise report starting with `### Stability Check`.
|
|
45
|
+
|
|
46
|
+
- id: release-readiness
|
|
47
|
+
agent: reviewer
|
|
48
|
+
task: >
|
|
49
|
+
Based on the following reports, assess overall release readiness for: {task}.
|
|
50
|
+
|
|
51
|
+
Code Review: {outputs.code-review}
|
|
52
|
+
Security Audit: {outputs.security-audit}
|
|
53
|
+
Stability: {outputs.stability-check}
|
|
54
|
+
|
|
55
|
+
Give:
|
|
56
|
+
1. Overall readiness score (1-10)
|
|
57
|
+
2. Blocking issues that must be fixed before release
|
|
58
|
+
3. Recommended issues to fix soon
|
|
59
|
+
4. Clear Go/No-Go recommendation
|
|
60
|
+
5. Short rationale
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
name: tdd-review
|
|
2
|
+
description: "Full TDD cycle with test quality and code review gates — ideal for new features or refactoring."
|
|
3
|
+
report:
|
|
4
|
+
agent: planner
|
|
5
|
+
focus: "TDD cycle outcomes, test quality, and implementation readiness"
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
stages:
|
|
9
|
+
- id: analyze
|
|
10
|
+
agent: planner
|
|
11
|
+
task: >
|
|
12
|
+
Analyze the codebase and create a step-by-step implementation plan for: {task}.
|
|
13
|
+
Include acceptance criteria, test strategy, edge cases, architecture decisions,
|
|
14
|
+
likely files to change, risks, and unknowns.
|
|
15
|
+
If the task is ambiguous or important context is missing, say so explicitly.
|
|
16
|
+
|
|
17
|
+
- id: write-tests
|
|
18
|
+
agent: worker
|
|
19
|
+
task: >
|
|
20
|
+
Write tests according to this plan: {outputs.analyze}.
|
|
21
|
+
Cover happy paths, error paths, boundary values, and edge cases.
|
|
22
|
+
Use the project's existing test framework and conventions.
|
|
23
|
+
Do not modify production code in this stage.
|
|
24
|
+
After writing tests, report changed files and the commands needed to run them.
|
|
25
|
+
gate:
|
|
26
|
+
type: review-loop
|
|
27
|
+
maxRounds: 3
|
|
28
|
+
targetScore: 9
|
|
29
|
+
reviewers:
|
|
30
|
+
- focus: "Do the tests cover ALL scenarios, acceptance criteria, and edge cases from the plan? Identify any missing cases."
|
|
31
|
+
- focus: "Are tests production-ready: isolated, deterministic, maintainable, and following project conventions?"
|
|
32
|
+
- focus: "Are error paths, boundary values, async/failure behavior, and unusual inputs covered where relevant?"
|
|
33
|
+
|
|
34
|
+
- id: implement
|
|
35
|
+
agent: worker
|
|
36
|
+
task: >
|
|
37
|
+
Implement the code to make these tests pass: {outputs.write-tests}.
|
|
38
|
+
Follow the plan: {outputs.analyze}.
|
|
39
|
+
Keep changes minimal, focused, and consistent with project conventions.
|
|
40
|
+
Do not modify tests unless a test is clearly wrong; if you modify a test, explain why.
|
|
41
|
+
|
|
42
|
+
gate:
|
|
43
|
+
type: review-loop
|
|
44
|
+
maxRounds: 3
|
|
45
|
+
targetScore: 8
|
|
46
|
+
reviewers:
|
|
47
|
+
- focus: "Does the implementation satisfy all acceptance criteria and make the intended tests pass?"
|
|
48
|
+
- focus: "Is the code simple, readable, well-structured, and consistent with existing project patterns?"
|
|
49
|
+
- focus: "Does the implementation handle errors and edge cases without overengineering or hidden behavior?"
|
|
50
|
+
|
|
51
|
+
- id: verify
|
|
52
|
+
agent: worker
|
|
53
|
+
task: >
|
|
54
|
+
Run ALL tests in the project using the existing package manager or test scripts.
|
|
55
|
+
Report:
|
|
56
|
+
1. Which tests pass and fail
|
|
57
|
+
2. Any regressions introduced
|
|
58
|
+
3. Coverage if available
|
|
59
|
+
4. Commands attempted and any blockers
|
|
60
|
+
Implementation context: {outputs.implement}
|
|
61
|
+
|
|
62
|
+
- id: propose-next
|
|
63
|
+
parallel:
|
|
64
|
+
- id: next-steps
|
|
65
|
+
agent: oracle
|
|
66
|
+
task: >
|
|
67
|
+
Based on the current project state, test results: {outputs.verify},
|
|
68
|
+
and this completed task ({task}),
|
|
69
|
+
what are the 3 most impactful things to work on next?
|
|
70
|
+
Consider technical debt, user-facing features, and architecture improvements.
|
|
71
|
+
Return exactly 3 prioritized next steps with rationale.
|
|
72
|
+
|
|
73
|
+
- id: risks
|
|
74
|
+
agent: reviewer
|
|
75
|
+
task: >
|
|
76
|
+
Review the project state after this change: {outputs.verify}.
|
|
77
|
+
What risks, bottlenecks, or areas need attention before continuing?
|
|
78
|
+
Return a concise risk report with severity.
|