Adds junie skills and subagents

[dacgray]

Now supported:

https://junie.jetbrains.com/docs/agent-skills.html
https://junie.jetbrains.com/docs/junie-cli-subagents.html

[github-actions]

PR #1260 Review Complete

Overall Verdict: ✅ MERGEABLE

Both code quality and security reviews found only low-severity or informational issues - no blockers for merging.

---

Code Review Findings

1. Code Quality: Excellent - Implementation follows all project conventions and patterns established by existing tool implementations (Copilot)

2. Consistency: Excellent - junie-skill.ts and junie-subagent.ts correctly mirror the Copilot implementations, maintaining codebase consistency

3. Test Coverage: Comprehensive - 244 lines of tests for skills, 325 lines for subagents covering all major functionality

4. Minor Gap (Low Severity): Missing forDeletion test in junie-subagent.test.ts for complete parity with junie-skill.test.ts

5. Documentation: Good - All three documentation files consistently updated to show Junie support

---

Security Review Findings

6. Input Validation: ✅ Pass - Zod schemas properly validate all frontmatter fields

7. Path Traversal Protection: ✅ Pass - Inherits robust security controls from base classes (AiDir, AiFile)

8. Injection Vulnerabilities: ✅ Pass - No command execution, code evaluation, or unsafe parsing

9. Error Handling: ✅ Pass - Appropriate error messages with context, no sensitive data exposure

10. File Operations: ✅ Pass - Uses secure utility functions with symlink protection and dangerous path checks

11. Global Mode: ✅ Pass - Correctly throws error for unsupported global mode

---

Summary

• Code Quality Issues: 0 critical, 0 high, 0 medium, 2 low (both cosmetic/optional)
• Security Issues: 0 critical, 0 high, 0 medium, 0 low
• Merge Status: Ready to merge

The PR is well-implemented, follows established patterns, has comprehensive test coverage, and introduces no security vulnerabilities.

github run

[dyoshikawa]

Code Review

🔴 High: JunieSubagentFrontmatterSchema — name/description required/optional appears inverted from official docs

File: src/features/subagents/junie-subagent.ts

The current schema defines name as required and description as optional:

export const JunieSubagentFrontmatterSchema = z.looseObject({
  name: z.string(),
  description: z.optional(z.string()),
});

However, according to the Junie CLI subagents documentation:

• name: Not required (defaults to the filename when omitted)
• description: Required (used by the main agent to decide task delegation)

The test cases in junie-subagent.test.ts follow this inverted logic as well ("should accept valid frontmatter without description", "should reject frontmatter missing name").

How to fix:

Update the schema to match the official spec:

export const JunieSubagentFrontmatterSchema = z.looseObject({
  name: z.optional(z.string()),
  description: z.string(),
});

And update the corresponding test cases accordingly. If the current behavior is intentional (e.g., Rulesync requires name for its own internal processing), please add a comment explaining why it diverges from the official spec.

---

🟡 Medium: fromRulesyncSubagent should use filterToolSpecificSection to prevent field overwriting

File: src/features/subagents/junie-subagent.ts — fromRulesyncSubagent()

The current implementation spreads junieSection directly into rawJunieFrontmatter:

const junieSection = rulesyncFrontmatter.junie ?? {};

const rawJunieFrontmatter = {
  name: rulesyncFrontmatter.name,
  description: rulesyncFrontmatter.description,
  ...junieSection,  // If junieSection contains "name" or "description", they silently overwrite the above
};

If a user places name or description inside the junie: section of a rulesync file, those values will silently overwrite the top-level rulesync values. The existing KiroSubagent implementation avoids this by using filterToolSpecificSection:

// kiro-subagent.ts
const kiroSection = this.filterToolSpecificSection(rawSection, [
  "name",
  "description",
  "prompt",
]);

How to fix:

Use filterToolSpecificSection to strip common fields from junieSection before spreading:

const junieSection = this.filterToolSpecificSection(
  rulesyncFrontmatter.junie ?? {},
  ["name", "description"],
);

const rawJunieFrontmatter = {
  name: rulesyncFrontmatter.name,
  description: rulesyncFrontmatter.description,
  ...junieSection,
};

---

🟡 Medium: Missing .junie/skills/ and .junie/agents/ entries in gitignore.ts

File: src/cli/commands/gitignore.ts

Per feature-change-guidelines.md: "Evaluate whether gitignore.ts needs additions or changes in its generated output."

This PR adds Junie skills (.junie/skills/) and subagents (.junie/agents/) as generated output directories, but the gitignore entries were not updated. Currently only the following Junie entries exist:

// Junie
"**/.junie/guidelines.md",
"**/.junie/mcp.json",

Other tools (e.g., Kiro, Copilot) include their corresponding directories:

// Kiro
"**/.kiro/skills/",
"**/.kiro/agents/",

How to fix:

Add the new entries to gitignore.ts:

// Junie
"**/.junie/guidelines.md",
"**/.junie/mcp.json",
"**/.junie/skills/",
"**/.junie/agents/",

Then run pnpm dev gitignore to regenerate .gitignore, and update gitignore.test.ts accordingly.

[github-actions]

Thank you for your contribution! Unfortunately, this PR has 1073 added lines, which exceeds the limit of 1000 lines for external contributors.

Please split your changes into smaller PRs. See CONTRIBUTING.md for details.

This PR has been automatically closed.

[dacgray]

@dyoshikawa requested changes implemented - but pushed the PR above the 1000 line threshold. Do you really need this split into 2 prs?

[dyoshikawa]

@dacgray sorry, I'll review it later. up to 1000 is too strict, isn't it 🤔

[github-actions]

Thank you for your contribution! Unfortunately, this PR has 1073 added lines, which exceeds the limit of 1000 lines for external contributors.

Please split your changes into smaller PRs. See CONTRIBUTING.md for details.