@mohammadhprp/system-prompt 0.12.0 → 0.12.2

package/framework/skills/effective-html/references/html-wireframe.md

@@ -0,0 +1,81 @@
+# HTML Wireframe
+
+Turn a product question into a low-fidelity HTML artifact that is easy to inspect, change, and discuss. The wireframe should help reviewers decide what belongs on the screen and how the task should work. It should not look like a finished product.
+
+## Establish the review question
+
+Read the conversation, supplied brief, and nearby project material before choosing a layout. Reuse the project's vocabulary, content model, and known product constraints.
+
+Authority runs in this order:
+
+1. The user's explicit instructions and accepted decisions.
+2. The product's existing structure and terminology.
+3. The user, task, and content being modeled.
+4. Your own layout judgment.
+
+Before coding, identify:
+
+- the user and the job they need to complete;
+- the screen or bounded flow under review;
+- the information and actions the artifact must contain;
+- the assumptions that can be made safely;
+- the structural questions the wireframe should help answer.
+
+Use real labels and representative content. Low fidelity is not permission to use anonymous boxes or lorem ipsum where wording affects the layout.
+
+## Explore structure before style
+
+When [`design-artifact`](design-artifact.md) is available, read it for
+subject-specific composition and hierarchy guidance without importing editorial
+polish. This skill's low-fidelity contract remains authoritative.
+
+When the layout is still unsettled, create two or three meaningfully different directions. Vary product decisions such as:
+
+- navigation model;
+- grouping and order;
+- primary-action placement;
+- content density;
+- overview versus step-by-step flow;
+- desktop-to-mobile reflow.
+
+Do not call color changes or minor card rearrangements separate directions. Give each direction a short descriptive name and one sentence about its tradeoff.
+
+Keep the directions in one HTML file when practical. Use a small, keyboard-operable selector so reviewers can compare them without opening several files. Preserve the same core content and task across directions. If the user has already chosen a structure, build that direction only.
+
+## Keep the artifact intentionally unfinished
+
+- Use a restrained grayscale palette, system type, plain borders, and simple blocks.
+- Avoid brand colors, gradients, shadows, illustrations, decorative imagery, and polished component styling.
+- Use limited radius and spacing. Enough order should be present to judge hierarchy, but not enough polish to invite a brand review.
+- Show images or rich media as labeled placeholders unless the asset changes a structural decision.
+- Add annotations only when they expose an assumption, open question, or behavior that cannot be shown directly.
+
+The wireframe may still be well composed. Intentional unfinishedness is different from careless spacing, illegible type, or broken responsive behavior.
+
+## Add only useful behavior
+
+Use basic click-through behavior when it helps test navigation, disclosure, or a short task flow. Keep it immediate and plain.
+
+- Make links, tabs, and next or back actions work when they are part of the review.
+- Use native controls and visible keyboard focus.
+- Do not build elaborate animation, persistence, simulated APIs, or production state management.
+- Remove controls that have no review purpose, or label them clearly as out of scope.
+
+## Build contract
+
+- Deliver one self-contained `.html` file with essential CSS and JavaScript inline.
+- Require no build tooling or external service.
+- Use semantic landmarks, headings, lists, forms, and buttons.
+- Make the layout useful at wide desktop and narrow mobile widths.
+- Keep the page free of accidental horizontal overflow.
+- Respect the source material. Do not invent extra product scope to fill space.
+
+## Verify and hand off
+
+Open the result at desktop and mobile widths. Check reading order, wrapping, overflow, focus visibility, and every implemented click path. Confirm that the directions remain structurally distinct at both sizes.
+
+Return the absolute file path, the names and tradeoffs of the directions, and the visual decisions deliberately deferred to a later mockup or prototype.
+
+## Further reading
+
+Read Plannotator's [HTML wireframes and prototypes for coding agents](https://docs.plannotator.ai/learn/code-context/html-wireframes-and-prototypes-for-coding-agents) for guidance on what to decide at the wireframe stage.

package/framework/skills/effective-html/references/html.md

@@ -0,0 +1,72 @@
+# HTML
+
+Build one self-contained HTML file that makes the subject clearer, easier to use, or easier to understand. The standard is consistent care, not a consistent look. Do not reproduce a house palette, typography stack, card system, or layout from prior runs.
+
+## Route the request first
+
+Use the narrowest skill that owns the main review question:
+
+- Read and compose [`design-artifact`](design-artifact.md) with the
+  chosen workflow when palette, type, composition, theming, or overall visual
+  register remain open. It provides creative direction; it does not replace the
+  specialist that owns fidelity, structure, or behavior.
+- Read and follow [`html-wireframe`](html-wireframe.md) when structure, information hierarchy, navigation, or task flow is still unsettled. It should remain visibly low fidelity and may compare two or three layout directions.
+- Read and follow [`html-prototype`](html-prototype.md) when the user needs a polished mockup or a working interactive flow. A mockup is the static fidelity mode inside that skill.
+- Read and follow [`html-plan`](html-plan.md) when the artifact is primarily a plan, roadmap, implementation sequence, or rollout document whose source commitments must remain easy to verify.
+- Read and follow [`html-diagram`](html-diagram.md) when relationships, sequence, topology, state, hierarchy, or system behavior are the main content.
+- Continue with `html` for reports, explainers, presentations, landing pages, data stories, tools, and mixed artifacts that do not have a clearer owner.
+
+These sibling links are the nesting mechanism when the collection is installed together. If a specialized skill is unavailable, continue here and load the closest reference below. Do not make the user install another skill before completing the request.
+
+## Read the room before designing
+
+Inspect the user's request and any material they supplied. When working in a repository, look for its design language in `AGENTS.md`, `CLAUDE.md`, design-system documentation, tokens, existing components, and nearby artifacts.
+
+Authority runs in this order:
+
+1. The user's explicit visual and functional instructions.
+2. The project's established design system and conventions.
+3. The subject matter, audience, and purpose of this artifact.
+4. Your own design judgment.
+
+Before coding, settle five things in working notes:
+
+- **Audience and job:** who will use this, and what should they understand or do?
+- **Form:** document, presentation, interface, diagram, or data visualization.
+- **Register:** quiet and workmanlike, polished and editorial, or intentionally expressive.
+- **Fidelity:** whether to preserve the user's structure and wording or synthesize more freely.
+- **Interaction:** what benefits from exploration, sequencing, filtering, or motion, if anything.
+
+If the project already answers the visual questions, follow it. Otherwise read
+and compose [`design-artifact`](design-artifact.md) when it is
+available. If the collection was installed without that sibling skill, read
+   [`creative-direction.md`](creative-direction.md) before
+choosing the palette, type, composition, or motion.
+
+## Load only the guidance the artifact needs
+
+- For reports, briefs, plans, explainers, and decks, read [`documents-and-presentations.md`](documents-and-presentations.md).
+- For interfaces, calculators, and other tools that remain in this broad skill, read [`interfaces.md`](interfaces.md).
+- For architecture, process, sequence, state, hierarchy, or concept diagrams, read [`diagrams.md`](diagrams.md).
+- For quantitative charts, tables, metrics, or data stories, read [`charts-and-data.md`](charts-and-data.md).
+
+Requests can span forms. Read every reference that materially applies, then give the artifact one coherent direction.
+
+## Build contract
+
+- Produce one `.html` file with its essential CSS and JavaScript inline. It should work when opened directly, without a build step. Do not require a network connection unless the user permits external dependencies.
+- Use real content. Do not fill prominent space with placeholder copy, decorative statistics, or controls that do nothing.
+- Let content determine structure. A sequence should read in order; a comparison should make differences easy to scan; an interface should expose state and actions; a diagram should make relationships legible.
+- Use semantic HTML, responsive layout, accessible contrast, visible keyboard focus, and reduced-motion handling. Make interactive elements work with a keyboard.
+- Keep the page body free of accidental horizontal overflow. Put intentionally broad content in a contained scrolling or pannable region.
+- Define a small set of CSS tokens for the chosen direction and use them consistently. Tokens are an implementation tool, not a predetermined palette.
+- Treat motion as explanation or feedback. If removing an animation loses no meaning or useful feedback, remove it.
+- Follow the user's or project's theme policy. When none exists, give durable utility artifacts considered light and dark themes if that improves their use. A deliberate single-theme concept is valid.
+
+## Finish the work
+
+Write the file to the requested location, or choose a clear filename in the current workspace. When browser tooling is available, open it and inspect a wide and narrow viewport. Exercise its controls, check the console, and fix clipping, overlap, illegible text, broken states, and accidental overflow.
+
+Before delivery, run one originality check: if the subject were swapped for a neighboring topic, would the same visual concept still make just as much sense? If yes, the direction is too generic; revise the composition, type, color, imagery, or interaction so it belongs to this subject.
+
+Return the absolute path and a short description of the artifact's visual and interaction choices.

package/framework/skills/effective-html/references/interfaces.md

@@ -0,0 +1,17 @@
+# Interfaces and tools
+
+Read this for editors, calculators, control panels, and other broad HTML artifacts people operate rather than read straight through. Use `html-prototype` for a styled mockup or a bounded product flow when that skill is available.
+
+Lead with the current state and the next useful action. Organize the interface around the user's task, not the shape of the underlying data model.
+
+- Make controls look actionable and label them with the result they produce.
+- Show feedback close to the action: pending, success, empty, validation, and error states should all be designed.
+- Preserve state visibly. Selected filters, active modes, changed values, and unsaved work should never be mysteries.
+- Put summaries before detail when scanning matters, while keeping the path to the underlying evidence obvious.
+- Use status color for status, independently from the artifact's decorative accent.
+- Keep forms keyboard-friendly, labels explicit, targets comfortably sized, and destructive actions difficult to trigger accidentally.
+- Prefer a few strong regions over a uniform grid of interchangeable cards.
+
+Implement the important path when behavior is part of the request. A convincing static shell with dead controls is worse than a simpler interface whose important path works end to end.
+
+On narrow screens, preserve the primary task. Reflow secondary panels, turn dense toolbars into deliberate controls, and contain wide data rather than shrinking it until it is illegible.

package/framework/skills/glab/SKILL.md

@@ -0,0 +1,222 @@
+---
+name: glab
+description: Expert guidance for using the GitLab CLI (glab) to manage GitLab issues, merge requests, CI/CD pipelines, repositories, and other GitLab operations from the command line. Use this skill when the user needs to interact with GitLab resources or perform GitLab workflows.
+allowed-tools: Bash, Read, Grep, Glob
+---
+
+# GitLab CLI (glab) Skill
+
+Provides guidance for using `glab`, the official GitLab CLI, to perform GitLab operations from the terminal.
+
+## When to Use This Skill
+
+Invoke when the user needs to:
+- Create, review, or manage merge requests
+- Work with GitLab issues
+- Monitor or trigger CI/CD pipelines
+- Clone or manage repositories
+- Perform any GitLab operation from the command line
+
+## Prerequisites
+
+Verify glab installation before executing commands:
+```bash
+glab --version
+```
+
+If not installed, inform the user and provide platform-specific installation guidance.
+
+## Authentication Quick Start
+
+Most glab operations require authentication:
+
+```bash
+# Interactive authentication
+glab auth login
+
+# Check authentication status
+glab auth status
+
+# For self-hosted GitLab
+glab auth login --hostname gitlab.example.org
+
+# Using environment variables
+export GITLAB_TOKEN=your-token
+export GITLAB_HOST=gitlab.example.org  # for self-hosted
+```
+
+## Core Workflows
+
+### Creating a Merge Request
+
+```bash
+# 1. Ensure branch is pushed
+git push -u origin feature-branch
+
+# 2. Create MR
+glab mr create --title "Add feature" --description "Implements X"
+
+# With reviewers and labels
+glab mr create --title "Fix bug" --reviewer=alice,bob --label="bug,urgent"
+```
+
+### Reviewing Merge Requests
+
+```bash
+# 1. List MRs awaiting your review
+glab mr list --reviewer=@me
+
+# 2. Checkout MR locally to test
+glab mr checkout <mr-number>
+
+# 3. After testing, approve
+glab mr approve <mr-number>
+
+# 4. Add review comments
+glab mr note <mr-number> -m "Please update tests"
+```
+
+### Managing Issues
+
+```bash
+# Create issue with labels
+glab issue create --title "Bug in login" --label=bug
+
+# Link MR to issue
+glab mr create --title "Fix login" --description "Closes #<issue-number>"
+
+# List your assigned issues
+glab issue list --assignee=@me
+```
+
+### Monitoring CI/CD
+
+```bash
+# Watch pipeline in progress
+glab pipeline ci view
+
+# Check pipeline status
+glab ci status
+
+# View logs if failed
+glab ci trace
+
+# Retry failed pipeline
+glab ci retry
+
+# Lint CI config before pushing
+glab ci lint
+```
+
+## Common Patterns
+
+### Working Outside Repository Context
+
+When not in a Git repository, specify the repository:
+```bash
+glab mr list -R owner/repo
+glab issue list -R owner/repo
+```
+
+### Self-Hosted GitLab
+
+Set hostname for all commands:
+```bash
+export GITLAB_HOST=gitlab.example.org
+# or per-command
+glab repo clone gitlab.example.org/owner/repo
+```
+
+### Automation and Scripting
+
+Use JSON output for parsing:
+```bash
+glab mr list --output=json | jq '.[] | .title'
+```
+
+### Using the API Command
+
+The `glab api` command provides direct GitLab API access:
+
+```bash
+# Basic API call
+glab api projects/:id/merge_requests
+
+# IMPORTANT: Pagination uses query parameters in URL, NOT flags
+# ❌ WRONG: glab api --per-page=100 projects/:id/jobs
+# ✓ CORRECT: glab api "projects/:id/jobs?per_page=100"
+
+# Auto-fetch all pages
+glab api --paginate "projects/:id/pipelines/123/jobs?per_page=100"
+
+# POST with data
+glab api --method POST projects/:id/issues --field title="Bug" --field description="Details"
+```
+
+## Best Practices
+
+1. **Verify authentication** before executing commands: `glab auth status`
+2. **Use `--help`** to explore command options: `glab <command> --help`
+3. **Link MRs to issues** using "Closes #123" in MR description
+4. **Lint CI config** before pushing: `glab ci lint`
+5. **Check repository context** when commands fail: `git remote -v`
+
+## Common Commands Quick Reference
+
+**Merge Requests:**
+- `glab mr list --assignee=@me` - Your assigned MRs
+- `glab mr list --reviewer=@me` - MRs for you to review
+- `glab mr create` - Create new MR
+- `glab mr checkout <number>` - Test MR locally
+- `glab mr approve <number>` - Approve MR
+- `glab mr merge <number>` - Merge approved MR
+
+**Issues:**
+- `glab issue list` - List all issues
+- `glab issue create` - Create new issue
+- `glab issue close <number>` - Close issue
+
+**CI/CD:**
+- `glab pipeline ci view` - Watch pipeline
+- `glab ci status` - Check status
+- `glab ci lint` - Validate .gitlab-ci.yml
+- `glab ci retry` - Retry failed pipeline
+
+**Repository:**
+- `glab repo clone owner/repo` - Clone repository
+- `glab repo view` - View repo details
+- `glab repo fork` - Fork repository
+
+## Progressive Disclosure
+
+For detailed command documentation, refer to:
+- **references/commands-detailed.md** - Comprehensive command reference with all flags and options
+- **references/quick-reference.md** - Condensed command cheat sheet
+- **references/troubleshooting.md** - Detailed error scenarios and solutions
+
+Load these references when:
+- User needs specific flag or option details
+- Troubleshooting authentication or connection issues
+- Working with advanced features (API, schedules, variables, etc.)
+
+## Common Issues Quick Fixes
+
+**"command not found: glab"** - Install glab or verify PATH
+
+**"401 Unauthorized"** - Run `glab auth login`
+
+**"404 Project Not Found"** - Verify repository name and access permissions
+
+**"not a git repository"** - Navigate to repo or use `-R owner/repo` flag
+
+**"source branch already has a merge request"** - Use `glab mr list` to find existing MR
+
+For detailed troubleshooting, load **references/troubleshooting.md**.
+
+## Notes
+
+- glab auto-detects repository context from Git remote
+- Most commands have `--web` flag to open in browser
+- Use `--output=json` for scripting and automation
+- Multiple GitLab accounts can be authenticated simultaneously
+- Commands respect Git configuration and current repository context