ZacharyZhang-NY
e74dafcd36
Three independently ugly bugs that all fed the same log flood:
* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
to stderr via `console.error`. When the worker fans a second
agent-event past a reloading renderer, we produced thousands of
identical lines and stalled the main loop on stderr I/O. Added a
`mainFrame.detached` guard so the send is short-circuited before
Electron's own catch block fires, and installed a targeted filter in
`suppress-warnings.ts` (now actually imported from the entry point)
so the specific `console.error("Error sending from webFrameMain:"…)`
noise never reaches the terminal. Any other payload still surfaces.
* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
target when an agent replied to `__board__` — `wakeAgentIfPossible`
then called `db.getAgent("__board__")`, threw, and the dispatcher
kept repeating on every send. Strip `HUMAN_SENDER_ID` at
`resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
heartbeat so a stray caller (future automation fan-out) cannot
reintroduce the crash.
* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
diverges from its parent directory. The four bundled `my-writing-style`
copies declared `name: writing-style-skill`, so every install emitted
a warning and dropped the skill. They also lived as orphan gitlinks
(mode 160000 without .gitmodules), and the global `*.md` gitignore
hid every other SKILL.md from version control. Fixed the frontmatter
to match the dir, converted the dangling submodules to plain trees,
and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
catalogue instead of silently losing it.
37 lines
3.1 KiB
Markdown
37 lines
3.1 KiB
Markdown
---
|
|
name: optimize-cicd-pipeline
|
|
description: Analyzes CI/CD pipelines to identify common antipatterns (like slow feedback loops or sequential steps) and recommends best practice patterns (like build images, parallelization, and build-once-deploy-anywhere). Use when designing, auditing, or troubleshooting CI/CD workflows to improve speed and reliability.
|
|
---
|
|
|
|
# Optimize CI/CD Pipeline
|
|
|
|
This skill provides a framework for auditing and improving CI/CD pipelines. The primary goal of any pipeline optimization is to **shorten the feedback loop**. The faster a developer knows something is wrong, the cheaper it is to fix.
|
|
|
|
## Usage Instructions
|
|
|
|
When analyzing a pipeline configuration or advising on DevOps practices, compare the user's current setup against the Antipatterns below. If an antipattern is detected, recommend the corresponding Pattern.
|
|
|
|
### 1. Core Philosophy Checklist
|
|
- [ ] **Feedback Loop**: Is the time from "commit" to "failure notification" under 10 minutes?
|
|
- [ ] **Reproducibility**: Can a developer run the exact same build command locally?
|
|
- [ ] **Maintenance**: Is the pipeline treated as a software product (versioned, refactored, maintained)?
|
|
|
|
### 2. Pattern Analysis
|
|
|
|
Use this table to diagnose issues and prescribe solutions:
|
|
|
|
| Detection (Antipattern) | Solution (Pattern) | Implementation Advice |
|
|
| :--- | :--- | :--- |
|
|
| **Installing tools on every run**<br>Build logs show repeated `npm install`, `apt-get install`, or downloading CLI tools. | **Use Build Images** | Pre-bake all dependencies into a Docker image. Use this image as the build agent/runner so the environment is instant. |
|
|
| **Sequential Steps**<br>Test, Lint, and Build run one after another. Total time = Sum of all steps. | **Parallelization (Fan-out)** | Run independent tasks simultaneously. Total time = Length of the slowest task. |
|
|
| **Rebuilding per Environment**<br>Code is compiled separately for "Test", "Staging", and "Prod". | **Build Once, Deploy Anywhere** | Build a single binary/artifact at the start. Promote that exact artifact through all environments to ensure consistency. |
|
|
| **Publishing on every run**<br>Artifact repository is flooded with broken or untested builds. | **Publish on Success** | Only push artifacts to the registry after all quality gates (linting, testing) have passed. |
|
|
| **Slow Feedback / Late Failures**<br>Syntax errors or linting issues are caught at the end of a long build. | **Fail Fast** | Reorder steps: Run the fastest checks (linting, unit tests) first. Do not run expensive integration tests if basic checks fail. |
|
|
| **"Works on My Machine"**<br>Pipeline fails but local build succeeds (or vice versa). | **Pipeline as Code** | Define infrastructure in code (Dockerfiles, YAML). Ensure local scripts match pipeline commands exactly. |
|
|
|
|
## Common Recommendations
|
|
|
|
1. **Target Time**: If a pipeline takes >15 minutes, productivity drops due to context switching. Aggressively optimize parallelization.
|
|
2. **Environment Consistency**: Never allow the CI server environment to drift from the developer's local environment.
|
|
3. **Drafting Pipelines**: Always start by defining the "Happy Path" (success state), then add the necessary gates to protect it.
|