natureco-cli 5.18.3 → 5.20.0

package/skills/openclaw-secure-linux-cloud/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: openclaw-secure-linux-cloud
+description: Use when self-hosting OpenClaw on a cloud server, hardening a remote OpenClaw gateway, choosing between SSH tunneling, Tailscale, or reverse-proxy exposure, or reviewing Podman, pairing, sandboxing, token auth, and tool-permission defaults for a secure personal deployment.
+---
+
+## Overview
+
+Use this skill for the conservative "deploy first, expose later" pattern for
+OpenClaw on a cloud server.
+
+Default to a private control plane:
+
+- Harden the Linux host before exposing anything.
+- Keep the gateway bound to `127.0.0.1`.
+- Reach the Control UI through an SSH tunnel first.
+- Keep token authentication, pairing, and sandboxing enabled.
+- Start with a narrow tool profile and loosen only with an explicit need.
+
+This skill is for secure Linux cloud hosting. If the user only wants the
+fastest generic OpenClaw install on a local machine, prefer the official
+OpenClaw onboarding docs instead of forcing this flow.
+
+Open [`references/REFERENCE.md`](./references/REFERENCE.md) when you need the
+command matrix, baseline config shape, checklist, or access-path comparison.
+
+## When To Use
+
+Use this skill when the user mentions any of the following:
+
+- OpenClaw on a cloud server, VM, or other Linux host
+- Secure self-hosting, hardening, or "run it privately"
+- Podman, loopback binding, SSH tunneling, or remote Control UI access
+- Tailscale vs reverse proxy for OpenClaw
+- Pairing, sandboxing, token auth, or locked-down tool permissions
+- Reviewing whether an existing OpenClaw host is too exposed
+
+Do not use this skill for:
+
+- General Linux hardening with no OpenClaw component
+- Local single-machine onboarding where remote access is irrelevant
+- Pure local onboarding with no remote-host hardening questions
+- Non-Linux hosting unless the user explicitly wants this Linux-first pattern
+  adapted
+
+## Workflow
+
+### 1. Classify the request
+
+Put the task in one of these buckets before giving detailed guidance:
+
+1. **Fresh deploy**: the user wants to stand up OpenClaw securely on a Linux
+   cloud host from scratch.
+2. **Hardening review**: the user already has OpenClaw running and wants to
+   reduce exposure or audit risky defaults.
+3. **Access-model decision**: the user is choosing between SSH tunneling,
+   Tailscale, or a reverse proxy.
+
+### 2. Start from the secure baseline
+
+Unless the user clearly asks for something else, recommend this baseline:
+
+- Harden the Linux host first: updates, SSH keys, SSH lock-down, and a
+  default-deny inbound firewall matched to the distro.
+- Run OpenClaw under rootless Podman rather than as a root-owned long-lived
+  process.
+- Keep the gateway on loopback only.
+- Keep the Control UI private and access it through an SSH tunnel.
+- Require token authentication.
+- Keep pairing enabled for inbound messaging channels.
+- Start with a minimal tool set and sandbox sessions by default.
+
+Treat these as explicit red flags:
+
+- Binding the gateway to `0.0.0.0`
+- Opening port `18789` to the public internet
+- Turning on broad runtime, filesystem, automation, or browser access by
+  default
+- Leaving `~/.openclaw` readable by other local users
+
+### 3. Separate local and server actions
+
+Always distinguish between:
+
+- **Local machine actions**: SSH key generation, tunnel setup, browser access
+- **Server actions**: Linux hardening, Podman install path, OpenClaw service
+  setup, config permissions, service restarts
+
+Do not blur the two execution contexts together. The user should be able to
+tell which commands run on their laptop and which run on the Linux host.
+
+### 4. Ask only for blocking facts
+
+Only stop for missing facts that change the safe path, such as:
+
+- Linux distro and host access details when package-manager or firewall
+  commands matter
+- Whether OpenClaw is already installed
+- Whether the user truly needs repeated remote private access or public access
+- Whether an existing deployment is already reachable from the internet
+
+If a detail is not safety-critical, make the reasonable secure assumption and
+state it.
+
+### 5. Use the access escalation ladder
+
+Recommend remote access in this order:
+
+1. **SSH tunnel**: default for first deployment and personal use
+2. **Tailscale**: next step when the user needs repeated private access across
+   trusted devices
+3. **Reverse proxy**: only when the user explicitly needs public exposure and
+   accepts the extra hardening burden
+
+If the user asks for Tailscale or reverse proxy, still explain why the loopback
+binding and private-first model remain the baseline.
+
+## Output Expectations
+
+For a fresh deployment, provide:
+
+- A short architecture summary
+- Local-vs-server steps
+- A conservative config baseline
+- A pre-launch checklist
+- A short "what not to expose" warning
+
+For a hardening review, provide:
+
+- The likely risks in the current setup
+- A prioritized remediation sequence
+- Any immediate exposure concerns to fix before anything else
+
+For an access-path decision, provide:
+
+- A recommendation
+- Why it is the lowest-risk fit
+- What extra safeguards are required if the user chooses a broader exposure
+  model
+
+## Common Mistakes
+
+- Treating OpenClaw like a normal public web app on day one
+- Assuming auth alone replaces network boundaries
+- Turning on more tool power before the user has a clear workflow that needs it
+- Disabling pairing just to save time during early setup
+- Skipping follow-up audits after changing config or sandbox settings
+
+## Reference Usage
+
+Use [`references/REFERENCE.md`](./references/REFERENCE.md) when you need:
+
+- The cross-distro hardening flow and Debian/Ubuntu example commands
+- The Podman-based OpenClaw setup outline
+- The baseline config skeleton
+- The pre-launch checklist
+- The day-to-day audit commands
+- The SSH tunnel vs Tailscale vs reverse-proxy comparison

package/skills/opensource-guide-coach/SKILL.md

@@ -0,0 +1,218 @@
+---
+name: opensource-guide-coach
+description: Use when a user wants guidance on starting, contributing to, growing, governing, funding, securing, or sustaining an open source project, or asks about contributor onboarding, community health, maintainer burnout, code of conduct, metrics, legal basics, or open source project adoption.
+---
+
+## Overview
+
+Use the official Open Source Guides as a coaching framework for open source questions.
+
+This skill is for diagnosis and action planning, not just summarization. Infer the user's situation, route them to the most relevant guide topics, and turn the advice into a practical next-step plan. Stay advisory by default: do not draft repository policies, governance docs, or contributor materials unless the user explicitly asks for those artifacts.
+
+## Source Of Truth
+
+- Use the official Open Source Guides site: <https://opensource.guide/>
+- Use [`references/guide-map.md`](./references/guide-map.md) to select the right topic quickly
+- Use [`references/persona-router.md`](./references/persona-router.md) to infer the closest audience persona
+- Use [`references/attribution.md`](./references/attribution.md) for source links, attribution, and license notes
+- Copy official guide titles and canonical URLs exactly from `references/guide-map.md`
+
+Treat the guides as curated community practice, not binding policy. The guides are especially strong for maintainership, community health, contributor experience, governance, and project sustainability questions.
+
+## When To Use
+
+Use this skill when the user is trying to:
+
+- decide whether or how to open source a project
+- attract users or contributors
+- improve onboarding or contribution flow
+- reduce maintainer overload or burnout
+- set governance or decision-making expectations
+- adopt or enforce a code of conduct
+- choose useful project metrics
+- think about funding or sustainability
+- understand open source legal basics
+- tighten project security practices
+
+Do not use this skill for:
+
+- GitHub product how-to questions that need product docs
+- repository-specific legal advice that requires a lawyer
+- deep software security implementation guidance unrelated to open source project operations
+
+## Working Style
+
+### 1. Identify the situation
+
+Infer:
+
+- the closest persona
+- the project stage: considering launch, early launch, growing, overwhelmed, or formalizing
+- the main pain point
+- whether the user wants advice, a checklist, or actual drafted artifacts
+
+If details are missing, make a reasonable inference and state it briefly. Do not interrogate the user for every unknown if a safe assumption will do.
+
+### 2. Choose the smallest useful guide set
+
+Pick `1-3` guide topics.
+
+- Use `1` guide for narrow questions
+- Use `2` guides for common combined situations
+- Use `3` guides only when the request clearly spans multiple concerns
+
+Do not dump the entire guide catalog on the user.
+
+### 3. Convert guidance into action
+
+Translate the guide themes into a prioritized plan that fits the user's scale.
+
+- Prefer the next `3-6` concrete actions
+- Match the level of process to the maturity of the project
+- Avoid recommending heavyweight governance or documentation too early
+- Keep the plan practical for solo maintainers and volunteer projects
+
+### 4. Link back to the official source
+
+For each recommended guide, include the official `opensource.guide` URL and one short sentence on why it applies.
+
+- Use the canonical URL from `references/guide-map.md`
+- Do not shorten, guess, or rewrite article slugs
+- Use the official article title exactly as written in `references/guide-map.md`
+
+### 5. Stay advisory by default
+
+Unless the user explicitly asks for drafting help:
+
+- do not write a full `CONTRIBUTING.md`
+- do not write a governance charter
+- do not write a code of conduct
+- do not generate a full legal policy
+
+If the user does ask for an artifact, say which guide(s) you are basing it on and then draft only the requested artifact.
+
+## Routing Heuristics
+
+Reach for these patterns first:
+
+- Launch decision, project scope, expectations, readiness: `starting-a-project`
+- How newcomers can help, contribution flow, first PR path: `how-to-contribute`
+- Adoption, awareness, project discovery: `finding-users`
+- Welcoming environment, community participation, contributor experience: `building-community`
+- Maintainer workload, process clarity, saying no, automation: `best-practices`
+- Shared decision-making, leadership models, formal rules: `leadership-and-governance`
+- Sustainability, sponsorship, funding models: `getting-paid`
+- Behavior expectations and enforcement norms: `code-of-conduct`
+- Measuring health and progress: `metrics`
+- Licensing and legal basics: `legal`
+- Burnout, boundaries, maintainership balance: `maintaining-balance-for-open-source-maintainers`
+- Security hygiene, project trust, dependency and vulnerability practices: `security-best-practices-for-your-project`
+
+Common pairings:
+
+- First launch + adoption: `starting-a-project` + `finding-users`
+- Contributor growth + community experience: `how-to-contribute` + `building-community`
+- Maintainer overload + burnout: `best-practices` + `maintaining-balance-for-open-source-maintainers`
+- Governance + conduct expectations: `leadership-and-governance` + `code-of-conduct`
+- Trust + sustainability for mature projects: `security-best-practices-for-your-project` + `best-practices` or `getting-paid`
+
+Canonical title reminders:
+
+- `starting-a-project` -> `Starting an Open Source Project`
+- `code-of-conduct` -> `Your Code of Conduct`
+- `security-best-practices-for-your-project` -> `Security Best Practices for your Project`
+
+## Response Contract
+
+Always use this structure:
+
+Respond in plain Markdown only.
+
+- Do not emit pseudo-tool calls
+- Do not emit XML-like tags
+- Do not emit internal reasoning markers
+- Do not rename the section headings below
+- If you begin responding, complete all five sections
+- Never return empty wrappers, placeholders, or partial scaffolding
+
+## Situation
+
+State the inferred persona, project stage, and main challenge in plain language. If you made an assumption, note it in one sentence.
+
+## Relevant Guides
+
+List `1-3` guides. For each one include:
+
+- official title copied exactly from `references/guide-map.md`, including capitalization
+- why it applies here
+- official URL
+
+Preferred format:
+
+`**Official Title**`
+
+`Why it applies: ...`
+
+`URL: <https://opensource.guide/...>`
+
+## Recommended Next Steps
+
+Provide a prioritized numbered list. Keep it concrete and proportionate to the user's scale.
+
+## Watch-outs
+
+Call out risks, anti-patterns, or ways the user could over-process the problem.
+
+## Optional deeper reading
+
+Include any extra guide links only if they are genuinely useful. If not, say that the guides above are enough for now.
+
+Mini example:
+
+## Situation
+
+You are an early-stage solo maintainer deciding whether your side project is ready for open source.
+
+## Relevant Guides
+
+**Starting an Open Source Project**
+
+Why it applies: It helps you decide whether to launch now and what basics to prepare first.
+
+URL: <https://opensource.guide/starting-a-project/>
+
+## Recommended Next Steps
+
+1. Clarify the project scope and your maintenance boundaries.
+2. Add a license, README, and minimal contributor expectations.
+3. Share with a small early audience before a broader announcement.
+
+## Watch-outs
+
+Do not over-promise support or add heavyweight process before you need it.
+
+## Optional deeper reading
+
+If you want to think about early contributor experience, read How to Contribute to Open Source next.
+
+## Quality Bar
+
+Your answer should:
+
+- sound like coaching, not policy boilerplate
+- reflect the likely persona and maturity level
+- use official guide links, not third-party summaries
+- avoid presenting legal content as legal advice
+- avoid copying long passages from the source material
+- leave the user with a clear next move
+
+## Escalation Rules
+
+Escalate carefully when:
+
+- the user is asking for legal certainty rather than general guidance
+- the user needs incident response or code-level security help
+- the user wants formal governance that may be disproportionate for a tiny project
+- the user is clearly burned out and needs boundaries more than process
+
+In those cases, keep the recommendation practical and say what this skill can and cannot confidently cover.

package/skills/output-skill/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: full-output-enforcement
+description: Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
+---
+
+# Full-Output Enforcement
+
+## Baseline
+
+Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity — optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions.
+
+## Banned Output Patterns
+
+The following patterns are hard failures. Never produce them:
+
+**In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...` standing in for omitted code
+
+**In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"
+
+**Structural shortcuts:** Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.
+
+## Execution Process
+
+1. **Scope** — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
+2. **Build** — Generate every deliverable completely. No partial drafts, no "you can extend this later."
+3. **Cross-check** — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.
+
+## Handling Long Outputs
+
+When a response approaches the token limit:
+
+- Do not compress remaining sections to squeeze them in.
+- Do not skip ahead to a conclusion.
+- Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
+- End with:
+
+```
+[PAUSED — X of Y complete. Send "continue" to resume from: next section name]
+```
+
+On "continue", pick up exactly where you stopped. No recap, no repetition.
+
+## Quick Check
+
+Before finalizing any response, verify:
+- No banned patterns from the list above appear anywhere in the output
+- Every item the user requested is present and finished
+- Code blocks contain actual runnable code, not descriptions of what code would do
+- Nothing was shortened to save space

package/skills/package-publishing/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: package-publishing
+description: Publish packages to npm, PyPI, or Maven with automated builds and provenance
+category: Software Development
+---
+
+# Package Publishing
+
+## Overview
+Publish packages to npm, PyPI, or Maven with automated builds and provenance. This skill helps you apply structured, repeatable methods for consistent results.
+
+## When to Use
+- When you need to apply package publishing best practices
+- When establishing processes or standards for your workflow
+- When training team members on package publishing
+- When automating or optimizing package publishing tasks
+
+## Instructions
+1. **Assess**: Evaluate the current state, requirements, and constraints
+2. **Plan**: Define the approach, steps, and success criteria
+3. **Execute**: Follow the established patterns and best practices
+4. **Verify**: Check results against expected outcomes and quality standards
+5. **Iterate**: Refine based on feedback and lessons learned
+
+## Examples
+```
+User: Help me apply package publishing for my current project
+Assistant: I'll help you apply package publishing step by step...
+```
+
+## Related Skills
+- Use with `workflow` tool for orchestrated execution
+- Combine with `task` tool for delegated processing
+- Reference `system-prompt` for system-level integration

package/skills/password-generator/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: password-generator
+description: Generate strong passwords with configurable length, symbols, and entropy
+category: Productivity
+---
+
+# Password Generator
+
+## Overview
+Generate strong passwords with configurable length, symbols, and entropy. This skill helps you apply structured, repeatable methods for consistent results.
+
+## When to Use
+- When you need to apply password generator best practices
+- When establishing processes or standards for your workflow
+- When training team members on password generator
+- When automating or optimizing password generator tasks
+
+## Instructions
+1. **Assess**: Evaluate the current state, requirements, and constraints
+2. **Plan**: Define the approach, steps, and success criteria
+3. **Execute**: Follow the established patterns and best practices
+4. **Verify**: Check results against expected outcomes and quality standards
+5. **Iterate**: Refine based on feedback and lessons learned
+
+## Examples
+```
+User: Help me apply password generator for my current project
+Assistant: I'll help you apply password generator step by step...
+```
+
+## Related Skills
+- Use with `workflow` tool for orchestrated execution
+- Combine with `task` tool for delegated processing
+- Reference `system-prompt` for system-level integration