github-integration
starsforks
How to install github-integration?
dnyoussef/context-cascade/github-integration
$npx -y skills add DNYoussef/context-cascade --skill github-integrationBuild reliable GitHub integrations, webhooks, and automation bridges
SKILL.md
| 1 | --- |
| 2 | |
| 3 | ## LIBRARY-FIRST PROTOCOL (MANDATORY) |
| 4 | |
| 5 | **Before writing ANY code, you MUST check:** |
| 6 | |
| 7 | ### Step 1: Library Catalog |
| 8 | - Location: `.claude/library/catalog.json` |
| 9 | - If match >70%: REUSE or ADAPT |
| 10 | |
| 11 | ### Step 2: Patterns Guide |
| 12 | - Location: `.claude/docs/inventories/LIBRARY-PATTERNS-GUIDE.md` |
| 13 | - If pattern exists: FOLLOW documented approach |
| 14 | |
| 15 | ### Step 3: Existing Projects |
| 16 | - Location: `D:\Projects\*` |
| 17 | - If found: EXTRACT and adapt |
| 18 | |
| 19 | ### Decision Matrix |
| 20 | | Match | Action | |
| 21 | |-------|--------| |
| 22 | | Library >90% | REUSE directly | |
| 23 | | Library 70-90% | ADAPT minimally | |
| 24 | | Pattern exists | FOLLOW pattern | |
| 25 | | In project | EXTRACT | |
| 26 | | No match | BUILD (add to library after) | |
| 27 | |
| 28 | --- |
| 29 | |
| 30 | ## STANDARD OPERATING PROCEDURE |
| 31 | |
| 32 | ### Purpose |
| 33 | Design and implement GitHub-centric integrations (API, Apps, webhooks) with secure auth, observability, and rollback-ready automation. |
| 34 | |
| 35 | ### Trigger Conditions |
| 36 | - **Positive:** Need GitHub automation or webhook bridge; Integrating GitHub with external systems; Auditable GitHub API usage across repos |
| 37 | - **Negative:** Release orchestration (route to github-release-management); Cross-repo campaign (route to github-multi-repo); Project board design (route to github-project-management) |
| 38 | |
| 39 | ### Guardrails |
| 40 | - Structure-first: keep SKILL.md aligned with examples/, tests/, and any resources/references so downstream agents always have scaffolding. |
| 41 | - Adversarial validation is mandatory: cover boundary cases, failure paths, and rollback drills before declaring the SOP complete. |
| 42 | - Prompt hygiene: separate hard vs. soft vs. inferred constraints and confirm inferred constraints before acting. |
| 43 | - Explicit confidence ceilings: format as 'Confidence: X.XX (ceiling: TYPE Y.YY)' and never exceed the ceiling for the claim type. |
| 44 | - MCP traceability: tag sessions WHO=operations-{name}-{session_id}, WHY=skill-execution, and capture evidence links in outputs. |
| 45 | - Avoid anti-patterns: undocumented changes, missing rollback paths, skipped tests, or unbounded automation without approvals. |
| 46 | |
| 47 | ### Required Artifacts |
| 48 | - SKILL.md (this SOP) |
| 49 | - readme.md with usage examples |
| 50 | - examples/ for integration flows |
| 51 | - tests/ for scripts/actions |
| 52 | - resources/ and shared-scripts/ for reuse |
| 53 | - references/ with API constraints |
| 54 | |
| 55 | ### Execution Phases |
| 56 | 1. **Assess integration surface** |
| 57 | - Map repos, events, and permissions required |
| 58 | - Confirm auth model (GitHub App, PAT, OIDC) and rotation plan |
| 59 | - Identify rate limits and audit requirements |
| 60 | |
| 61 | 2. **Design event and API flows** |
| 62 | - Define webhook payload handling, retries, and signature validation |
| 63 | - Specify idempotency, deduplication, and backoff policies |
| 64 | - Plan data mapping and error handling between systems |
| 65 | |
| 66 | 3. **Implement automation** |
| 67 | - Build or reuse scripts/actions with least privilege |
| 68 | - Add logging/metrics and sandbox tests |
| 69 | - Gate production rollout with dry runs and approvals |
| 70 | |
| 71 | 4. **Validate and operate** |
| 72 | - Run integration tests and failure-injection scenarios |
| 73 | - Set up monitoring, alerts, and dashboards |
| 74 | - Document runbooks, fallbacks, and support contacts |
| 75 | |
| 76 | ### Output Format |
| 77 | - Integration design doc with events, permissions, and rate-limit posture |
| 78 | - Auth and secret management plan with rotation cadence |
| 79 | - Implemented automation artifacts (scripts/actions) with test evidence |
| 80 | - Monitoring and alert plan with dashboards/links |
| 81 | - Runbook with rollback/disablement steps and owners |
| 82 | |
| 83 | ### Validation Checklist |
| 84 | - Tokens/keys scoped to least privilege and rotated |
| 85 | - Webhook verification, retries, and idempotency tested |
| 86 | - Integration tested in staging or dry-run mode |
| 87 | - Audit trail and observability hooks enabled |
| 88 | - Confidence ceiling stated for go-live |
| 89 | |
| 90 | Confidence: 0.70 (ceiling: inference 0.70) - GitHub integration steps follow validated automation guardrails |
People who liked this also viewed
6 picksType
- caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026
- git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026
