@gokulkrishh/skills 0.1.0

package/README.md

@@ -0,0 +1,51 @@
+# Skills
+
+A collection of custom [Agent Skills](https://agentskills.io) for AI coding agents. Works with Claude Code, GitHub Copilot, Cursor, Cline, and more.
+
+## Skills
+
+| Skill                                            | Command    | Description                                                                                                                                     |
+| ------------------------------------------------ | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
+| [Model Council](./skills/model-council/SKILL.md) | `/council` | 4-agent debate system inspired by Grok 4.20's council. Agents (Captain, Scholar, Logician, Contrarian) analyze, debate, and synthesize answers. |
+| [Code Review](./skills/code-review/SKILL.md)     | `/review`  | Code review for security (OWASP), performance, accessibility, and code quality with severity-based findings.                                    |
+| [Commit](./skills/commit/SKILL.md)               | `/commit`  | Analyzes changes and creates a conventional commit with a clear title and description.                                                          |
+
+## Install
+
+### Via [skills.sh](https://skills.sh)
+
+```bash
+npx skills add https://github.com/gokulkrishh/skills
+```
+
+### Via Claude Code (Commands)
+
+Clone this repo and the commands are available via `.claude/commands/`:
+
+```bash
+/council Should I use RSC or client-side rendering for my app?
+/review https://github.com/user/repo/pull/42
+```
+
+### As npm Package
+
+```bash
+npm install @gokulkrishh/skills
+```
+
+```js
+import { getSkill } from '@gokulkrishh/skills'
+
+const prompt = getSkill('model-council')
+```
+
+## Creating a Skill
+
+1. Create a new directory in `skills/` with a `SKILL.md` file
+2. Add YAML frontmatter with `name` and `description` ([spec](https://agentskills.io/specification))
+3. Add a command file in `.claude/commands/` for Claude Code
+4. Register it in `index.js`
+
+## License
+
+MIT

package/index.js

@@ -0,0 +1,16 @@
+import { readFileSync } from 'fs'
+import { join, dirname } from 'path'
+import { fileURLToPath } from 'url'
+
+const __dirname = dirname(fileURLToPath(import.meta.url))
+
+export function getSkill(name) {
+  const skillPath = join(__dirname, 'skills', name, 'SKILL.md')
+  return readFileSync(skillPath, 'utf-8')
+}
+
+export const skills = {
+  'model-council': 'skills/model-council/SKILL.md',
+  'code-review': 'skills/code-review/SKILL.md',
+  'commit': 'skills/commit/SKILL.md',
+}

package/package.json

@@ -0,0 +1,27 @@
+{
+  "name": "@gokulkrishh/skills",
+  "version": "0.1.0",
+  "description": "Agent Skills for AI coding agents - model council, code review, and more",
+  "type": "module",
+  "main": "index.js",
+  "files": [
+    "skills/",
+    "index.js"
+  ],
+  "keywords": [
+    "agent-skills",
+    "claude-code",
+    "copilot",
+    "cursor",
+    "model-council",
+    "code-review",
+    "multi-agent",
+    "ai-skills"
+  ],
+  "author": "Gokulakrishnan Kalaikovan",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/gokulkrishh/skills"
+  }
+}

package/skills/code-review/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: code-review
+description: Reviews code for security (OWASP), performance, accessibility, and quality. Outputs findings by severity (Critical, Warning, Suggestion, Good) with a verdict. Use when reviewing code, diffs, or PRs.
+license: MIT
+metadata:
+  author: gokulkrishh
+  version: '0.1.0'
+---
+
+# Code Review
+
+A code review skill that checks for web security vulnerabilities, performance issues, accessibility problems, and code quality — then delivers structured feedback with severity levels.
+
+## Instructions
+
+**STEP 1 — GATHER CHANGES**
+
+Determine what to review:
+
+- If a GitHub PR URL is provided: fetch the PR diff and context
+- If a branch name is provided: diff it against the main branch
+- If file paths are provided: read those files directly
+- If nothing is provided: check for staged changes, then fall back to unstaged changes
+
+**STEP 2 — ANALYZE**
+
+Review the changes across these dimensions:
+
+**Security (OWASP Top 10):**
+
+- Injection flaws (SQL, XSS, command injection)
+- Broken authentication / authorization
+- Sensitive data exposure (hardcoded secrets, API keys, tokens)
+- Insecure dependencies (check for known CVEs if possible)
+- CSRF, open redirects (including client-side navigation to unvalidated URLs), unsafe deserialization
+
+**Performance:**
+
+- Unnecessary re-renders (React: missing memo, unstable refs in deps, missing key props in lists)
+- Bundle size impact (large imports, tree-shaking issues)
+- N+1 queries, unoptimized loops, missing pagination
+- Memory leaks (event listeners, subscriptions not cleaned up)
+- Lazy loading opportunities
+
+**Accessibility:**
+
+- Missing ARIA attributes, roles, or labels
+- Keyboard navigation issues
+- Color contrast, focus management
+- Semantic HTML usage
+
+**Code Quality:**
+
+- Type safety issues (TypeScript)
+- Error handling gaps
+- Dead code, unused imports
+- Naming clarity, readability
+- Test coverage for new logic
+
+**STEP 3 — REPORT**
+
+Output the review in this format:
+
+```
+## Code Review
+
+### Summary
+[1-2 sentence overview of the changes and overall assessment]
+
+### Findings
+
+#### 🔴 Critical
+[Issues that MUST be fixed before merging — security vulnerabilities, data loss risks, breaking bugs]
+
+#### 🟡 Warning
+[Issues that SHOULD be fixed — performance problems, accessibility gaps, potential bugs]
+
+#### 🔵 Suggestion
+[Nice-to-haves — code style improvements, minor optimizations, better patterns]
+
+#### ✅ Good
+[Things done well worth calling out — encouragement for good patterns]
+
+### Verdict: [APPROVE | REQUEST CHANGES | NEEDS DISCUSSION]
+```
+
+## Rules
+
+- Every finding must reference the specific file and line number. If code is provided inline (not from a file), reference the relevant line within the snippet
+- Include a concrete fix or code suggestion for each Critical and Warning item
+- If there are no findings in a severity category, omit that category
+- Be direct and specific — no vague feedback like "consider improving this"
+- If the diff is clean with no issues, say so and approve
+- For security findings, explain the attack vector briefly so the author understands the risk

package/skills/code-review/evals/evals.json

@@ -0,0 +1,39 @@
+{
+  "skill_name": "code-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Review this Express endpoint: app.get('/user', (req, res) => { const id = req.query.id; db.query('SELECT * FROM users WHERE id = ' + id); })",
+      "expected_output": "A review that catches the SQL injection vulnerability as Critical, with a fix suggestion using parameterized queries.",
+      "assertions": [
+        "SQL injection is flagged as Critical",
+        "The attack vector is briefly explained",
+        "A concrete fix using parameterized queries is suggested",
+        "The specific file and line are referenced",
+        "A verdict of REQUEST CHANGES is given"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Review my changes on the current branch",
+      "expected_output": "The skill gathers the diff from the current branch, analyzes it, and outputs structured findings with severity levels.",
+      "assertions": [
+        "The review includes a Summary section",
+        "Findings are organized by severity (Critical, Warning, Suggestion, Good)",
+        "A Verdict is given (APPROVE, REQUEST CHANGES, or NEEDS DISCUSSION)",
+        "Empty severity categories are omitted"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Review this React component: function UserList({ users }) { return <div>{users.map(u => <div onClick={() => window.location = u.website}>{u.name}</div>)}</div> }",
+      "expected_output": "Catches accessibility issues (no semantic HTML, no keyboard handling) and potential XSS via unvalidated URL redirect.",
+      "assertions": [
+        "Missing semantic HTML is flagged (div instead of ul/li or button)",
+        "Keyboard accessibility issue is identified (onClick without keyboard handler)",
+        "The unvalidated URL redirect is flagged as a security concern",
+        "Missing key prop on mapped elements is noted"
+      ]
+    }
+  ]
+}

package/skills/commit/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: commit
+description: Generates a conventional commit (conventionalcommits.org) with a clear title and description based on staged or unstaged changes. Analyzes the diff to determine the type, scope, and whether it's a breaking change. Use when the user wants to commit code changes.
+license: MIT
+metadata:
+  author: gokulkrishh
+  version: '0.1.0'
+---
+
+# Commit
+
+Analyzes code changes and creates a [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) compliant git commit.
+
+## Instructions
+
+**STEP 1 — GATHER CHANGES**
+
+- Run `git status` to see what files have changed
+- Run `git diff --staged` to see staged changes
+- If nothing is staged, run `git diff` for unstaged changes and stage them
+- Run `git log --oneline -5` to understand the repo's commit style
+
+**STEP 2 — ANALYZE**
+
+Determine:
+
+- The **type** of change (see types below)
+- The **scope** — which module, component, or area is affected (always include when one can be reasonably determined)
+- Whether this is a **breaking change**
+- The "why" behind the change, not just the "what"
+
+**STEP 3 — COMMIT**
+
+Create the commit following the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification:
+
+```
+<type>(<scope>): <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Format
+
+- **Title line:** `<type>(<scope>): <description>` — under 70 characters
+- **Body:** Explain why the change was made, with brief context on what changed. 1-3 lines. Separate from title with a blank line. Always include a body for non-trivial commits.
+- **Breaking changes:** Add `BREAKING CHANGE:` in the footer, or `!` after the type/scope (e.g. `feat!:` or `feat(api)!:`)
+
+### Types
+
+- `feat` — new feature (correlates with MINOR in SemVer)
+- `fix` — bug fix (correlates with PATCH in SemVer)
+- `docs` — documentation only
+- `style` — formatting, whitespace, semicolons (no code change)
+- `refactor` — code change that neither fixes a bug nor adds a feature
+- `perf` — performance improvement
+- `test` — adding or updating tests
+- `build` — build system or external dependencies
+- `ci` — CI configuration and scripts
+- `chore` — other changes that don't modify src or test files
+
+### Examples
+
+Simple:
+
+```
+feat(auth): add OAuth2 login flow
+```
+
+With body:
+
+```
+fix(parser): handle empty input without crashing
+
+Previously the parser would throw a NullPointerException when given
+an empty string. Now it returns an empty result set.
+```
+
+Breaking change:
+
+```
+feat(api)!: remove deprecated /users endpoint
+
+BREAKING CHANGE: The /users endpoint has been removed.
+Use /v2/users instead.
+```
+
+**STEP 4 — SUMMARY**
+
+After committing, show a summary:
+
+```
+Committed: <commit hash>
+Branch: <branch name>
+Files: <number of files changed>
+
+<commit title>
+
+<commit body>
+```
+
+## Rules
+
+- Title must be under 70 characters
+- Title should be imperative mood ("add feature" not "added feature")
+- Description should be lowercase, no period at the end
+- Body should explain why the change was made, not just restate the title
+- Do not commit files that look like secrets (.env, credentials, tokens)
+- If there are no changes to commit, say so and stop
+- Stage specific files, not `git add .` or `git add -A`
+- Use `!` or `BREAKING CHANGE:` footer for breaking changes

package/skills/commit/evals/evals.json

@@ -0,0 +1,38 @@
+{
+  "skill_name": "commit",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I just added a new login page component, commit it for me",
+      "expected_output": "A conventional commit with type feat, a scope related to auth/login, imperative mood title under 70 chars, and a body explaining why.",
+      "assertions": [
+        "The commit message starts with a valid type (feat, fix, docs, style, refactor, perf, test, build, ci, chore)",
+        "The title line is under 70 characters",
+        "The title uses imperative mood",
+        "The description is lowercase with no period at the end",
+        "A post-commit summary is shown with commit hash, branch, and file count"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "commit my changes",
+      "expected_output": "The skill analyzes the diff, determines the correct type and scope, and creates a well-formed conventional commit without needing more context from the user.",
+      "assertions": [
+        "The commit message follows <type>(<scope>): <description> format",
+        "The type matches the nature of the actual changes in the diff",
+        "The body explains what changed and why",
+        "Specific files are staged (not git add . or git add -A)"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "I renamed the API endpoint from /users to /v2/accounts, this is a breaking change. commit please",
+      "expected_output": "A conventional commit with breaking change indicator (! or BREAKING CHANGE footer).",
+      "assertions": [
+        "The commit includes a breaking change indicator (! after type/scope or BREAKING CHANGE: in footer)",
+        "The title mentions the API change",
+        "The body or footer explains what broke and what to use instead"
+      ]
+    }
+  ]
+}

package/skills/model-council/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: model-council
+description: Multi-agent debate system for complex queries. Four agents (Scholar, Logician, Contrarian, Captain) analyze independently, debate, and synthesize a consensus. Use for deeper analysis, second opinions, or stress-testing decisions.
+license: MIT
+metadata:
+  author: gokulkrishh
+  version: '0.1.0'
+---
+
+# Model Council
+
+A multi-agent debate system inspired by Grok 4.20's council architecture. Four specialized agents deliberate on your query, challenge each other's reasoning, and produce a synthesized consensus answer.
+
+## Architecture
+
+Four agents with distinct roles:
+
+1. **Captain (Coordinator)** — Decomposes the task, sets the agenda, resolves conflicts, and synthesizes the final answer.
+2. **Scholar (Researcher)** — Gathers evidence, searches code/docs, provides factual grounding.
+3. **Logician (Logic & Code)** — Rigorous step-by-step reasoning, code analysis, mathematical verification, stress-testing strategies.
+4. **Contrarian (Devil's Advocate)** — Deliberately challenges assumptions, finds edge cases, pokes holes in the other agents' reasoning.
+
+## Instructions
+
+Follow these phases strictly:
+
+**PHASE 1 — INDEPENDENT ANALYSIS**
+
+Simulate three independent agent perspectives on the user's query:
+
+**Scholar (Research & Facts):**
+
+- Search the codebase, documentation, or use web search for relevant context
+- Present factual findings, prior art, and evidence. When the user presents multiple options, evaluate each one individually
+- Be thorough and cite specific files/lines when applicable
+
+**Logician (Logic & Code):**
+
+- Break down the problem step-by-step
+- Propose a concrete solution with reasoning
+- Consider performance, maintainability, and correctness
+- Write code snippets if applicable
+
+**Contrarian (Devil's Advocate):**
+
+- Challenge the other agents' assumptions
+- Identify edge cases, failure modes, and risks
+- Suggest alternative approaches the others may have missed
+- Be constructively critical — not dismissive
+
+**PHASE 2 — DEBATE**
+
+Have each agent respond to the others' Phase 1 analysis:
+
+- Scholar: Verify or refute claims made by Logician and Contrarian
+- Logician: Address Contrarian's objections, strengthen or revise the solution
+- Contrarian: Final challenge — are there still unaddressed risks?
+
+**PHASE 3 — SYNTHESIS (Captain)**
+
+As the Captain (Coordinator), synthesize the debate using this exact template:
+
+```
+## Council Verdict
+
+**Confidence:** [High | Medium | Low]
+
+### Consensus Answer
+[The synthesized answer incorporating the strongest arguments from all agents]
+
+### Key Insights
+- [Non-obvious or surprising points that emerged from the debate — not just restatements of known facts]
+
+### Dissenting Points
+- [Any unresolved disagreements or risks flagged by the Contrarian]
+
+### Recommended Action
+[Clear, actionable next steps]
+```
+
+## Rules
+
+- Each agent must stay in character throughout
+- The Contrarian MUST disagree with at least one aspect of the other agents' reasoning
+- The Captain must acknowledge dissent, not just override it
+- If the query is simple and doesn't benefit from debate, you MUST skip all phases, state that it doesn't warrant a council debate, and answer directly
+- Use the actual tools available (file reading, searching, web search, etc.) during the Scholar phase — don't just theorize

package/skills/model-council/evals/evals.json

@@ -0,0 +1,38 @@
+{
+  "skill_name": "model-council",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Should I use Next.js App Router or Remix for a new SaaS dashboard?",
+      "expected_output": "A full council debate with all 3 phases (independent analysis, debate, synthesis) and a Council Verdict with confidence level.",
+      "assertions": [
+        "All three agents (Scholar, Logician, Contrarian) provide independent analysis in Phase 1",
+        "The Contrarian disagrees with at least one aspect of the other agents' reasoning",
+        "Phase 2 shows agents responding to each other's points",
+        "The Council Verdict includes a confidence level (High, Medium, or Low)",
+        "Dissenting points are acknowledged in the final synthesis"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "What is 2 + 2?",
+      "expected_output": "The skill recognizes this is too simple for a full council debate and answers directly.",
+      "assertions": [
+        "The skill identifies the query as too simple for a full debate",
+        "A direct answer is given without running all 3 phases"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "We're choosing between PostgreSQL, MongoDB, and DynamoDB for a real-time analytics platform processing 10M events/day. What should we use?",
+      "expected_output": "A thorough council debate with the Scholar researching each database's strengths, the Logician analyzing trade-offs, and the Contrarian challenging assumptions.",
+      "assertions": [
+        "The Scholar provides factual evidence about each database option",
+        "The Logician breaks down the decision with structured reasoning",
+        "The Contrarian challenges at least one assumption",
+        "The final verdict includes a clear recommended action",
+        "Key insights section surfaces non-obvious points from the debate"
+      ]
+    }
+  ]
+}