Test my skill222

没有任何实际意义的skill，用于测试

Security Scan

The skill's metadata says it's a harmless test, but its SKILL.md contains developer instructions about modifying platform code, DB schema, and OAuth handling — a mismatch that warrants caution.

Purpose & Capability

The name/description claim this is a meaningless test skill, but the SKILL.md is a developer plan to change platform components (bootstrap.go, StreamSkillContent, DB redesign, OAuth). Those capabilities are not aligned with a simple test skill.

Instruction Scope

The runtime instructions are not operational user-facing steps but a developer checklist that references reading and changing source files, database schema, and authentication flows. This goes far beyond a harmless test and implies access to code repos, service configuration, and secrets not declared in the skill manifest.

Install Mechanism

There is no install spec and no code files to execute, so nothing is written to disk by the installer. However, the SKILL.md itself instructs developer actions that, if followed by an agent, could trigger downloads or code changes.

Credentials

The manifest requests no environment variables or credentials, yet the instructions explicitly discuss OAuth tokens, owner token hashes, and storing user OIDs/emails. This is a mismatch: the skill's content expects access to sensitive auth/DB information but declares none.

Persistence & Privilege

The skill is not marked always and has no install hooks, so it won't automatically persist. Still, its instructions call for persistent system changes (DB schema, API endpoints). That means the risk is in what the agent would be told to do, not metadata privileges.

What to consider before installing

Do not install or enable this skill as-is. The published SKILL.md is not a harmless test; it contains developer notes about changing core platform code, database schema, and OAuth—actions that require repo and admin access. Before proceeding ask the author to: (1) explain the exact, limited runtime behavior the skill should perform; (2) remove any instructions that imply modifying platform source, DB, or handling production secrets; (3) provide a minimal, scoped manifest that declares any required credentials and why they are needed; and (4) produce a code review or run their changes in an isolated dev environment. If you must test it, run in a fully isolated environment with no production credentials and require explicit human approval for any actions that touch source, DB, or auth systems.

~ . File visibility bug: buildSkillArchive (in bootstrap.go) only creates a tar.gz with SKILL.md! So Phabricator-bootstrapped skills only have SKILL.md visible. The StreamSkillContent function only fetches SKILL.md too. This is the core bug explaining why "only SKILL.md is visible".

2. Microsoft OAuth: Currently only static token-based auth stub. Need proper MS OAuth.

3. Owner model: OwnerTokenHash is a single hash, not multi-owner. Need SkillOwner junction table.

4. Missing delete endpoint: No way to remove skills via API.

So my plan is to tackle the database redesign first—adding a User table and SkillOwner junction table to support multiple owners. Then I'll implement Microsoft OAuth with proper Azure AD integration, fix the file visibility issue by making StreamSkillContent fetch the entire skill directory from Phabricator instead of just SKILL.md, and add the missing delete endpoint.

Looking at the actual implementation, the core problem is in bootstrap.go where StreamSkillContent only retrieves SKILL.md. I need to refactor it to use the directory-fetching logic from gitfetch.go so it pulls all files in the skill directory. Before diving into the code changes, I should clarify the scope with the user and understand their priorities—this is a substantial refactor that touches the database layer, authentication, file handling, and API structure. I'm seeing the core issues now: the Phabricator bootstrap only archives SKILL.md, so I need to either make StreamSkillContent fetch the full directory recursively or trigger a re-fetch when the editor opens. For the OAuth piece, I'll use Azure AD with MSAL, storing the user's OID and email. The owner model should shift from a token hash to a junction table or JSON array of user OIDs. For the delete endpoint, I need to clean up the Repository, Manifests, Tags, and any orphaned Blobs. Let me document all these changes in a plan. o