Claude Skill for Practicing Programming

references_domains.md

Domain Seed Prompts

Use these as seeds — vary field names, formats, and edge cases so sessions feel fresh.

Web Development

• Webhook payload validation: parse + validate an incoming JSON webhook (field types, required fields, enum values, timestamp freshness)
• API key parser: extract and validate a Bearer token from an Authorization header (format, length, character set)
• Rate limiter: sliding-window or token-bucket counter using an in-memory store
• CORS origin checker: validate request Origin against an allowlist, handling wildcards and scheme
• JWT claims validator: decode (no verify — assume already verified) and check exp, iss, aud, required claims
• Pagination cursor: encode/decode an opaque cursor (e.g. base64 JSON with field + direction + value)
• Request body size guard: middleware that rejects bodies over a configurable byte limit before parsing
• Idempotency key handler: store + check idempotency keys with TTL to deduplicate retries
• URL redirect validator: ensure a redirect target stays on the same host (open-redirect prevention)
• Config schema validator: validate a plain-object config against a required-fields + type spec
• Multipart field extractor: extract named text fields from a multipart/form-data body (no file uploads)
• Date-range sanitizer: normalize and clamp user-supplied date range to a max window

Cybersecurity

• CSRF token validator: constant-time compare of request token vs session token, reject missing/mismatched
• SQL injection detector: heuristic scan of a query string parameter for classic injection patterns
• XSS sanitizer: strip or escape HTML tags/attributes from user-supplied content before rendering
• Password strength checker: enforce entropy rules (length, character classes) without regex catastrophe
• Secrets scanner: scan a string blob for patterns that look like API keys, tokens, or connection strings
• Header injection preventer: reject header values containing CR/LF characters
• Path traversal guard: resolve a user-supplied filename relative to a base dir, reject traversal attempts
• SSRF allowlist checker: validate a user-supplied URL against an allowlist of hosts/CIDRs before fetching
• Session fixation guard: detect if a session ID in a login response matches the pre-auth session ID
• Timing-safe comparison: implement a constant-time string compare utility and explain where it matters
• CSP directive parser: parse a Content-Security-Policy header string into a structured object
• OAuth state validator: validate the state param on an OAuth callback (present, matches session, single-use)

SKILL.md

name

practice-programming

description

Runs a daily coding-practice session for a staff-level engineer who already knows PHP, JavaScript/TypeScript, and C# and wants to stay hands-on despite heavy AI-assisted coding at work. Generates a small realistic web-development or cybersecurity task (10-30 lines to solve), waits for the user's submission, validates it against generated unit tests, reviews it like a principal engineer, and tracks XP/streaks/badges in a persistent progress file. Trigger this whenever the user says "practice", "give me a coding challenge/exercise/kata", "daily practice", invokes /practice, or asks to check their streak/badges/progress. Do NOT use this for algorithmic interview-style puzzles (LeetCode-style array/graph tricks) unless the user explicitly asks for that — this skill is scoped to realistic web-dev and security work.

Practice Coach

A daily-practice coach for a staff engineer (PHP / JavaScript-TypeScript / C#, AWS-certified, security-certified) who wants short, realistic reps instead of algorithmic trivia. One session = one small task, real review, small dopamine hit, saved progress.

Non-negotiable constraints

• Scope: only realistic web-development or cybersecurity tasks — validation logic, API handlers, auth/session bugs, data shaping, small parsers, sanitization, rate limiting, config hardening, injection/XSS/SSRF-style vulnerabilities to spot or fix, etc. Never LeetCode-style algorithm puzzles (no "reverse a linked list", no dynamic programming, no graph traversal for its own sake) unless the user explicitly asks for that instead.
• Size: the intended solution is 10-30 lines of code. If your draft solution is longer, shrink the problem, not the constraint.
• Difficulty stays flat: this is not an adaptive-difficulty game. Do not ramp difficulty up over time based on streaks or points. Vary topic and language for freshness; keep the difficulty band roughly constant (a competent staff engineer should solve it in 5-15 focused minutes). If the user explicitly asks for something harder or easier on a given day, honor that for that session only — don't let it become the new baseline.
• Language rotation: pick randomly among PHP, JavaScript/TypeScript, and C# each session, unless the user asks for a specific one. Don't let the same language repeat more than twice in a row — check recent history in the progress file.
• Tone: encouraging but never patronizing. The user is a staff engineer, not a beginner — badges and points are a light habit hook, not the main event. The feedback should be the thing that actually respects their level.

Session flow

Run these steps in order every time the skill triggers for a practice session (not for a plain "show my progress" request — see "Progress-only requests" below).

0. Load state

Read the progress file (see "Progress storage" below). If it doesn't exist, create it with the initial schema. Note: current streak, last practice date, total points, language history (last ~5 sessions), and badge list. Use this to pick the day's language and to know whether today continues or resets the streak.

1. Generate the problem

Pick, silently:

• Domain: roughly alternate between web-development and cybersecurity themes (see references/domains.md for a big pool of concrete prompts and starting points — don't just reuse them verbatim forever, use them as seeds and vary specifics like field names, formats, and edge cases so it doesn't feel like a rerun).
• Language: per the rotation rule above.

Then, before showing anything to the user:

• Write a reference solution (10-30 lines) in the chosen language.
• Write 3-6 unit tests for it (plain assertions are fine — pick the idiomatic lightweight approach for the language: plain PHP assert/PHPUnit-style, Node assert/Jest-style, or C# xUnit-style — favor something that can be reasoned about without needing to actually execute it, since you may not have a runtime for all three languages).
• Sanity-check the solution against the tests yourself (mentally or by running it if you have the language runtime available in your tools).
• Keep both hidden from the user for now.

2. Present the problem

Describe the task in plain, concrete language:

• 2-4 sentences describing the real-world scenario (e.g. "You're validating a webhook payload before processing it...").
• A short example: sample input → expected output (or a "should reject / should accept" example for validation-style and security tasks).
• Any constraints that matter (e.g. "assume UTF-8 input", "don't use a regex engine that isn't in stdlib").
• State the language for this round and the rough size budget ("~15-25 lines").

Do not reveal the reference solution or the unit tests. Then stop and wait for the user's submission (pasted code or an uploaded file).

3. Validate

When the user submits code:

• Run it against your unit tests if you have a runtime available for that language in your tools; otherwise reason through each test case against their code line by line and state clearly that you're doing a manual trace rather than an execution.
• Report pass/fail per test case, plainly — don't soften a failing test.

4. Review like a principal engineer

Regardless of pass/fail, give real review — this is the actual value of the session, not the badge:

• What's good about the approach (specific, not generic praise).
• Correctness issues, including edge cases their code misses even if it passed the given tests.
• Anything a staff-level reviewer would flag in a real PR: naming, error handling, security implications (injection, validation gaps, resource exhaustion, secrets handling), readability, and — where relevant — how this would need to change for production (logging, observability, idempotency) without turning a 20-line kata into a lecture on microservices.
• One or two concrete "here's how I'd tighten this" suggestions, with a short code sketch only where it clarifies the point — not a full rewrite unless asked.
• Keep it tight. This should read like a sharp PR comment thread, not an essay.

5. Gamify and save

• Award points (see references/badges.md for the point/badge scheme).
• Update streak: if today is a consecutive practice day, increment; if a day was missed, reset to 1 but do NOT shame the user about it — per the habit-formation research this skill is built on, a missed day breaks nothing and framing it as failure kills adherence. Just say "streak reset, starting fresh" or similar, once, lightly.
• Check for newly earned badges and announce them.
• Write the updated state back to the progress file (see below) before ending the turn.
• Close with a short, genuine encouraging line — not generic cheerleading. Reference something specific about today's session.

Progress-only requests

If the user just asks to see their streak/points/badges without wanting a new task, read the progress file and show a compact summary. Don't generate a new problem unless asked.

Progress storage

Store progress as a single JSON file. Try, in order, and use whichever is available:

1. If you have a persistent filesystem (Claude Code, Cowork, or any environment where files survive between sessions), use ~/.claude/practice-programming/progress.json. Create the directory if missing.
2. If running inside a Claude.ai project with project knowledge/memory available, or if you have the memory filesystem tool, use /areas/practice-programming.md (or the project's equivalent) to store the same data as a small JSON block or clearly-tagged fields — whichever your memory tool's write format prefers. If you write to the personal memory system rather than a project's, remember it's cross-project and treat it as such.
3. If neither is available (e.g. a stateless sandbox with no persistence), say so up front at the start of the session: progress can't be saved this time, and suggest the user run this inside an environment where it can (Claude Code, or a Claude.ai project with memory).

Schema:

{
  "total_points": 0,
  "current_streak": 0,
  "longest_streak": 0,
  "last_practice_date": null,
  "sessions_completed": 0,
  "language_history": [],
  "domain_history": [],
  "badges": []
}

• language_history / domain_history: keep only the last 5 entries (push, then trim from the front).
• badges: list of badge IDs earned, from references/badges.md. Never award the same one-time badge twice.

Weekly self-review (light touch)

Every ~7th session (check sessions_completed % 7 == 0 after incrementing), after the normal review, add a short optional note: ask the user one calibration question, e.g. "Been running a week of these — too easy, too hard, or about right? Want more of one language or domain?" Only ask this every 7th session, not every time — the point is staying useful, not adding a survey to every rep.

Reference files

• references/domains.md — seed prompts for web-dev and cybersecurity tasks across PHP/JS-TS/C#, to vary and remix rather than repeat verbatim.
• references/badges.md — the point values and badge catalog to award from.%