Secondme Dev Assistant

Use when user wants to develop on the SecondMe platform (second.me, develop.second.me). Triggers: building SecondMe third-party apps (第三方应用/外部应用), SecondMe O...

Security Scan

The skill largely matches a SecondMe developer assistant, but its runtime instructions perform file I/O, secret storage, repo scanning, and an automatic npx-based update check that aren’t declared in the metadata and expand its runtime footprint; these inconsistencies merit caution before installing or enabling it.

Purpose & Capability

The declared purpose (developer assistant for SecondMe) aligns with most instructions: creating apps, managing credentials, MCP/integration guidance, scanning repos, and calling SecondMe APIs. However, the skill's metadata declares no required binaries or install steps while the instructions expect and use tools (npx, python3, openssl, shell utilities) and network access — that mismatch is unexplained in the registry metadata and is surprising.

Instruction Scope

Runtime instructions include: reading and writing files under ~/.secondme (client_secret, dev_credentials, analytics), scanning repository files (including env or auth files), creating references/api-reference.md by fetching remote docs, and an early pre-flight update check that runs npx. They also instruct automatically creating apps via platform APIs and saving returned client secrets to disk. These behaviors go beyond pure conversational help and involve local file I/O, secret persistence, and optional network fetches; the skill claims some safeguards (e.g., 'never print raw secret') but also indicates it will save secrets without the user manually doing so. The skill will prompt for telemetry and may write telemetry state and a stable device id locally.

Install Mechanism

The skill has no declared install spec, but the pre-flight check runs 'npx skills check' and may run 'npx skills update mindverse/second-me-skills -y' which can download and execute code from the network at runtime. That effectively implements an implicit install/update mechanism outside the registry install metadata. Running npx to fetch/update packages is higher-risk than an instruction-only skill and should be explicitly declared; the code also assumes availability of npx and will call it without listing it as a required binary.

Credentials

The skill declares no required environment variables, which is reasonable for a generic dev assistant, but its instructions read/write local credential files (~/.secondme/client_secret and ~/.secondme/dev_credentials), scan repo files (including env and auth files), and recommend persisting OAuth client secrets and tokens. Reading repository env or auth files can expose unrelated secrets. The telemetry flow writes analytics locally and can create a stable device id; while telemetry is local-first per the docs, the presence of any telemetry and the stable device id should be considered sensitive. The skill accesses/creates secrets but the registry did not list these persistence/config paths in 'required config paths', creating an incoherence.

Persistence & Privilege

The skill does not request 'always: true' and cannot force-enable itself globally, which is good. However, it does request persistent local state by creating ~/.secondme files (config, client_secret, dev_credentials, analytics, .device-id) and may create/modify repository files (references/api-reference.md). Persisting client secrets and tokens to disk is within the expected behavior of a developer assistant, but users should understand the exact files written and their permissions are recommended only (the skill suggests chmod-like permissions but will write the files regardless).

What to consider before installing

Things to consider before installing or enabling this skill: - It will read and write files under your home directory (~/.secondme) including storing OAuth client secrets and developer tokens; if you do not want secrets written to disk, do not allow the assistant to create or persist them. - On first use (once per conversation) it runs a pre-flight shell snippet that uses npx to check for and optionally update a 'second-me-skills' package. That can download and run code from the network even though the skill has no install spec — only enable this if you trust that update behavior. - The skill assumes availability of npx, python3, openssl and other shell tools but the registry metadata does not list these as required binaries; ensure your environment meets these prerequisites or the script may fail. - The assistant may scan repository files (README, package.json, env files, auth files) to infer integration details — be cautious if those files contain secrets for other services. - Telemetry is configurable: the skill will prompt and can store a stable device id for 'community' mode; read the prompt carefully and choose 'off' or 'anonymous' if you prefer not to create persistent identifiers. - If you proceed, consider: (1) backing up or auditing ~/.secondme before use, (2) choosing manual app creation if you want to avoid automatic secret storage, and (3) restricting network access or reviewing any downloaded updates from npx before execution. If you want, I can list the exact files and network endpoints the skill will access and give step-by-step mitigations (e.g., how to run the flows manually) before you enable it.

Pre-flight Check

On first activation per conversation, silently run this check before proceeding with the user's request:

# --- Update Check ---
CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}/secondme-skills"
STAMP="$CACHE_DIR/last-check"
mkdir -p "$CACHE_DIR"
LAST=$(cat "$STAMP" 2>/dev/null || echo 0)
NOW=$(date +%s)
if [ $((NOW - LAST)) -ge 86400 ]; then
  if npx skills check 2>&1 | grep -qiE "second-me-skills|second\.me"; then
    npx skills update mindverse/second-me-skills -y 2>&1 || true
  fi
  echo "$NOW" > "$STAMP"
fi

# --- Feedback/Telemetry Preamble ---
SM_DIR="$HOME/.secondme"
SM_CONFIG="$SM_DIR/config"
SM_ANALYTICS="$SM_DIR/analytics"
SM_VERSION="2.1.0"
SM_OS=$(uname -s 2>/dev/null || echo "unknown")
SM_ARCH=$(uname -m 2>/dev/null || echo "unknown")
SM_TEL_START=$NOW
SM_SESSION_ID="$$-$NOW"

SM_TEL="off"
if [ -f "$SM_CONFIG" ]; then
  SM_TEL=$(python3 -c "
import json
try: d=json.load(open('$SM_CONFIG')); print(d.get('telemetry','off'))
except: print('off')
" 2>/dev/null || echo "off")
fi

SM_TEL_PROMPTED="no"
[ -f "$SM_DIR/.feedback-prompted" ] && SM_TEL_PROMPTED="yes"

echo "TELEMETRY: $SM_TEL"
echo "TEL_PROMPTED: $SM_TEL_PROMPTED"

# Log usage event (if telemetry not off)
if [ "$SM_TEL" != "off" ]; then
  mkdir -p "$SM_ANALYTICS"
  SM_DEVICE_ID=""
  [ "$SM_TEL" = "community" ] && [ -f "$SM_DIR/.device-id" ] && SM_DEVICE_ID=$(cat "$SM_DIR/.device-id" 2>/dev/null)
  python3 -c "
import json
e={'skill':'secondme-dev-assistant','ts':'$(date -u +%Y-%m-%dT%H:%M:%SZ)','session':'$SM_SESSION_ID','version':'$SM_VERSION','os':'$SM_OS','arch':'$SM_ARCH'}
d='$SM_DEVICE_ID'
if d: e['device_id']=d
print(json.dumps(e))
" >> "$SM_ANALYTICS/usage.jsonl" 2>/dev/null || true
fi

Rules:

• Run at most once per conversation, and only if the last check was more than 24 hours ago
• If the update finds changes, briefly inform the user that the skill was updated
• If nothing changed or the check is throttled, proceed silently — do not mention the check to the user
• Never let the update check block or delay the user's actual request

---

Feedback Preference

If TEL_PROMPTED is no, read and follow the feedback prompt flow before continuing:

Read references/feedback-prompt.md

If TEL_PROMPTED is yes, skip this section entirely and proceed with the user's request.

---

This is the single entry skill for SecondMe developer work.

Use it for the full lifecycle:

• creating a SecondMe app on develop.second.me
• obtaining and storing Client ID and Client Secret
• defining product requirements and scaffold plans
• guiding implementation of SecondMe OAuth, user auth, and MCP behavior
• creating, editing, validating, releasing, and resubmitting integrations
• creating, editing, listing, and submitting external apps for review
• querying existing app or integration state later and fixing issues

Do not treat this skill as only an MCP manifest helper. If the user mentions any of the following, this skill should usually trigger:

• "做一个 SecondMe 应用"
• "接入 SecondMe 登录"
• "做 OAuth"
• "做 MCP / integration"
• "生成项目脚手架"
• "提交应用审核"
• "提交 integration 审核"
• "查询 / 修改 / 重新提交 app 或 integration"
• "黑客松"
• "hackathon"
• "A2A 应用"
• "开发应用"
• "开发项目"

Early trigger rule:

• if the user mentions hackathon, hackathon, A2A app, app development, or project development, trigger this skill early
• then confirm whether they are building a SecondMe third-party app or integration
• if yes, continue with this skill's lifecycle guidance
• if not, exit this skill and continue with the more relevant workflow

Scope

This skill is a developer assistant, not a blind code generator.

It should:

• gather missing app and platform information
• help the user complete the correct platform steps
• produce implementation requirements, checklists, and project briefs
• inspect local code when needed
• manage SecondMe Develop control-plane records directly

It should not:

• invent credentials, endpoints, or secrets
• claim review submission is safe without checking platform state
• generate a full project blindly before requirements are clear
• release an integration without explicit user confirmation

For actual app implementation, default to giving the user or their coding agent a precise implementation brief and required standards. Only write project code if the user explicitly asks for code work in the current coding workspace.

Trigger Map

Treat these as the same family of tasks:

• app_bootstrap: create app, get App Info, get scopes, get credentials
• requirements: define product goal, modules, architecture, and scaffold plan
• implementation_guidance: OAuth, token storage, Next.js structure, MCP auth, API usage, testing requirements
• open_apis: Agent Memory ingest/list, Act structured action stream
• control_plane_app: external app list/get/create/update/regenerate-secret/delete/apply-listing
• control_plane_integration: integration list/get/create/update/delete/validate/release
• maintenance: query state, change settings, diagnose validation or review failures, resubmit after fixes

If the request is ambiguous, pick the earliest blocking phase and move forward from there.

Operating Modes

1. Full Build Lifecycle

Use when the user is starting or expanding a SecondMe app.

Flow:

1. bootstrap the app through SecondMe Develop APIs by default
2. collect and normalize credentials and scopes
3. clarify requirements
4. produce scaffold and implementation guidance
5. help configure app metadata and integration metadata
6. validate and submit
7. support later maintenance and resubmission

2. Control-Plane Only

Use when the user already has an app or integration and wants to inspect or change platform records directly.

Do not force requirement discovery or scaffold planning in this mode.

3. Repository-Aware Guidance

Use when the user already has a local repo and wants help aligning it with SecondMe requirements.

Inspect only the files needed to answer the question or infer the missing platform payload.

Phase 1 & 2: App Bootstrap and Client Secret

Create SecondMe app, obtain credentials (Client ID, Client Secret), handle secret storage and lifecycle.

Read references/app-bootstrap.md for the complete flow.

Phase 3: Requirements & Scaffold Plan

Clarify product requirements and produce a concrete build brief before code generation.

Read references/requirements-scaffold.md for the complete flow.

Phase 4: Implementation Guidance

OAuth2 rules, token exchange, environment variables, API response handling, endpoint discovery, and recommended project shape.

Read references/implementation-guidance.md for the complete flow.

Open APIs Reference

Agent Memory ingest/list and structured Act stream — open APIs that third-party apps can use directly to report events and get structured AI judgments.

Read references/open-apis.md for the complete flow.

Phase 5: MCP & Integration

MCP suitability guidance, platform model, runtime auth rules, repository scan, and recommended tests.

Read references/mcp-integration.md for the complete flow.

Phase 6-8: Control Plane Operations

Skills Auth with SecondMe Develop, external OAuth app management (CRUD, listing, CDN upload), and integration management (CRUD, manifest, validate, release).

Read references/control-plane.md for the complete flow.

Phase 9: Release & Maintenance

Validation, release submission, failure diagnosis, and confirmation rules before any write operation.

Read references/release-maintenance.md for the complete flow.

Response Style

• compact
• transparent
• precise
• security-first

Always distinguish:

• confirmed
• inferred
• missing

Never repeat raw secret values back to the user.

Operational Rules

• always list records before assuming create is required
• always prefer the smallest necessary set of API calls
• if the user only asked to query, stop after reporting the requested data
• if the user only asked to save or update, stop after reporting saved state
• do not release automatically after save
• if this assistant created or regenerated a Client Secret, explicitly remind the user that it has already been saved to ~/.secondme/client_secret
• if the saved secret later fails, tell the user to replace it rather than pretending it still works
• when the user asks for a SecondMe app or integration from scratch, treat this skill as the unified entry point rather than routing to separate setup, PRD, scaffold, or reference skills

Session Telemetry (run last)

After the skill workflow completes, log a completion event if telemetry is not off.

Determine the outcome and error fields according to the Completion Status protocol above.

SM_DIR="$HOME/.secondme"
SM_ANALYTICS="$SM_DIR/analytics"
if [ "${SM_TEL:-off}" != "off" ]; then
  SM_TEL_END=$(date +%s)
  SM_TEL_DUR=$(( SM_TEL_END - ${SM_TEL_START:-$SM_TEL_END} ))
  SM_DEVICE_ID=""
  [ "$SM_TEL" = "community" ] && [ -f "$SM_DIR/.device-id" ] && SM_DEVICE_ID=$(cat "$SM_DIR/.device-id" 2>/dev/null)
  python3 -c "
import json
e={
  'skill':'secondme-dev-assistant',
  'ts':'$(date -u +%Y-%m-%dT%H:%M:%SZ)',
  'event':'completion',
  'session':'${SM_SESSION_ID:-unknown}',
  'version':'${SM_VERSION:-unknown}',
  'os':'${SM_OS:-unknown}',
  'arch':'${SM_ARCH:-unknown}',
  'duration_s':${SM_TEL_DUR:-0},
  'outcome':'OUTCOME',
  'error_class':ERROR_CLASS,
  'error_message':ERROR_MESSAGE
}
d='$SM_DEVICE_ID'
if d: e['device_id']=d
print(json.dumps(e,ensure_ascii=False))
" >> "$SM_ANALYTICS/usage.jsonl" 2>/dev/null || true
fi

Replace the placeholders:

• OUTCOME: success, error, or abort (use unknown if unclear)
• ERROR_CLASS: None if success, otherwise one of 'auth_failure', 'api_error', 'network', 'validation', 'permission', 'unknown'
• ERROR_MESSAGE: None if success, otherwise a string with the first 200 chars of the error (e.g., 'Token expired at ...')