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.
53 lines
1.3 KiB
Markdown
53 lines
1.3 KiB
Markdown
---
|
|
name: clean-comments
|
|
description: Use when writing, fixing, editing, or reviewing Python comments and docstrings. Enforces Clean Code principles—no metadata, no redundancy, no commented-out code.
|
|
---
|
|
|
|
# Clean Comments
|
|
|
|
## C1: No Inappropriate Information
|
|
|
|
Comments shouldn't hold metadata. Use Git for author names, change history,
|
|
ticket numbers, and dates. Comments are for technical notes about code only.
|
|
|
|
## C2: Delete Obsolete Comments
|
|
|
|
If a comment describes code that no longer exists or works differently,
|
|
delete it immediately. Stale comments become "floating islands of
|
|
irrelevance and misdirection."
|
|
|
|
## C3: No Redundant Comments
|
|
|
|
```python
|
|
# Bad - the code already says this
|
|
i += 1 # increment i
|
|
user.save() # save the user
|
|
|
|
# Good - explains WHY, not WHAT
|
|
i += 1 # compensate for zero-indexing in display
|
|
```
|
|
|
|
## C4: Write Comments Well
|
|
|
|
If a comment is worth writing, write it well:
|
|
- Choose words carefully
|
|
- Use correct grammar
|
|
- Don't ramble or state the obvious
|
|
- Be brief
|
|
|
|
## C5: Never Commit Commented-Out Code
|
|
|
|
```python
|
|
# DELETE THIS - it's an abomination
|
|
# def old_calculate_tax(income):
|
|
# return income * 0.15
|
|
```
|
|
|
|
Who knows how old it is? Who knows if it's meaningful? Delete it.
|
|
Git remembers everything.
|
|
|
|
## The Goal
|
|
|
|
The best comment is the code itself. If you need a comment to explain
|
|
what code does, refactor first, comment last.
|