Parnell Systems
View on GitHub
Skills Library
Reusable instructions that make
Claude better on every project
Each skill is a folder Claude Code loads when triggered. They encode hard-won patterns — things corrected, approaches that worked, rules that should apply everywhere.
9Skills
5Categories
55+Trigger phrases
All 🌟 Global 📦 Project Code Quality Frontend Workflow SaaS Engagement
End-to-End Feature Test
e2e-feature-test
🧪 global code
Full end-to-end feature testing — generates an exhaustive test matrix, drives the browser UI via agent-browser, verifies backend state (database, API responses), and produces a pass/fail report. Use after building a feature with both frontend and backend components. Triggers on 'test this feature end to end', 'e2e test', 'full feature test', 'usability test this', 'test the whole feature', 'browser and backend test'.
Triggers on
e2e test end to end test full feature test usability test test the whole feature browser and backend test
Rules
Never claim a test passes without screenshot or command output evidence
Always verify backend state after frontend actions (database, API, logs)
Re-snapshot after every navigation or DOM mutation
Test both happy path AND failure/edge cases
Close the browser session when done
GitHub Pages Portal
github-pages-portal
🌐 project tooling
Self-updating GitHub Pages knowledge portal. Folders become pages, markdown frontmatter becomes cards, GitHub Actions regenerate HTML on every push.
Triggers on
add this to the portal update the portal make pages update automatically new portal section
Key patterns
Shared portal.css design system
Frontmatter-driven card generation
GitHub Action regenerates on every push
Changelog live from GitHub API
Plan Progress Tracker
plan-tracker
🗺 global workflow
>
Triggers on
show me plan progress where are we in the plan plan tracker visual progress update the plan diagram how are we tracking
Process
Read the plan markdown file and extract all workstreams, tasks, and completion markers
Cross-reference with memory files for any completed items not yet checked off in the plan
Generate a self-contained HTML file in docs/diagrams/ following the existing dark-theme diagram pattern
Each workstream is a coloured phase card showing task count, completion percentage, and individual task status
Use green for done, amber for in-progress, and slate for not-started
Include a summary bar at the top with overall completion percentage
Commit and push to update the portal automatically
After generating, use the skill-publisher skill to update the portal
Project Documentation Standard
project-docs-standard
📚 global workflow
Mandatory documentation structure for every project. Ensures consistent docs/ folder with requirements, design, plans, tracking, user guides, API reference, decisions, and a project portal page. Enforced during ce:plan and ce:work.
Triggers on
new project project setup create project docs docs structure documentation standard set up docs project kickoff
Required docs
docs/index.html — project portal page (Deep Ocean Tech design)
docs/requirements/ — PRDs, feature specs, acceptance criteria
docs/design/ — architecture diagrams, system design, data models
docs/plans/ — build plans with implementation waves
docs/diagrams/ — visual progress tracking (plan-tracker output)
docs/user-guide/ — end-user documentation and onboarding
docs/api/ — API reference, endpoints, schemas (if applicable)
docs/decisions/ — per-project architecture decision records
docs/brainstorms/ — discovery notes, alternatives considered
CHANGELOG.md — what shipped and when
SaaS Automation Engagement
saas-automation-engagement
📄 project engagement
End-to-end playbook for new client automation engagements — from feasibility through discovery, architecture, technical spec, proposal, documentation, and Claude Code handoff.
Triggers on
new client engagement build a proposal automation project scope this work new client project client onboarding
Phases
Feasibility and API check
Discovery and requirements (→ docs/requirements/)
Architecture and design (→ docs/design/)
Technical spec + SOW + Proposal
Build plan (→ docs/plans/ via ce:plan)
Project portal setup (→ docs/index.html)
Testing framework and Claude Code handoff
User guide scaffolding (→ docs/user-guide/)
SaaS Patterns
saas-patterns
🚀 project saas
Production-grade SaaS patterns. Tenant isolation, plan gating, usage tracking, idempotent ops, soft deletes, and onboarding principles.
Triggers on
add a new feature design this API build the onboarding flow add usage limits
Core rules
Every query scoped to orgId
Feature flags from day one
Idempotent webhooks and jobs
Soft delete — never hard delete
Security Review
security-review
🔒 global code
Comprehensive security review for web applications. Use when implementing auth, handling user input, working with secrets, creating API endpoints, or touching sensitive features. Covers OWASP Top 10, secrets management, input validation, SQL injection, XSS, CSRF, and rate limiting. Adapted from everything-claude-code.
Triggers on
security review is this secure authentication handling user input API endpoint secrets vulnerability OWASP
Rules
No hardcoded secrets — all in environment variables
All user inputs validated with schemas (whitelist, not blacklist)
All database queries use parameterised queries — no string concatenation
Tokens stored in httpOnly cookies, not localStorage
Authorisation checks before every sensitive operation
User-provided HTML sanitised before rendering
CSRF tokens on state-changing operations
Rate limiting on all API endpoints
Error messages never expose internal details
No secrets or sensitive data in logs
Dependencies checked for known vulnerabilities
Systematic Debugging
systematic-debugging
🔍 global code
Root-cause-first debugging methodology. Use when encountering any bug, test failure, or unexpected behaviour — before proposing fixes. Enforces evidence gathering, pattern analysis, hypothesis testing, and defence-in-depth validation. Adapted from obra/superpowers.
Triggers on
bug test failure unexpected behaviour debugging why is this broken it doesn't work fix this
Rules
No fixes without root cause investigation first
Read error messages completely before acting
Reproduce consistently before hypothesising
One hypothesis at a time — smallest possible change
Create a failing test before implementing a fix
If 3+ fixes fail, question the architecture
Trace bugs backward through the call stack to find the source
Add defence-in-depth validation at every layer
Verification Before Completion
verification-before-completion
✅ global code
Prevents premature completion claims. Use before claiming work is done, fixed, or passing — requires running verification commands and confirming output before making any success assertions. Evidence before claims, always. Adapted from obra/superpowers.
Triggers on
done fixed tests pass it works ready for review complete all good
Rules
No completion claims without fresh verification evidence
Run the actual verification command in this message before claiming success
Read full output and check exit code
Never use "should", "probably", or "seems to" for status claims
No expressing satisfaction before verification
Verify agent-delegated work independently
Check requirements line-by-line, not just test results