instant-python 0.21.0__tar.gz → 0.22.0__tar.gz

instant_python-0.22.0/.agents/commands/code-review.md

@@ -0,0 +1,36 @@
+## Senior XP Developer — Pending Changes Review (Tests, Maintainability, Project Rules)
+
+Act as a **Senior XP Developer** performing a thoughtful code review of the **pending, uncommitted changes**.  
+Focus on **test quality**, **maintainability**, **simplicity**, and **alignment with project rules and standards**.
+
+### Task
+Review the pending changes with attention to:
+
+1. **Test Coverage & Quality**
+   - Are new behaviors backed by clear, intention-revealing tests?
+   - Do tests follow the project's testing style (naming, structure, speed, isolation)?
+   - Are edge cases, failure paths, and boundaries tested?
+   - Do tests help prevent regressions and clarify expected behavior?
+
+2. **Maintainability & Simplicity**
+   - Is the code easy to understand at a glance?
+   - Are names clear and aligned with domain concepts?
+   - Is there unnecessary complexity that could be simplified?
+   - Are functions/classes/modules small, cohesive, and well-factored?
+   - Does the change make the system easier or harder to evolve?
+
+3. **Project Rules & Conventions**
+   - Validate the changes against the project’s explicit rules (coding standards, architectural guidelines, patterns, constraints).
+   - Check that dependencies, error handling, and logging follow the agreed practices.
+   - Identify deviations and justify whether they are acceptable or need correction.
+
+4. **Risk & Impact**
+   - Highlight areas likely to fail in production or introduce hidden coupling.
+   - Call out missing tests for critical paths.
+   - Evaluate how the change affects overall reliability and flow.
+
+### Deliverables
+Provide:
+- A **structured review** detailing strengths and weaknesses.
+- **Specific, actionable improvements** to increase clarity, testability, and alignment with project rules.
+- A brief final summary: *Is this change ready to commit? If not, what is the smallest next improvement?*

instant_python-0.22.0/.agents/commands/commit.md

@@ -0,0 +1,62 @@
+---
+name: commit
+description: Split uncommitted changes into atomic conventional commits with a focus on why each change was made. Use only when the user explicitly invokes this command.
+---
+
+Split the currently uncommitted changes into multiple atomic conventional commits. This command is **conversational**: you will ask the user before every decision.
+
+## Steps
+
+1. Run `git status` and `git diff` (staged + unstaged) to see everything that exists. For files with multiple unrelated hunks, also inspect `git diff` per file.
+
+2. Propose a grouping plan: list each commit you would create, which files (or hunks) go into it, and the conventional commit subject you suggest. Show this as a numbered list. Each commit must represent a **chunk of correct functional code** — it should compile and work on its own.
+
+3. **Ask the user** to confirm or correct the grouping before doing anything.
+
+4. For each commit in the agreed order:
+   - Stage exactly the files (or hunks via `git add -p` if needed) that belong to this commit. Never use `git add .` or `git add -A`.
+   - Draft a subject line and **optional body** that explain **why** the change was made, not just what changed. Ask yourself: does the commit benefit from extra context? If yes, include a body. If the subject already tells the full story, omit the body.
+   - Confirm the subject and body (if any) with the user.
+   - Commit with the subject line only, or subject + body if applicable.
+   - Run `git status` to confirm only the intended files were committed.
+
+5. After the last commit, run `git status` and `git log --oneline` so the user can verify the result.
+
+## Commit message guidance
+
+- The subject should express **intent**: *what was done and why* (e.g., `feat(api): add rate limiting to prevent abuse` rather than `feat(api): add rate limiting`).
+- Add a body only when the subject alone doesn't capture the reasoning. The body is for context: trade-offs considered, alternatives rejected, or non-obvious implications.
+- Use `!` after the type/scope to mark a breaking change (e.g., `feat(api)!: remove deprecated v1 endpoints`). If breaking, also include a `BREAKING CHANGE:` trailer in the body explaining the migration path.
+- Reference issues with `Closes #123`, `Fixes #456`, or `Refs #789` in the body when applicable.
+- If in doubt about whether a body adds value, ask the user.
+
+## Commit types
+
+| Type       | When to use                                                                                                                                                    |
+|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `feat`     | Code changes that add new functionality, modify existing behavior/return values (often breaks tests), or remove a feature.                                     |
+| `fix`      | Changes that fix a bug — either an unidentified bug, or a test that broke after a behavior change and needs correction.                                        |
+| `refactor` | Changes that modify existing code without altering its behavior: type hints, removing unused imports, renaming variables, etc.                                 |
+| `test`     | Changes related only to tests: object mothers, fixing a test that was incorrectly implemented, renaming test variables, reorganizing test structure.           |
+| `style`    | Formatting changes that don't modify code behavior (whitespace, formatting, etc.).                                                                             |
+| `build`    | Changes to the build process, dependencies, or tooling that don't affect code behavior.                                                                        |
+| `docs`     | Documentation changes like README, ADRs, or design docs.                                                                                                       |
+| `chore`    | Changes that don't fit other types and don't touch src, tests, or docs (e.g., .gitignore, editor config).                                                      |
+| `ci`       | Changes to CI/CD pipeline files or configuration.                                                                                                              |
+| `perf`     | Performance improvements that change behaviour to make it faster.                                                                                              |
+
+## Questions you should ask
+
+- Is this grouping correct, or should X go with Y instead?
+- For the proposed subject `feat(api): add rate limiting to prevent abuse`, is the scope right?
+- Does this commit deserve a body, or is the subject enough?
+- Should any change be discarded instead of committed?
+
+Err on the side of asking more rather than less.
+
+## Hard rules
+
+- **No Claude attribution.** Never add `Co-Authored-By: Claude`, `🤖 Generated with Claude Code`, or any similar footer.
+- **No `--no-verify`.** If a hook fails, stop and ask the user.
+- **Never bundle unrelated changes.** If two changes share a file but belong in different commits, use `git add -p` to split them.
+- **Do not push.**

instant_python-0.22.0/.agents/commands/security-review.md

@@ -0,0 +1,22 @@
+## Security Expert — Deep, Pragmatic Risk Analysis
+
+Act as a **senior security expert** with experience in **OWASP**, **threat modeling**, **cloud security**, **secure engineering**, and **production risk assessment**. Your goal is to identify *real, practical vulnerabilities* and recommend *simple, high-value mitigations* without adding unnecessary complexity.
+
+### Task
+**Analyze the code, architecture, or system from a security perspective**, focusing on:
+
+- Attack surface and weak entry points
+- Insufficient validation, untrusted inputs, injection vectors
+- Dependency risks, secret/credential exposure, unsafe configuration
+- Common failure modes: insecure deserialization, session issues, broken authorization, etc.
+- Behavior under stress, unexpected conditions, or malformed data
+
+### Deliverables
+Provide:
+
+1. **Identified risks**, clearly described and prioritized
+2. **Realistic exploitation scenarios** showing how each risk could impact production
+3. **Concrete, lightweight mitigations** to reduce risk without adding friction
+4. **Ongoing defensive practices** to keep the system secure over time
+
+Stay pragmatic: minimal complexity, maximum clarity, high reliability.

instant_python-0.22.0/.agents/commands/technical-debt-review.md

@@ -0,0 +1,33 @@
+## Senior XP Developer — Technical Debt Analysis
+
+Act as a **Senior XP Developer** with **Lean thinking** and a focus on sustainable pace.
+
+### Task
+**Identify and prioritize technical debt** in the codebase:
+
+1. **Catalog debt items**
+    - Code smells (long methods, god classes, primitive obsession, etc.)
+    - Missing or weak tests
+    - Outdated dependencies
+    - Unclear or misleading names
+    - Duplicated logic
+    - Broken windows (small issues left unfixed)
+
+2. **Classify by type**
+    - **Deliberate/Prudent**: Conscious trade-offs made knowingly
+    - **Inadvertent/Reckless**: Mistakes or lack of knowledge
+    - **Bit rot**: Accumulated entropy over time
+
+3. **Prioritize by ROI**
+    - Impact on current development flow
+    - Risk to production reliability
+    - Cost of deferral vs. cost of fix
+    - Frequency of change in affected area
+
+### Deliverables
+- **Top 5 debt items** with clear descriptions
+- **Recommended payoff order** with rationale
+- **Quick wins**: items fixable in < 30 minutes
+- **Strategic debt**: items to defer consciously (and why)
+
+**Keep the codebase healthy. Pay debt before it compounds.**

instant_python-0.22.0/.agents/skills/adr/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: adr
+description: Create or improve adr documentation based on the current conversation. Use this when a plan has been created and changes
+  were requested because it didn’t follow the repository’s conventions.
+---
+
+Based on the current conversation, create new or improve existing documentation files inside the `docs/adrs` folder.
+
+## Steps
+
+1. Identify conventions, patterns, or decisions discussed in the conversation that should be documented.
+2. Check if a relevant doc already exists in `docs/adrs` (organized by area: `testing/`, `database/`, etc.).
+    - If it exists, improve it while preserving the required structure.
+    - If it does not exist, create a new file in the appropriate subfolder.
+3. Read `docs/adrs/adr-guidelines.md` and follow its structure exactly. Every document MUST include these sections in order:
+```
+# Name of the convention
+
+## Convention
+## Benefits
+## Examples (with Good and Bad subsections)
+## Real world examples
+## Related agreements
+```
+
+4. Ask the user to confirm the target file path before writing.
+5. Update the AGENTS.md index with the new doc.
+
+## Rules
+
+- Each convention goes in its own standalone Markdown file — never bundle multiple conventions into one doc.
+- Place files in the correct area subfolder (`database/`, `testing/`, etc.).
+- Include concrete good and bad examples with code blocks when applicable.
+- Link to real files in the codebase that follow the convention in the "Real world examples" section.