@ahumandev/autocode 0.0.1

package/dist/plugin.test.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=plugin.test.d.ts.map

package/dist/plugin.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"plugin.test.d.ts","sourceRoot":"","sources":["../src/plugin.test.ts"],"names":[],"mappings":""}

package/dist/skills/author-article/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: author-article
+description: Use `author-article` to get Professional Article/Report Format when reviewing/writing user content as articles/reports.
+---
+
+# Professional Article/Report Format
+
+Follow these instructions before reviewing/writing professional articles/reports
+
+## Editorial Rules
+
+- Use full human-readable sentences by default
+- Reduce long sentences > 40 words to smaller sentences (except in quoted text)
+- Fix spelling and grammar mistakes (except in quoted text)
+- Use British English by default in articles (unless different language requested)
+- Merge repetitions
+- Group long sections of continuous sentences in paragraphs, each paragraph focus on 1 argument/point of message.
+- A paragraph typically starts with a statement/fact, then contain sentences that explain this statement with examples.
+- Ensure content of the article does not deviate from topic of mentioned in the introduction section
+- Capitalize first letter of every word in titles, except short prepositions < 4 characters (in, on, at, to, by, of, up), conjunctions (and, but, for, or, not, so, yet), and articles (a, an, the).
+- NEVER modify quoted text even if it contains errors
+- NEVER change the meaning of the text, unless the user explicitly asked to do so
+
+## Style Rules
+
+- Add an introduction (if missing): Introductions should make it clear what topic the article will explore without giving away the main argument or point of the article. The introduction should rather trigger the reader's curiosity and encourage them to read it. The introduction should not be offensive to any group or people with a strong view point against the article main argument.
+- Write articles in third person
+- Check if the author's tone appears arrogant, offensive, or divisive. Replace sarcasm or rhetorical questions with objective statements.
+- Write content diplomatically so it does not offend any people group.
+- Use a professional tone, but explain academic or technical words in basic layman terms so non-Christians can understand.
+- Only allow statements like "I think", "We believe", "It's possible" if the author uses unproven opinions.
+- Replace em-dashes (—) and en-dashes (–) by breaking sentences up into multiple short sentences with periods that flow into each other (except in quoted text).
+- Replace only Old Testament bible verses that refer to `the Lord` (lowercase) with `the LORD` (ALL CAPS). New Testament bible verses may refer to `the Lord` (lowercase).
+- Use basic English vocabulary or explain complex academical terminology so that a non-English speaker or layman can understand.
+- The final conclusion should only summarize the main argument, point or purpose of the article without explanations and evidence. Each statement in conclusion should be backed by section in the main content with a Markdown link in the text to that section for further reading or evidence.
+
+## Credibility Rules
+
+- Rephrase confusing explanations, contradictions or fallacies
+- Clearly indicate what is facts vs what is opinions
+- Check that bible verses are quoted correctly from the bible: If a bible verse is incorrectly quoted, fix the quote. If the correct bible verses was referenced by comparing the context/sentence in which the bible verse appear. For example `Jesus said love your enemies (Genesis 1:1)` is wrong because that is not what Genesis 1:1 says. In these cases, replace it with the correct scripture reference.
+- Add additional evidence like bible scriptures or Markdown links in text to external websites to support the author's statements (if known sources are available)
+- Remove contradictions against the author's own content
+- The article should never contradict itself. Instead it should objectively list the different views of groups and let the reader decide which view he prefers.
+- Check for reasoning errors or fallacies: Rephrase the author's arguments to communicate the intended message but without logical reasoning errors.
+- When author make controversial statement: add typical critique (argument) and defense (counter-argument).
+- Enhance weak arguments with evidence or rephrase if no evidence could be provided.
+- If article links to external sites, check that sites exist and if not: Search for the site and fix link or remove it if not found.
+
+## Formatting Rules
+
+- The first line (after frontmatter) is the article's main title and must be H1 header level. There should only be 1 H1 title.
+- Keep H2 headers as short as possible, but still unique.
+- Ensure logical header hierarchy (no skipped levels).
+- Large sections (> 25 lines) should be subdivided into smaller subsections.
+- Use numerical points if the article mentions a specific sequence or priority.
+- Use bullet points only to list items.
+- Convert `--` double hyphens in quoted text to em dashes.
+- Quoted sources are formatted as `> Quoted text — Source`. Note that the em dash is wrapped with spaces on both sides. The source could be a bible verse, a name of another author or book, or a link to an external website.
+- If quoted source is bible verse, then include bible book abbreviation (for example: `John 3:16 (ESV)`); otherwise omit book abbreviation for inline bible references.
+- Correct bible verses of different books are separated by semicolons `;`, for example: `Genesis 1; Exodus 1:1; Leviticus 1`.
+- Correct bible verses of the same book but different chapters are separated by a comma and a space `, ` for example `Genesis 1:1, 2:1, 3:1`.
+- Correct bible verses of the same book and chapter are separated by a comma only `,` (without spaces) for example `Genesis 1:1-3,5-7,11,13`. If no colon `:` is included, you may assume the number refers to a verse of the previously stated chapter, for example `Genesis 1:1,3` means Genesis 1:1 and Genesis 1:3.
+
+## Markdown Rules
+
+- Convert underscore headers `-------------` to hashed prefix headers `##`
+- Content should be Markdown linter compliant
+- Code samples must be displayed in md code blocks specifying the correct language attribute
+- Add Markdown links in text to online websites or external md files in content if content was based on an external source
+- Double spaces before EOL character are allowed as they indicate line breaks in Markdown
+- Ensure that Markdown links within the same document to anchors/headers are valid.
+- Fragments are preserved, for example `path/page.md#anchor`
+- Images are co-located in the same directory as Markdown, unless they link to an external website
+- Image naming: `{page}.{descriptor}.{ext}` (avoid duplication if the image has the same name as the page, for example `church.church.jpg`)
+- Provide alt text for accessibility
+- Use mermaid diagrams to explain complex relationships, integrations or architectures
+- Strikethrough text as Markdown strikethrough: ~~strikethrough~~
+- Inline math formulas as Markdown inline math: $E = mc^2$
+- Block math formulas as Markdown block math: $$ ... $$
+- Links to online sources as Markdown links: [source name](url)
+- Public logos, icons, illustrations as Markdown images: ![alt text](url)
+
+## Layout Rules
+
+Default md layout (unless different layout was requested):
+```
+---
+description: [Description]
+keywords: [Keywords]
+---
+
+# [Title]
+
+[Introduction]
+
+## [Content Sections]
+
+### [Optional Sub-Sections]
+
+#### [Optional Sub-Sub-Sections...]
+
+## Conclusion
+
+[Conclusion Content]
+```
+
+- Conclusion should not repeat the problem, but summarize the solution to the problem mentioned in introduction
+- Conclusion MUST contain Markdown links to anchors within the article where the solution was displayed in more detail (like a TOC in natural language)
+- Prefer grouping instructions and examples together so that reader can follow instructions without jumping around in article
+
+## Frontmatter Rules
+
+- By default add frontmatter to each article (unless user indicates otherwise).
+- The article description will be used as a meta tag element that describes the page for SEO. Ensure that the description is search engine compliant and not longer than 160 characters. The description should compliment the introduction of the article by providing a brief description of which topic the article will explore without giving away the main argument or point of the article. The like the introduction, description should also be non-offensive to any group or view point. Description should not start with a verb, but rather a short intro explaining the problem the article address in such a way that it does not give away the solution but rather trigger curiosity to read further.
+- Update the `keywords` field of the frontmatter with sensible csv keywords related to the main points of this article. Use unique keywords that would make this article stand out among other articles. Avoid using common or generic terms as keywords.

package/dist/skills/author-caveman/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: author-caveman
+description: Use `author-caveman` to write Caveman English.
+---
+
+# Caveman English
+
+Verbose English: "Sure! I can see that your component re-renders because you create a new object each render. Perhaps wrap it in useMemo."
+Caveman English: "New obj each render. New ref = re-render. Wrap in useMemo."
+
+Caveman English Rules:
+- Cut pleasantries, filler, hedging, articles (a/an/the) when meaning stays clear
+- Prefer short plain words. Keep exact technical terms.
+- Use common abbreviations
+- Fragments OK if cause/action stays clear
+- Emoji only when it clarifies
+
+You MUST write Caveman English except: multi-step steps instructions, SQL, errors, quotes, links, code, technical terms, values.

package/dist/skills/author-readme/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: author-readme
+description: Use `author-readme` to get "README.md Format" when reviewing/writing or updating README.md files.
+---
+
+# README.md Format
+
+- README.md must be written for humans in professional, user-manual style natural language 
+- Use full sentences except diagrams and listing items like features
+- Use British English by default (unless specified otherwise)
+- Assume user has limited technical knowledge, but understand technical terminology (no need to explain basic technical terms like "docker", "compile", "proxy", etc.)
+- Code examples must specify the correct language attribute for syntax highlighting
+- Do not invent exact command output. If exact output is not known, describe the expected result in prose.
+- Use only links that are present in the repository, existing README, package metadata, build files, or supplied documentation.
+- Do not create links to internal files unless the file path is known.
+- Prefer relative links for repository files.
+- Mermaid diagrams must be high-level, readable, and syntactically valid.
+- Prefer `flowchart TD` for integration and component diagrams.
+- Use short node labels.
+- Do not include secrets, environment-specific hostnames, or internal credentials in diagrams.
+- Use one H1 heading only.
+- Use sequential heading levels without skipping levels.
+- Surround headings and fenced code blocks with blank lines.
+- Specify a language for every fenced code block, for example `bash`, `json`, `yaml`, `sql`, `text`, or `mermaid`.
+- Do not use trailing spaces.
+- Use hyphens for unordered lists.
+
+## README.md Layout
+
+```markdown
+<p align="center">[LOGO]</p>
+
+<h1 align="center">[Project Name]</h1>
+
+<h3 align="center">[HERO]</p>
+
+[PURPOSE]
+
+---
+
+## Features
+
+[FEATURES]
+
+[INTEGRATION]
+
+## Installation
+
+[PREREQUISITES]
+
+[LOCAL SETUP STEPS]
+
+[STARTUP STEPS]
+
+## Usage
+
+[COMMON USAGE]
+
+[TUTORIAL]
+
+## Configuration
+
+[CONFIGURATION]
+
+## Development
+
+[ARCHITECTURE]
+
+[DEVELOPER NOTES]
+
+### Testing
+
+[TESTING]
+
+### Deployment
+
+[PACKAGING STEPS]
+
+[DEPLOYMENT STEPS]
+
+## Terminology
+
+[ACRONYMS]
+
+[DEFINITIONS]
+
+```
+
+Replace placeholders in README.md as follows:
+
+- [LOGO]: Determine the logo as follow:
+    1. Use `autocode_logo_find` tool to find a logo. 
+    2. If `autocode_logo_find` returns a logo path, replace [LOGO] with `<img src="{path to logo}" alt="Project Logo" height="128">`. 
+    3. If no logo was found, use an appropriate emoji to replace [LOGO] with `<span style="font-size: 96px; text-shadow: -3px -3px 0 #000, 3px -3px 0 #000, -3px  3px 0 #000, 3px 3px 0 #000, 0 -3px 0 #000, 0 3px 0 #000, -3px 0 0 #000, 3px 0 0 #000;">{emoji}</span>`.
+- [Project Name]: Project name in a natural title format. If unknown: derive title from repo name
+- [HERO]: Catching advertising title as follows:
+    - Summarize what project does in positive way like marketing advert
+    - Max 20 words
+    - No definitions in this section
+    - Use only common words, not project specific terminology (except for naming components)
+- [PURPOSE]: Motivate why this project should exist as follows:
+    - Briefly describe problem it solves and solution/benefit of using this project
+    - Use marking style: Wording should encourage stakeholders to invest time to setup and use system
+    - Do not list any technical features, instead mention problems it solve (use cases)
+    - Max 80 words
+    - No definitions in this section
+    - Use only common words, not project specific terminology (except for naming components)
+- [FEATURES]: Advertise core features in markdown bullets as follows: 
+    - 1 feature per bullet
+    - Unique emoji per feature
+    - Max 40 words per feature
+    - No definitions in this section
+    - Use only common words, not project specific terminology (except for naming components)
+- [INTEGRATION]: Explain how project integration with external systems (like miroservices):
+    - Title summarize how it integrations (max 7 words), like "REST Integration" or "Microservice Architecture"
+    - Include high-level Mermaid diagram of how it integrates
+    - Only include [INTEGRATION] section if this project does integrate with external systems
+- [PREREQUISITES]: System requirements and dependencies needed before installation as follows:
+    - List prerequisites as bullet points: 1 per dependency
+    - Provide markdown links in text to online sources that provide guidance where to download or how to install dependency
+    - Only include [PREREQUISITES] if project does depend on other systems
+- [LOCAL SETUP STEPS]: Commands and steps to set up the project locally as follows:
+    - Provide sequential steps
+    - Each step must include an example command/config/user action
+    - Each step must include an example response/output (if known)
+    - Provide minimal configuration/commands just to get a demo/basic version going
+    - Format examples with proper markdown block formatting where appropriate
+    - Only include [LOCAL SETUP STEPS] if project does require a setup
+- [STARTUP STEPS]: Commands to start the project
+    - Provide sequential steps
+    - Each step must include an example command/config/user action
+    - Each step must include an example response/output (if known)
+    - Format examples with proper markdown block formatting where appropriate
+    - Explain different modes project support (for example development vs production mode)
+    - If startup modes are vastly different organize it in different sub-sections
+    - Only include [STARTUP STEPS] if project does require a server/service to start
+- [COMMON USAGE]: Explain how to use system as follows:
+    - Provide primary commands (if applicable)
+    - Provide primary URLs (if applicable)
+    - Explain how user can navigate through application to reach primary features (if applicable)
+    - Include example input/output in markdown blocks/tables (if possible)
+    - ONLY include usage of feature that is currently available 
+    - NEVER include deprecated/uninplemented/planned/future features
+- [TUTORIAL]: Step-by-step guide for common user flows as per `author-tutorial` skill.
+- [CONFIGURATION]: Explain every project specific configuration setting as follow:
+    - Provide tables of every custom config key/property/env var that project accepts with descriptions and default values and valid ranges or alternative enums
+    - NEVER include standard framework properties like Spring Boot/Angular/Nuxt configs or any standard OS env vars
+    - ONLY include known (proven) configuration (no guessing)
+    - Only include this section if project has custom configuration
+- [ARCHITECTURE]: Explain how project fulfill its purpose describe in [PURPOSE] as follow:
+    - If project is full stack: Include high-level Mermaid diagram of how different components of project interact with each other
+    - If project contains complex event system: Include high-level Mermaid diagram of how events/data flow 
+    - If project contains multiple pages of static web content: Include high-level Mermaid diagram of primary pages link to each other (sitemap)
+    - If project is library or monolithic application: Include high-level Mermaid diagram of primary internal components and how they relate to each other
+    - If project is CLI tool: Include high-level Mermaid diagram of how data typically flow through this tool: inputs -> processes -> outputs
+    - Project may solve more than 1 problem (multi-purpose project): In such case identify each primary goal, then for each goal:
+        - Write 1 paragraph per goal (max 200 words) how it solves that specific goal
+        - Include markdown links in text to core source files responsible for solution or where additional documentation could be found
+    - Omit this section is project architecture is unclear, empty or new (no guessing)
+- [DEVELOPER NOTES]: Any special notes that developers of the project should be aware of like: Special commands to build project, common pitfalls, unusual file locations/config/commands required, quality standards, etc.
+    - May contain sub-sections (max 200 words per section)
+    - Must be human readable and may contain examples to explain intend
+    - Keep this section as lean as possible and AVOID REPEATING any info mentioned in other sections of this document
+    - Only include this optional section if you have important info to make developers aware of
+- [TESTING]: Steps how to test local development quality as follow:
+    - Provide sequential steps
+    - Each step must include an example command/config/user action
+    - Each step must include an example response/output (if known)
+    - Format examples with proper markdown block formatting where appropriate
+    - Only include this section if project does contain tests
+- [PACKAGING STEPS]: Steps to build/package for production as follows:
+    - Provide sequential steps
+    - Each step must include an example command/config/user action
+    - Each step must include an example response/output (if known)
+    - Format examples with proper markdown block formatting where appropriate
+    - Only contain this section if project needs packing for production deployment
+- [DEPLOYMENT STEPS]: Steps to deploy to production as follows:
+    - Provide sequential steps
+    - Each step must include an example command/config/user action
+    - Each step must include an example response/output (if known)
+    - Format examples with proper markdown block formatting where appropriate
+    - If different deployment environments are supported (e.g. local vs docker): Organize in sub-sections
+    - Only include this section if production deployment is different from [LOCAL SETUP STEPS]
+
+## Rules for Updates
+- If current README.md already follows this layout, only update outdated or missing sections
+- If current README.md already exist, but in different format:
+    1. Identify critical info to keep
+    2. Reorganize original README.md according to this specification
+    3. Verify that critical info is still included and in correct section
+- Remove empty sections or sections with no factual content (no guessing or "coming soon" placeholders)
+- Ensure all markdown links to internal project files or external sites are valid
+- Updated/Remove outdated info (if detected)
+- Avoid duplicated content (instead add markdown links in text that refers to previous sections of same content applies)
+- First time non-standard acronym is used: include definition in round brackets (), for example: "It guard UST (User Security Tables) when configured."
+- First time non-standard definition is used: include an INFO block below the paragraph where it was used to explain what it is in < 20 words.
+- NEVER repeat definitions, only first occurrence.
+- NEVER mention deprecated tools or configs
+- Keep examples updated with current tools/APIs/configs

package/dist/skills/author-rules/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: author-rules
+description: Use `author-rules` get Agent Rule Format when reviewing/writing agent prompts, commands or AGENTS.md
+---
+
+# Agent Rule Format
+
+When writing agent prompts, commands or AGENTS.md apply this layout:
+
+## Layout 
+
+Layout Template:
+
+```
+# [TITLE]
+
+[PURPOSE]
+
+[USER REQUEST ANALYSIS]
+
+[WORKFLOW]
+
+[CONDITIONAL INSTRUCTIONS]
+
+[USER CONTENT]
+
+[RULES]
+```
+
+Replace above [PLACEHOLDERS] in Layout Template with:
+
+[TITLE]
+- Unique description of rules file
+- Must be < 7 words
+- Type of rule file determine title:
+  - Agent prompt: [TITLE] = Agent role (e.g. "Java Coder")
+  - Skill: [TITLE] = What knowledge and/or ability agent should expect (e.g. "Spring Boot Applications")
+  - AGENTS.md: [TITLE] = Scope of instructions (e.g. Project name for root AGENTS.md "Autocode Plugin" or Package purpose for sub AGENTS.md like "Business Services")
+
+[PURPOSE]
+- Agent prompt + multiple AGENTS.md files + skill files will be concatenated into 1 system prompt which may confuse agent about when to apply which rules
+- Solution: Define purpose for rule set such that agent understands when or how to apply rules
+- Must be < 20 words
+- Type of rule file determine title:
+  - Agent prompts: [PURPOSE] = High-level responsibilities of agent (e.g. "You write professional Java Code...")
+  - Skill: [PURPOSE] = Conditions when rules become relevant (e.g. "When designing Spring Boot Application...")
+  - AGENTS.md: [PURPOSE] = What content to find in scope AGENTS.md file covers: root AGENTS.md summarize purpose of entire project; sub AGENTS.md summarize purpose of sub-scope
+
+[USER REQUEST ANALYSIS]
+- Only include [USER REQUEST ANALYSIS] for agent prompts or commands
+- Defining "user request":
+  - commands: "user request" = existing session context
+  - agent prompts: "user request" = user's original prompt
+
+1. This section must first indicate how to categorize each type of supported "user request" in < 20 words per category
+2. Then this section must map each category to workflow/conditional instructions and/or any special rules that may apply for that condition in < 40 words per category
+
+- [USER REQUEST ANALYSIS] must also indicate how to handle unsupported "user requests" in < 20 words
+- Omit [USER REQUEST ANALYSIS] section entirely if all user request should be treated the same
+
+[CONDITIONAL INSTRUCTIONS]
+- Conditional Instructions may be 1 or more primary sections
+- Unlike Workflows that contain fixed sequential steps, conditional instructions apply ad-hoc based on conditions
+- Typical examples:
+    - Interviewing User
+    - Handling Errors
+    - Presenting Report
+- Each Conditional Instruction section must start with condition: when to apply instructions
+- Numeric list of sequential instructions agent must follow
+- Keep instructions concise but understandable in < 40 words per instruction
+- Large (40+ lines) or complex [CONDITIONAL INSTRUCTIONS] should be moved to separate skills or references/ folders to be loaded ad-hoc
+
+[USER CONTENT]
+- Omit entire [USER CONTENT] section by default, unless user specified additional content
+- Format content according to user request
+- May span across multiple primary sections
+- May include examples
+- Preferably keep write content as concise bullet points (unless user specified different format)
+
+[RULES]
+- Must be section final in md file
+- Only include very critical (dangerous consequence if not adhered - e.g. forbidden actions/limiting scope) rules or common rules that always applies (edge-cases belong in [CONDITIONAL INSTRUCTIONS] section)
+- When rules contradict: Add conditions when each contradicting rule applies
+- Must be < 40 words per rule (excluding conditions)
+
+[WORKFLOW]
+- Only include [WORKFLOW] section if rules contain sequential instructions (steps)
+- It usually follows default happy path to accomplish specific purpose of agent
+- ALWAYS omit entire [WORKFLOW] section for AGENTS.md (too general)
+
+Workflow Template:
+
+```
+
+---
+
+## Workflow
+
+[WORKFLOW TOC]
+
+### STEP 1: [STEP TITLE]
+
+[STEP GOAL]
+
+[STEP INSTRUCTIONS]
+
+[STEP EXAMPLE]
+
+### Step 2...
+
+---
+
+```
+
+Line dividers (`---`) helps to organize large Workflow with its steps together
+
+Replace above [PLACEHOLDERS] in Workflow Template with:
+
+[WORKFLOW TOC]
+Include every step section's header without "STEP X: " prefixes in same order steps appear
+
+For example:
+
+```md
+
+---
+
+## Workflow
+
+1. Analyze Problem
+2. Solve Problem
+3. Test Solution
+
+### STEP 1: Analyze Problem
+...
+
+### STEP 2: Solve Problem
+...
+
+### STEP 3: Test Solution
+...
+
+---
+
+```
+
+[STEP GOAL]
+
+Briefly describe goal of specific STEP in < 20 words
+
+[STEP INSTRUCTIONS]
+
+- Numeric list of sequential step instructions agent must follow
+- Keep instructions concise but understandable in < 40 words per instruction
+
+[STEP EXAMPLE]
+
+- Only include examples for complex STEPS or specific templates
+- User provided examples MUST be keep as-is (no stripping, reducing, formatting or any other modifications allowed)
+- Keep generated examples minimalistic but understandable to limited LLM
+- Generate max 1 good example per step (if no user example was provided)
+- Generate only bad examples if common pitfalls are expected that should be avoided
+- Never generate examples for obvious steps
+- When writing skills: Extract large examples/templates (> 40 lines) to template files (located in `.agents/skills/{skill-name}/templates/`) with references to `templates/{template-file}` in original skill
+
+## Rules
+
+- ALWAYS speak and write Caveman English
+- Each point < 20 words
+- No repetitions
+- Only use emojis to highlight important aspects to LLM, like attention, warning, checklists, correct vs wrong
+- Always keep md < 400 lines by:
+  - Cleaning up redundant content
+  - Removing excessive examples
+  - Only if skill's [USER CONTENT] section is > 200 lines:
+    1. Divide content into smaller < 200 line sections
+    2. Divided skills user content should not overlap
+    3. Move subdivided content to reference files (located in `.agents/skills/{skill-name}/references/`)
+    4. Refer to `reference/{reference-name}` references in original `SKILL.md` with instruction when load which reference
+    5. Report list of skill files you created to user
+  - Otherwise summarize trivial info in [USER CONTENT] section
+  - As last resort: Reducing/grouping obvious instructions agent can derive by itself

package/dist/skills/author-skill/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: author-skill
+description: Use `author-rules` to get Skill File Authoring when you need to review/write skill files for agents.
+---
+
+# Skill File Authoring
+
+Use this Skill Template to review/write skill files:
+
+---
+
+## Skill Template 
+
+Write skill Template:
+
+```markdown
+---
+name: [NAME]
+description: Use `[NAME]` to get [TOPIC] if [CONDITION].
+---
+
+# [TOPIC]
+
+[TRIGGERS]
+
+---
+
+[CONTENT]
+
+---
+
+[RULES]
+```
+
+Replace above [PLACEHOLDERS] in Layout Template with:
+
+* Replace [NAME] with short skill name as follows:
+  - 4 words max
+  - Prefix with `author-` for skill related to human readable content, articles
+  - Prefix with `code-` for skill related to project source code, configurations, scripts
+  - Prefix with `design-` for skill related to project designs (architecture)
+* [TOPIC] with short topic in Caveman English as follows:
+  - Unique header summarizing topic skill addresses - What knowledge and/or ability agent should expect (e.g. "Deploying Spring Boot Applications")
+  - Must be < 7 words
+  - Use exact phrase and case consistently
+* [TRIGGERS] with description of when topic is relevant (< 20 words) like "Understand how to build and package Spring Boot Application for production deployments, ..."
+* [CONTENT] translate content from user request into Caveman English:
+  - Preferably format as structured sequence lists or bullet points
+  - May include formatted examples when applicable
+  - Prefer linking to templates, scripts, references, external sources instead of embedding verbose content to keep SKILL.md lean
+* [RULES] important rules regarding agents behavior to apply skill:
+  - Optional: Only include if behavioral changes are required
+  - Must be last section SKILL.md
+  - Only include very critical instructions or limitations that always apply
+  - When rules contradict: Add conditions when each contradicting rule applies
+
+---
+
+## Rules
+
+- ALWAYS write skill files in `.agents/skills/{name}/SKILL.md`
+- Place templates, scripts, references in subdirectories from skill directory `.agents/skills/{name}/` and link to it from `SKILL.md`, for example: `templates/email_template.html`, `scripts/process_data.py`
+- Keep templates, scripts, reference files also lean (only keep important info and valuable example snippets).
+- No repetitions
+- Only use emojis to highlight important aspects to LLM, like attention, warning, checklists, correct vs wrong
+- ALWAYS keep md < 400 lines by:
+  - Cleaning up redundant content
+  - Removing excessive examples
+  - Summarize trivial info in [CONTENT] section
+  - Only if skill's  [CONTENT] section is > 200 lines:
+    1. Divide content into smaller < 200 line sections
+    2. Divided skills user content should not overlap
+    3. Move subdivided content to reference files (located in `.agents/skills/{name}/`) and link to it
+  - As last resort: Reducing/grouping obvious instructions agent can derive by itself
+
+___
+
+Use this same skill text as an example on how to format other skills.

package/dist/skills/author-tutorial/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: author-tutorial
+description: Use `author-tutorial` to get Tutorial Format when reviewing/writing tutorial or manual user step guide.
+---
+
+# Tutorial Format
+
+A tutorial guide a human user to complete an assignment manually.
+
+1. Determine goal of assignment (tutorial)
+2. Breakdown human assignment into practical steps.
+3. Each step must be formatted as a subsection of tutorial section and formatted as follows:
+   - Must include an example command/config/user action
+   - Must include an example response/output (if known)
+
+## Important Tutorial Rules   
+
+- Communicate to human: Full but concise sentences, first person as guide
+- Tutorial Steps must be placed in correct sequential order
+- Entire tutorial must be < 400 lines (remove trivial examples if necessary)    
+- Where user can decide on different workflow paths, format each workflow as different subsection
+- Include warnings about common pitfalls
+- Use emojis to highlight important info
+- Start every step title with emoji