@mohammadhprp/system-prompt 0.11.0 → 0.11.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mohammadhprp/system-prompt",
-  "version": "0.11.0",
+  "version": "0.11.2",
   "description": "AI Coding Agent Framework — interactive bootstrap CLI",
   "keywords": [
     "ai",

package/src/catalog.js

@@ -6,20 +6,32 @@ export const categories = {
     items: [
       { id: 'agent-browser', name: 'Agent Browser', description: 'Automate browser and Electron workflows for navigation, testing, screenshots, and data extraction' },
       { id: 'backend-best-practices', name: 'Backend Best Practices', description: 'Consolidated backend engineering practices across API, data, security, testing, and operations' },
-      { id: 'backend-engineer', name: 'Backend Engineer', description: 'Analyze backend requirements, risks, and implementation plans' },
       { id: 'brainstorming', name: 'Brainstorming', description: 'Turn ideas into fully formed designs through dialogue' },
       { id: 'brand-guidelines', name: 'Brand Guidelines', description: 'Apply official brand colors and typography' },
       { id: 'code-review', name: 'Code Review', description: 'Review backend changes for correctness and maintainability' },
+      { id: 'codenavi', name: 'CodeNavi', description: 'Navigate unknown codebases with precision, a persistent .notebook knowledge base, and surgical implementation' },
+      { id: 'create-adr', name: 'Create ADR', description: 'Create Architecture Decision Records documenting significant architectural choices and rationale' },
       { id: 'design', name: 'Design Like Damien', description: 'Premium UI design philosophy and Lovable prompting' },
       { id: 'diagram-design', name: 'Diagram Design', description: 'Create technical and product diagrams as standalone HTML with inline SVG' },
-      { id: 'documentation', name: 'Documentation', description: 'Create ADRs, design docs, runbooks, and API docs' },
+      { id: 'docs-writer', name: 'Docs Writer', description: 'Write, review, and edit documentation files with consistent structure, tone, and technical accuracy' },
       { id: 'find-skills', name: 'Find Skills', description: 'Discover, evaluate, and install agent skills for specialized tasks' },
+      { id: 'frontend-design', name: 'Frontend Design', description: 'Distinctive, intentional visual design for new UI or reshaping existing UI' },
       { id: 'gitlab-mcp', name: 'GitLab MCP', description: 'Work with GitLab via MCP for MRs, issues, pipelines' },
+      { id: 'humanizer', name: 'Humanizer', description: 'Remove signs of AI-generated writing to make text sound more natural and human' },
       { id: 'jira-mcp', name: 'Jira MCP', description: 'Work with Jira MCP for issue management and JQL search' },
       { id: 'laravel-best-practices', name: 'Laravel Best Practices', description: 'Laravel patterns for Eloquent, validation, testing' },
+      { id: 'learning-opportunities', name: 'Learning Opportunities', description: 'Facilitate deliberate skill development during AI-assisted coding with short, interactive exercises' },
       { id: 'lavish', name: 'Lavish', description: 'Turn complex responses into rich HTML artifacts' },
       { id: 'notion-mcp', name: 'Notion MCP', description: 'Work with Notion MCP for pages, databases, search' },
-      { id: 'skill-creator', name: 'Skill Creator', description: 'Create and evaluate new agent skills' }
+      { id: 'perf-web-optimization', name: 'Web Performance Optimization', description: 'Optimize web performance: bundle size, images, caching, lazy loading, and overall page speed' },
+      { id: 'security-best-practices', name: 'Security Best Practices', description: 'Language and framework specific security best-practice reviews and secure-by-default coding help' },
+      { id: 'sentry', name: 'Sentry', description: 'Inspect Sentry issues, summarize production errors, and pull health data via the Sentry API' },
+      { id: 'show-me', name: 'Show Me', description: 'Explain the current topic visually with diagrams, code-shape sketches, and focused HTML artifacts' },
+      { id: 'skill-creator', name: 'Skill Creator', description: 'Create and evaluate new agent skills' },
+      { id: 'spec-driven-eval', name: 'Spec-Driven Eval', description: 'Score how completely an implementation fulfills a PRD/spec, case by case, into a single comparable grade' },
+      { id: 'technical-design-doc-creator', name: 'Technical Design Doc Creator', description: 'Create comprehensive Technical Design Documents with mandatory and optional sections through interactive discovery' },
+      { id: 'tlc-spec-driven', name: 'TLC Spec-Driven', description: 'Feature planning and implementation with adaptive phases, EARS testable requirements, atomic commits, and independent verification' },
+      { id: 'web-design-guidelines', name: 'Web Design Guidelines', description: 'Review UI code for Web Interface Guidelines compliance: accessibility, interaction patterns, and design best practices' }
     ],
   },
 

package/src/installer.js

@@ -10,7 +10,72 @@ const packageRoot = resolve(__dirname, '..');
 
 const AGENTS_MD = `# AGENTS.md
 
-> Fill this base on project use /init command
+Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
+
+Read CONTEXT.md for repository-specific setup, commands, architecture, tests, and workflow guidance.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines, and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multistep tasks, state a brief plan:
+
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+
+---
+
+**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.
+
 `;
 
 const OPENCODE_GITIGNORE = `.env*

package/framework/skills/backend-engineer/SKILL.md

@@ -1,76 +0,0 @@
----
-name: backend-engineer
-description: Analyze backend requirements, risks, and implementation plans before coding.
-version: 0.1.0
----
-# Purpose
-Analyze backend requirements, risks, and implementation plans before coding. This skill guides an AI agent to act with senior backend judgment: clarify the outcome, identify constraints, choose the least complex safe path, and make production impact visible.
-
-# When to Activate
-Use this skill when the task involves general backend planning, requirement analysis, problem breakdown, complexity estimates, risk evaluation, and simple solution selection. It is also useful when a request is vague, risky, touches production behavior, changes contracts, changes data, or needs a reviewable engineering plan. Do not activate it for trivial text edits unless the edit changes engineering guidance.
-
-# Principles
-- Correctness and data integrity come before speed of implementation.
-- Simplicity is a feature: fewer moving parts means fewer failure modes.
-- Existing contracts must remain compatible unless a breaking change is approved.
-- Every important decision should have a reason, an alternative considered, and an operational consequence.
-- Work should be testable, observable, deployable, and reversible.
-- Prefer explicit boundaries, clear names, and local reasoning over clever shared abstractions.
-- Security and privacy are design inputs, not final review steps.
-
-- Requirements analysis must identify users, workflows, data ownership, invariants, and constraints.
-- Break problems into contract, domain, persistence, operations, and delivery concerns.
-- Estimate complexity by counting boundaries, state transitions, migration steps, and failure modes.
-- Evaluate risks before implementation: data loss, authorization gaps, compatibility breaks, latency, and operational burden.
-- Choose the simplest solution that satisfies current known needs and can evolve safely.
-
-# Workflow
-1. Restate the user goal in concrete backend terms with explicit scope and non-goals.
-2. Identify actors, data entities, invariants, and failure modes.
-3. Identify external dependencies, integration points, and data flows.
-4. Inspect existing project patterns and conventions before proposing changes.
-5. Decide whether clarifying questions are needed. Ask only questions that materially affect design or risk.
-6. Produce a small plan: contract, data changes, behavior changes, tests, observability, deployment, rollback.
-7. Compare at least one simpler alternative when the proposed solution adds complexity.
-8. Verify with the narrowest meaningful tests, then broader checks when risk justifies them.
-9. Summarize tradeoffs, residual risks, and follow-up work.
-
-# Rules
-- Never assume hidden requirements, traffic scale, compliance needs, or data retention rules.
-- Do not introduce new infrastructure unless the current requirement cannot be met safely without it.
-- Do not hide breaking changes in refactors.
-- Do not weaken authorization, validation, transaction safety, or error handling to make implementation easier.
-- Keep public contracts, migrations, and operational changes explicit in the deliverable.
-- Reference related standards: references/standards/architecture.md, references/standards/testing.md.
-
-# Deliverables
-- A concise engineering plan or review summary.
-- Explicit assumptions and clarifying questions when needed.
-- Contract, data, test, observability, deployment, and rollback notes for production changes.
-- Concrete risks with mitigations.
-- A checklist showing completion evidence.
-
-# Common Mistakes
-- Starting with code before understanding invariants, data ownership, or failure modes.
-- Designing for imagined future scale while ignoring present correctness.
-- Treating validation, authorization, logging, and tests as optional polish.
-- Creating generic abstractions after seeing only one use case.
-- Optimizing without measurement or failing to define the target metric.
-- Writing documents that describe implementation but omit failure handling.
-
-# Failure Modes
-- A simple request becomes a broad rewrite because scope was not bounded.
-- A change works locally but cannot be safely deployed or rolled back.
-- Data becomes inconsistent because constraints or transactions were skipped.
-- Operators cannot diagnose incidents because logs and metrics are missing.
-- Reviewers cannot evaluate risk because decisions and assumptions are implicit.
-
-# Checklist
-- [ ] Goal, scope, and non-goals are clearly defined.
-- [ ] Simpler alternatives were considered and documented.
-- [ ] Data integrity and backward compatibility are protected.
-- [ ] Security and authorization impact is reviewed.
-- [ ] Tests cover normal paths, edge cases, and failure paths.
-- [ ] Logs, metrics, traces, or health signals are included when operationally relevant.
-- [ ] Deployment and rollback are understood and tested.
-- [ ] The deliverable explains reasoning and evidence, not just code.

package/framework/skills/backend-engineer/examples.md

@@ -1,31 +0,0 @@
-# Backend Engineer Examples
-
-## Example 1: User Settings API
-
-Implement an endpoint that reads and updates user notification preferences. Good agent behavior:
-
-- Identify actors (user, admin) and data ownership rules—user sees own settings, admin sees tenant-wide defaults.
-- Choose a caching strategy: cache by user_id with a short TTL; invalidate on write via cache-aside pattern.
-- Validate setting keys against an allowlist, reject unknown keys with a 422 error and a list of valid options.
-- Design the update to be partial (PATCH) so clients send only changed fields; merge with stored defaults.
-- Add a rate limit on writes to prevent abuse; reads can be higher but still bounded.
-
-## Example 2: Notification Service
-
-Design a service that sends email and push notifications when orders are placed. Good agent behavior:
-
-- Evaluate sync vs async delivery: accept the notification request synchronously but hand delivery off to a queue for resilience.
-- Implement a retry mechanism with exponential backoff for transient failures; dead-letter after 3 attempts.
-- Deduplicate by notification_id so the same event is not sent twice if the producer retries.
-- Template notifications server-side so copy changes don't require app releases.
-- Emit telemetry for each notification channel (sent, delivered, bounced, opened) to track provider health.
-
-## Example 3: Inventory Reservation
-
-Design inventory reservation for a checkout flow with a 15-minute payment window. Good agent behavior:
-
-- Reserve inventory atomically at checkout time; release the reservation if payment is not completed within the window.
-- Handle concurrent requests: use SELECT FOR UPDATE or optimistic locking to prevent overselling.
-- On payment failure, roll back the reservation immediately and asynchronously notify the warehouse.
-- Implement a background job that releases expired reservations every minute; log releases for audit.
-- Add metrics for reservation success, expiration, and contention rate to tune the timeout and capacity.

package/framework/skills/documentation/SKILL.md

@@ -1,74 +0,0 @@
----
-name: documentation
-description: Create ADRs, design docs, runbooks, API docs, and operational knowledge that stays useful.
-version: 0.1.0
----
-# Purpose
-Create ADRs, design docs, runbooks, API docs, and operational knowledge that stays useful. This skill guides an AI agent to act with senior backend judgment: clarify the outcome, identify constraints, choose the least complex safe path, and make production impact visible.
-
-# When to Activate
-Use this skill when the task involves ADRs, design documents, runbooks, API documentation, operational documentation, architecture diagrams, or knowledge transfer. It is also useful when a request is vague, risky, touches production behavior, changes contracts, changes data, or needs a reviewable engineering plan. Do not activate it for trivial text edits unless the edit changes engineering guidance.
-
-# Principles
-- Correctness and data integrity come before speed of implementation.
-- Simplicity is a feature: fewer moving parts means fewer failure modes.
-- Existing contracts must remain compatible unless a breaking change is approved.
-- Every important decision should have a reason, an alternative considered, and an operational consequence.
-- Work should be testable, observable, deployable, and reversible.
-- Prefer explicit boundaries, clear names, and local reasoning over clever shared abstractions.
-- Security and privacy are design inputs, not final review steps.
-
-- ADRs record decisions, context, consequences, and alternatives.
-- Design documents explain proposed behavior before expensive implementation.
-- Runbooks explain how to operate, diagnose, mitigate, and escalate.
-- API documentation must define contracts, errors, authorization, examples, limits, and compatibility.
-- Architecture diagrams should show boundaries, data flow, ownership, and failure paths.
-- Documentation should be close to the workflow where it is used.
-
-# Workflow
-1. Identify the audience and their primary use case for the document.
-2. Choose the right document type: ADR, design doc, runbook, API reference, README.
-3. Define the scope: what decisions, behavior, or procedures are covered.
-4. Write the document starting with the summary for busy readers.
-5. Include concrete examples, not just abstract descriptions.
-6. Add failure modes and operational notes where relevant.
-7. Cross-reference related documentation, code, and standards.
-8. Place the document close to where it is used (same repo, same directory).
-9. Review for accuracy with someone who was not involved in the writing.
-
-# Rules
-- Never assume hidden requirements, traffic scale, compliance needs, or data retention rules.
-- Do not introduce new infrastructure unless the current requirement cannot be met safely without it.
-- Do not hide breaking changes in refactors.
-- Do not weaken authorization, validation, transaction safety, or error handling to make implementation easier.
-- Keep public contracts, migrations, and operational changes explicit in the deliverable.
-- Reference related standards: references/standards/documentation.md.
-
-# Deliverables
-- Document with clear audience, purpose, and type.
-- Concrete examples reflecting real usage.
-- Failure modes and operational notes where relevant.
-- Cross-references to related code, standards, and docs.
-- Ownership and update cadence defined.
-
-# Common Mistakes
-- Writing documents that repeat what the code already expresses without adding decision context.
-- Creating documentation that is too long or too vague to be useful under time pressure.
-- Letting documentation become stale because there is no ownership or review process.
-- Writing for an imaginary audience instead of actual readers.
-- Including implementation details that change frequently while omitting stable design decisions.
-
-# Failure Modes
-- A runbook is too long to read during an incident.
-- An ADR describes what was decided but not why alternatives were rejected.
-- Documentation lives in a separate wiki that no one updates after the initial write.
-- Critical operational knowledge exists only in the head of one team member.
-
-# Checklist
-- [ ] The document has a clear audience and purpose.
-- [ ] The document type matches the content (ADR, runbook, design doc, etc.).
-- [ ] Examples are concrete and reflect real usage.
-- [ ] Failure modes and operational notes are included where applicable.
-- [ ] Cross-references to code, standards, or related docs are accurate.
-- [ ] The document is reviewable by someone not involved in its creation.
-- [ ] Ownership and update cadence are defined.

package/framework/skills/documentation/examples.md

@@ -1,31 +0,0 @@
-# Documentation Examples
-
-## Example 1: ADR for Cache Strategy
-
-Write an ADR documenting the decision to add Redis caching for product catalog reads. Good agent behavior:
-
-- State the context: product catalog reads are 500 req/s, each takes 50ms from PostgreSQL, and latency spikes during flash sales.
-- List alternatives considered: in-memory cache (lost on restart, per-node inconsistency), read replicas (cost, replication lag), CDN (static data only).
-- Describe the decision: Redis cache-aside with 5-minute TTL and immediate invalidation on price or stock changes.
-- Record consequences: increased operational complexity (need Redis cluster, monitoring), cache hit ratio must be >90% to justify cost.
-- Link to related ADRs for deployment topology and monitoring setup.
-
-## Example 2: Runbook for Payment Failure
-
-Write a runbook for diagnosing payment processing failures. Good agent behavior:
-
-- Start with the alert trigger (e.g., >5% payment failures in 5 minutes) and the severity level.
-- Provide step-by-step diagnosis: check the payment provider status page, then look at the circuit breaker state, then inspect dead-letter queue.
-- List the dashboards and log queries needed (payment error rate by provider, latency p95, DLQ count).
-- Include remediation steps: toggle the kill switch to fallback provider, reset circuit breaker after provider recovers, replay DLQ messages.
-- End with escalation contacts and a post-mortem template link for the follow-up.
-
-## Example 3: API Docs for Public Endpoint
-
-Document a public POST /orders endpoint for external developers. Good agent behavior:
-
-- Show a complete request example with all fields, including `Idempotency-Key` in the header and `X-Api-Version`.
-- Show success (201), validation error (422), and conflict (409) response bodies with annotated fields.
-- Document authentication: `Bearer` token in the `Authorization` header with required scopes.
-- Note rate limits (100 req/min per token) and include `X-RateLimit-Remaining` in the response.
-- List every error code with a human-readable message, a likely cause, and a recovery action.