script-dev
Skill0 starsChanged 6 months agoMITView on GitHub
TDD pipeline for vallorcine scripts (bash/python/node)
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 11 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Use /ideate instead when:
- Distinctive: line 26
Read the description and determine:
- Distinctive: line 34
Read the affected files and their test files before proceeding.
- Very specific: line 65
Add test cases to the appropriate tests/scenario-*.sh file.
- Very specific: line 88
Use /tmp/vallorcine/* paths (pre-granted permissions)
- Distinctive: line 89
Test all three language implementations if applicable
- Distinctive: line 90
Test malformed/corrupt input gracefully handled (exit 0, no crash)
- Distinctive: line 91
Test backwards compatibility with legacy shell variable format if touching state files
- Distinctive: line 95
Run the test file and confirm new tests fail (they test behavior that doesn't exist yet):
- Distinctive: line 119
Always implement in this order:
- Very specific: line 138
Atomic writes: Write to .tmp then rename() / mv.
- Very specific: line 141
ANSI output: Use \\033[NNm (double-escaped) in Python/Node output strings.
- Very specific: line 145
Error handling: All scripts must exit 0 on any error.
- Very specific: line 149
Wrappers: Every user-facing script has a wrapper at scripts/<name>-wrapper.sh that detects runtimes and delegates: python3 → node → bash.
- Distinctive: line 178
After all tests pass, perform a self-review against these criteria:
- Distinctive: line 225
Run the full test suite:
- Distinctive: line 231
All tests must pass. Display the final count.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/script-dev "<description>"
Dev-only TDD pipeline for vallorcine script work. Follows the same test-first discipline as /feature-quick but specialized for the multi-language hook/script pattern used throughout this repo.
Use this when:
- Adding or modifying scripts in
scripts/ - Adding or modifying hooks (statusline, stop hook, subagent hook, etc.)
- Changes that need bash + Python + Node.js implementations
- Changes to install.sh, MANIFEST, or settings.json hook registration
Use /ideate instead when:
- The work is broader than scripts (skills, agents, rules, etc.)
- You're designing something new that needs discussion first
Step 1 — Understand the change
Read the description and determine:
- Which scripts are affected? List every file in
scripts/that will change. - Is this a new script or a modification? New scripts need all three implementations + wrapper + MANIFEST + install.sh entries.
- Which test file covers this? Usually
tests/scenario-*.shortests/test-install.sh.
Read the affected files and their test files before proceeding.
Display a brief summary:
SCRIPT DEV — <description>
─────────────────────────────────────────────
Files: <list of scripts to modify/create>
Tests: <test file(s)>
Languages: bash / python / node (or subset)
─────────────────────────────────────────────
Type **yes** to proceed · or: adjustStep 2 — Write tests first
This step is mandatory. No implementation before tests.
2a — Identify test scenarios
For each script change, identify:
- Happy path (normal operation)
- Edge cases (empty input, missing files, malformed state)
- Backwards compatibility (if changing state file formats)
- Cross-implementation parity (if bash/python/node must produce identical output)
- Error handling (permission errors, missing directories, corrupt data)
2b — Write the tests
Add test cases to the appropriate tests/scenario-*.sh file. Follow the
existing pattern:
# ── Test N: <description> ─────────────────────────────────────────
echo ""
echo " testing: <category>"
# Setup
<prepare state>
# Execute
(cd "$PROJECT_PATH" && <run script>)
# Assert
if <condition>; then
pass "<description>"
else
fail "<description>" "<diagnostic>"
fiTest requirements:
- Use
/tmp/vallorcine/*paths (pre-granted permissions) - Test all three language implementations if applicable
- Test malformed/corrupt input gracefully handled (exit 0, no crash)
- Test backwards compatibility with legacy shell variable format if touching state files
2c — Verify tests fail
Run the test file and confirm new tests fail (they test behavior that doesn't exist yet):
bash tests/<test-file>.shShow the failure output. If tests pass before implementation, they're not testing the right thing — rewrite them.
Display:
TESTS WRITTEN — <N> new tests, all failing as expected
─────────────────────────────────────────────
Type **yes** to proceed to implementation · or: adjust testsStep 3 — Implement
Multi-language implementation order
Always implement in this order:
- Bash first — the fallback that must always work. No jq required for
flat JSON objects (use
grep -o/sedpatterns). Shell variable backwards-compat via_is_jsondetection. - Python second — stdlib only (
json,sys,os,pathlib,datetime). No pip dependencies. Must produce identical side effects (state files, log entries, ANSI output) as bash. - Node.js third — stdlib only (
fs,path,os,process). No npm dependencies. Must produce identical side effects as bash and Python.
Script conventions
State files: JSON format. Flat objects only — no nesting beyond one level.
Bash reads via grep -o '"key":"[^"]*"' | cut -d'"' -f4. Always detect legacy
shell variable format with _is_json and read it if found.
Atomic writes: Write to .tmp then rename() / mv. Prevents partial
reads by concurrent hooks.
ANSI output: Use \\033[NNm (double-escaped) in Python/Node output strings.
The wrapper scripts call echo -e which interprets them. This matches how bash
echo -e works natively.
Error handling: All scripts must exit 0 on any error. Hooks that crash with
nonzero exit may block Claude Code. Wrap filesystem operations in try/catch
(Python: try/except OSError, Node: try {} catch {}).
Wrappers: Every user-facing script has a wrapper at
scripts/<name>-wrapper.sh that detects runtimes and delegates:
python3 → node → bash. Wrappers catch errors from enhanced implementations
and fall back silently.
Implementation checklist
For each script:
- Bash implementation works without jq (for JSON state files)
- Python implementation uses only stdlib
- Node.js implementation uses only stdlib
- All three produce identical side effects (files written, content format)
- All three exit 0 on any error condition
- Atomic writes for state files (
.tmp+ rename) - Backwards-compat: reads legacy shell variable format if detected
- Wrapper delegates correctly
Run tests after each implementation
bash tests/<test-file>.shFix failures before moving to the next language.
Step 4 — Review
After all tests pass, perform a self-review against these criteria:
Performance review
Scripts run on every assistant message (statusline) or every response (stop hook). They must be fast.
- No unnecessary file reads — don't read a file twice when one read suffices (e.g., return line count from usage parsing, don't re-read)
- No unnecessary stat calls —
existsSyncbeforereadFileSyncis redundant if the read has a try/catch - Use
max()notsorted()when only the most recent file is needed - Avoid spawning subprocesses — no
child_process.execin Node, nosubprocess.runin Python. Pure stdlib file I/O only. - Target: <10ms for statusline, <5ms for no-op stop hook path
Memory and resource review
- No unbounded reads — don't slurp entire large files into memory when
line-by-line streaming works (Python: iterate file object, Node: be aware
that
readFileSyncloads the full file) - No accumulation — scripts run and exit, no long-lived state. But within a run, don't build arrays of all transcript entries when only a sum is needed.
- Close file handles — use
within Python, don't hold open FDs
Correctness review
- Race conditions — state file reads/writes across concurrent hooks. Atomic writes mitigate but don't eliminate. Document any remaining windows.
- Path assumptions — hooks run from project root (
cwd). Don't assume subdirectory or absolute paths unless reading from state. - Integer arithmetic —
parseIntalways with radix 10 in Node. Token counts can exceed 32-bit — use standard Number (safe to 2^53).
Distribution review (if new files added)
- MANIFEST updated with all new script paths
- install.sh copies new files and registers any new hooks
- settings.json uses wrapper scripts, not direct implementations
- .gitignore includes any new runtime state files
- tests/test-install.sh asserts new files are installed
Step 5 — Final verification
Run the full test suite:
bash tests/scenario-token-tracking.sh && bash tests/test-install.shAll tests must pass. Display the final count.
SCRIPT DEV COMPLETE
─────────────────────────────────────────────
Tests: <N> passed, 0 failed
Files: <list of files changed/created>
─────────────────────────────────────────────In this repository45 other files it gives its agents.
- decisions/CLAUDE.mdCLAUDE.md
- kb/CLAUDE.mdCLAUDE.md
- spec/CLAUDE.mdCLAUDE.md
- work/CLAUDE.mdCLAUDE.md
- architectSkill
- auditSkill
- capabilitiesSkill
- curateSkill
- decisionsSkill
- feature-cleanupSkill
- feature-completeSkill
- feature-coordinateSkill
- feature-domainsSkill
- feature-hardenSkill
- feature-implementSkill
- feature-planSkill
- feature-prSkill
- feature-quickSkill
- feature-refactorSkill
- feature-resumeSkill
- feature-retroSkill
- featureSkill
- feature-testSkill
- kbSkill
- project-contextSkill
- researchSkill
- setup-vallorcineSkill
- spec-authorSkill
- spec-backfillSkill
- spec-initSkill
- spec-resolveSkill
- specSkill
- spec-splitSkill
- spec-verifySkill
- spec-writeSkill
- uninstall-vallorcineSkill
- upgrade-vallorcineSkill
- vallorcine-helpSkill
- work-decomposeSkill
- work-planSkill
- work-resumeSkill
- work-runSkill
- workSkill
- work-startSkill
- work-statusSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

