New Skill: added the tunneling skill with tinyfi.sh

[simantak-dabhade]

No description provided.

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request adds a new Markdown documentation file for the Tunneling skill, documenting the TinyFish Tunneling Service (tinyfi.sh). The documentation includes usage instructions, pre-flight SSH verification steps, quick-start SSH commands, options for custom subdomains, keep-alive configuration, operational guidelines, common ports, and rate limiting constraints. The file provides step-by-step instructions and example commands to help users understand how to use the tunneling service, including tunnel lifetime behavior and per-IP rate limits.

🚥 Pre-merge checks | ✅ 1 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No description was provided by the author, making it impossible to assess whether it relates to the changeset.	Add a pull request description explaining the purpose, scope, and any relevant details about the new tunneling skill documentation.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding a new tunneling skill documentation that covers the tinyfi.sh service.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch simantak/adding-tinyfi.sh

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@skills/tunneling/SKILL.md`:
- Around line 46-54: Add a concrete "Running Tunnels in the Background"
subsection to the skill docs (adjacent to the "Usage Guidelines" section) that
gives practical examples for backgrounding SSH (e.g., shell backgrounding,
nohup, or spawning a subprocess), shows how to capture/parse the public tunnel
URL from SSH output (e.g., redirecting stdout/stderr to a file or reading
subprocess stdout and using a regex to extract the URL), and explains simple
monitoring/restart strategies (e.g., checking the PID/alive status or tailing
output and respawning on failure). Reference the phrases "run the SSH command in
the background" and "report the public URL" so readers can find the updated
guidance easily.
- Around line 22-24: The SSH example in SKILL.md currently uses the client-side
option "-o StrictHostKeyChecking=accept-new" — either remove that option and
replace the snippet with the official documented form "ssh -R
80:localhost:<PORT> tinyfi.sh" to match tinyfi.sh docs, or keep the option but
add one concise sentence immediately after the command explaining why it's
included and its security implications (that it disables strict host key prompts
and may accept unknown host keys), referencing the exact snippet and the "-o
StrictHostKeyChecking=accept-new" flag so reviewers can find and update it.

🧹 Nitpick comments (1)

skills/tunneling/SKILL.md (1)

28-36: Consider documenting subdomain conflict behavior.

The documentation shows how to request a custom subdomain but doesn't explain what happens if the subdomain is already taken or invalid. Consider adding a brief note about expected behavior or error messages.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

tinyfi.sh official documentation SSH command StrictHostKeyChecking

💡 Result:

tinyfi.sh’s official docs show connecting with a plain reverse-tunnel command and do not mention StrictHostKeyChecking:

• ssh -R 80:localhost:3000 tinyfi.sh (example from the tinyfi.sh homepage docs) [1]

If you specifically need to control host-key checking, that’s an OpenSSH client option, not something documented as required by tinyfi.sh. For example (use with care):

• ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:3000 tinyfi.sh
• ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 80:localhost:3000 tinyfi.sh

Source: tinyfi.sh homepage documentation [1]

References:
[1] tinyfi.sh (homepage) https://tinyfi.sh/

---

Align command with official tinyfi.sh documentation or add clarification.

The SKILL.md command includes -o StrictHostKeyChecking=accept-new, but the official tinyfi.sh documentation shows the simpler command without this option: ssh -R 80:localhost:3000 tinyfi.sh. The StrictHostKeyChecking parameter is a client-side SSH option, not part of tinyfi.sh's official guidance. Either use the documented command or add a note explaining why this modification is included and its security implications.

🤖 Prompt for AI Agents

In `@skills/tunneling/SKILL.md` around lines 22 - 24, The SSH example in SKILL.md
currently uses the client-side option "-o StrictHostKeyChecking=accept-new" —
either remove that option and replace the snippet with the official documented
form "ssh -R 80:localhost:<PORT> tinyfi.sh" to match tinyfi.sh docs, or keep the
option but add one concise sentence immediately after the command explaining why
it's included and its security implications (that it disables strict host key
prompts and may accept unknown host keys), referencing the exact snippet and the
"-o StrictHostKeyChecking=accept-new" flag so reviewers can find and update it.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Add practical examples for background execution.

The guidelines instruct to "run the SSH command in the background" (line 51) and "report the public URL" (line 52), but don't provide any examples of how to accomplish this. Users need concrete guidance on:

• How to background the SSH process (e.g., using &, spawning in a subprocess, etc.)
• How to capture and parse the tunnel URL from SSH output
• How to monitor if the tunnel is still alive

This is essential for implementing these guidelines correctly.

📝 Suggested enhancement with practical examples

Consider adding a section like:

## Running Tunnels in the Background

To run a tunnel without blocking:

**Option 1: Background process**
```bash
ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:3000 tinyfi.sh > tunnel_output.txt 2>&1 &
TUNNEL_PID=$!

Option 2: Using nohup for persistent tunnels

nohup ssh -o StrictHostKeyChecking=accept-new -R 80:localhost:3000 tinyfi.sh > tunnel_output.txt 2>&1 &

Parse the URL from output:

sleep 2  # Wait for connection
grep -oP 'https://[^/]+\.tinyfi\.sh' tunnel_output.txt

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

In @skills/tunneling/SKILL.md around lines 46 - 54, Add a concrete "Running
Tunnels in the Background" subsection to the skill docs (adjacent to the "Usage
Guidelines" section) that gives practical examples for backgrounding SSH (e.g.,
shell backgrounding, nohup, or spawning a subprocess), shows how to
capture/parse the public tunnel URL from SSH output (e.g., redirecting
stdout/stderr to a file or reading subprocess stdout and using a regex to
extract the URL), and explains simple monitoring/restart strategies (e.g.,
checking the PID/alive status or tailing output and respawning on failure).
Reference the phrases "run the SSH command in the background" and "report the
public URL" so readers can find the updated guidance easily.

</details>

<!-- fingerprinting:phantom:triton:puma -->

<!-- This is an auto-generated comment by CodeRabbit -->