Add support for Factory's Droid CLI#129
Add support for Factory's Droid CLI#129galangryandana wants to merge 1 commit intoobra:mainfrom galangryandana:add-factory-droid-support
Conversation
- Add .factory/ directory with Droid CLI specific implementation
- Add skills adjusted for Droid CLI (terminology, paths)
- Add droids (general-purpose, code-reviewer, explore, plan)
- Add commands (brainstorm, write-plan, execute-plan)
- Add AGENTS.md protocol for context injection
- Add install.sh for one-line installation
- Add docs/README.factory.md with complete documentation
WalkthroughIntroduces a comprehensive Superpowers protocol and skill framework for the Droid CLI (Factory). Adds the AGENTS.md directive protocol defining pre-response workflows, mandatory skill checks, and design-first processes; installation scripts and documentation; new commands for brainstorming, planning, and plan execution; droid definitions for code review, exploration, and planning; and 30+ skills spanning design, execution, debugging, testing, code review, and development workflows. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes
Possibly related issues
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (36)
.factory/skills/writing-skills/anthropic-best-practices.md (1)
257-257: Add language specifiers to code blocks for clarity.Three code blocks lack language specifiers, which reduces syntax highlighting and clarity for readers:
- Line 257: Directory structure (use
textorbash)- Line 301: Directory structure (use
textorbash)- Line 1040: Directory structure (use
textorbash)Apply this fix to improve readability:
-``` +```text ├── SKILL.md # Main instructions (loaded when triggered)Also applies to: 301-301, 1040-1040
.factory/skills/condition-based-waiting/example.ts (1)
20-44: Polling logic and timeout handling look solid; consider DRY-ing the shared patternThe three helpers correctly:
- Poll
threadManager.getEvents(threadId)on a bounded 10ms interval.- Enforce a hard timeout using
Date.now() - startTime > timeoutMs.- Resolve only on a successful match and stop scheduling new timeouts, so there’s no runaway timer loop.
Given the near-identical
check+ timeout pattern acrosswaitForEvent,waitForEventCount, andwaitForEventMatch, you could optionally factor this into a small internalwaitForhelper (taking a predicate and error message builder) to reduce duplication and keep future changes to the polling behavior in one place. This is fully optional; the current implementation is already clear and correct.Also applies to: 60-89, 111-136
.factory/skills/testing-anti-patterns/SKILL.md (3)
33-33: Add language specifiers to fenced code blocks.The code blocks at lines 33 and 90 should specify language tags for syntax highlighting and clarity. Line 33 appears to be TypeScript/JavaScript test code, and line 90 is a shell/bash block.
Apply this diff:
-``` +```typescript // ❌ BAD: Testing that the mock exists test('renders sidebar', () => { render(<Page />); expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument(); }); -``` +```And:
-``` +```bash // ✅ GOOD: Test utilities handle test cleanup -``` +```As per the Markdown linting standards (MD040), all fenced code blocks should specify a language identifier.
Also applies to: 90-90
208-208: Use proper headings instead of emphasis for section labels.Lines 208, 218, 228, 236, 246, 294, and 302 use bold emphasis (e.g.,
**Critical:**,**your human partner's question:**,**Actions:**,**If uncertain:**) where proper Markdown headings would be more appropriate and consistent.Example fixes:
-**Critical:** +### Critical-**your human partner's question:** "Do we need to be using a mock here?" +### Your Human Partner's Question: "Do we need to be using a mock here?"-**When Mocks Become Too Complex** +## When Mocks Become Too ComplexThis aligns with Markdown best practices (MD036) and improves document structure for navigation and parsing.
Also applies to: 218-218, 228-228, 236-236, 246-246, 294-294, 302-302
1-302: Excellent comprehensive anti-patterns guide with strong practical examples.The skill document is well-structured and educational. The Iron Laws are clear, each anti-pattern is explained with concrete violations and fixes, and the gate functions provide actionable decision trees. The quick reference table and red flags section are particularly useful for practitioners. The integration of "your human partner" feedback mechanisms aligns well with the collaborative debugging philosophy described in systematic-debugging and other skills.
.factory/skills/systematic-debugging/SKILL.md (2)
18-18: Add language specifiers to fenced code blocks.Lines 18 and 77 contain fenced code blocks without language identifiers. Both appear to be shell/bash commands and should include language tags.
Apply these diffs:
-``` +```bash NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST -``` +```-``` +```bash For EACH component boundary: - Log what data enters component - Log what data exits component - Verify environment/config propagation - Check state at each layer Run once to gather evidence showing WHERE it breaks THEN analyze evidence to identify failing component THEN investigate that specific component -``` +```This follows Markdown linting standards (MD040).
Also applies to: 77-77
1-295: Exceptional four-phase debugging framework with clear decision gates.This skill provides a rigorous, scientific approach to debugging with strong emphasis on root cause analysis before attempting fixes. The Iron Law is well-articulated, and the red flags section effectively calls out common anti-patterns in debugging behavior. The phase descriptions are detailed and actionable. Integration points with other skills (root-cause-tracing, test-driven-development, defense-in-depth) provide a cohesive skill ecosystem. The real-world impact data is compelling.
.factory/skills/dispatching-parallel-agents/SKILL.md (2)
143-143: Add language specifier to code block.Line 143 contains a fenced code block showing Task definitions that should specify a language identifier for clarity.
Apply this diff:
-``` +```typescript // In Claude Code / AI environment Task("Fix agent-tool-abort.test.ts failures") Task("Fix batch-completion-behavior.test.ts failures") Task("Fix tool-approval-race-conditions.test.ts failures") // All three run concurrently -``` +```This follows Markdown linting standards (MD040) and hints that this is TypeScript/JavaScript-like syntax.
1-180: Excellent pattern documentation with clear decision logic and practical real-world example.The skill provides a clear, evidence-based pattern for parallelizing independent debugging tasks. The decision diagram effectively illustrates when to use parallel dispatch, and the four-step pattern is practical. The "Common Mistakes" section (too broad scope, missing context, no constraints, vague output) provides valuable guidance that would help contributors apply the pattern correctly. The real-world example (3 agents fixing different failures in parallel) is compelling and demonstrates clear value. The verification section ensures integration risks are minimized.
.factory/skills/receiving-code-review/SKILL.md (1)
86-98: Clarify intent and authority of "your human partner's rule" references.Lines 86 and 98 reference "your human partner's rule" with paraphrased guidance. This pattern appears multiple times (lines 86, 98, 121) but lacks explicit definition. Clarify whether these are optional guidelines or mandatory behaviors for the workflow.
Consider adding a section early in the document (after line 12) clarifying the role and authority of "your human partner" directives, so readers understand when to follow them vs. when they are suggestions.
.factory/skills/requesting-code-review/code-reviewer.md (1)
112-112: Add language specifier to fenced code block.Line 112 starts a code block in the example output but lacks a language identifier. This affects syntax highlighting and Markdown compliance.
Apply this diff:
-``` +```markdown ### Strengths.factory/skills/requesting-code-review/SKILL.md (1)
51-51: Add language specifier to fenced code block.Line 51 starts a code block but lacks a language identifier. The context suggests bash commands, which should be specified for syntax highlighting.
Apply this diff:
-``` +```bash [Just completed Task 2: Add verification function].factory/skills/using-git-worktrees/SKILL.md (2)
42-42: Add language specifiers to fenced code blocks (lines 42, 138, 176).Multiple code blocks lack language identifiers. Lines 42 and 176 contain bash commands; line 138 contains plain text output. These should be specified for proper Markdown compliance and syntax highlighting.
Apply these diffs:
### 1. Check Existing Directories -```bash +```bash # Check in priority orderAt line 138 (Plain text output showing usage):
If no directory exists and no CLAUDE.md preference: -``` +```text No worktree directory found. Where should I create worktrees?At line 176 (Bash commands):
## Example Workflow -``` +```bash You: I'm using the using-git-worktrees skill to set up an isolated workspace.Also applies to: 138-138, 176-176
158-173: Convert emphasis-formatted section headers to proper Markdown headings (lines 158-170).Lines 158, 162, 166, and 170 use bold emphasis (text) to format section headers rather than proper Markdown headings (###). This violates Markdown best practices (MD036). These should be converted to h4 headings for proper document structure.
Apply this diff:
## Common Mistakes -**Skipping .gitignore verification** +### Skipping .gitignore verificationApply similar changes to lines 162, 166, and 170:
-**Assuming directory location** +### Assuming directory location -**Proceeding with failing tests** +### Proceeding with failing tests -**Hardcoding setup commands** +### Hardcoding setup commands.factory/skills/writing-plans/SKILL.md (2)
65-82: Convert emphasized step headers to proper Markdown headings (lines 65, 70, 77, 82).Lines 65, 70, 77, and 82 use bold emphasis (Step N: ...) instead of proper Markdown headings. This violates Markdown best practices (MD036) and makes document structure less clear for parsers and readers.
Apply this diff to convert emphasis to h4 headings:
-**Step 1: Write the failing test** +#### Step 1: Write the failing testApply similar changes to lines 70, 77, and 82:
-**Step 2: Run test to verify it fails** +#### Step 2: Run test to verify it fails -**Step 3: Write minimal implementation** +#### Step 3: Write minimal implementation -**Step 4: Run test to verify it passes** +#### Step 4: Run test to verify it passes -**Step 5: Commit** +#### Step 5: Commit
88-88: Add language specifier to fenced code block at line 88.Line 88 contains a closing code fence without a corresponding opening fence with language specification. The block preceding it (lines 84-87) shows bash commands, so the language should be specified.
Apply this diff:
**Step 5: Commit** -```bash +```bash git add tests/path/test.py src/path/file.py.factory/skills/test-driven-development/SKILL.md (3)
33-33: Specify language for fenced code blocks to improve readability and enable syntax highlighting.Lines with missing language specifications: 33 (dot/graphviz), 49-69 (dot), 76-90 (typescript), 94-106 (typescript), 295-300 (typescript), 310-315 (typescript), 359 (text/plain).
Add language identifiers to all fenced code blocks. For example:
- ``` + ```dot digraph tdd_cycle {and
- ``` + ```typescript test('retries failed operations 3 times', async () => {Also applies to: 49-69, 76-90, 94-106, 295-300, 310-315, 359-362
208-208: Use heading syntax instead of bold formatting for section headers.Lines 208, 218, 228, 236, 246, 294, 302, 308, 318 use bold (
**Text**) where proper headings (### Text) would improve document structure and semantic clarity.Replace bold headers with heading markup:
- **"I'll write tests after to verify it works"** + ### I'll write tests after to verify it worksAlso applies to: 218-218, 228-228, 236-236, 246-246, 294-294, 302-302, 308-308, 318-318
254-254: Minor grammar: add "that" for clarity.Line 254: "lose proof tests work" → "lose proof that tests work"
.factory/skills/verification-before-completion/SKILL.md (1)
18-18: Specify language for fenced code blocks.Lines 18, 26, 79, 85, 91, 97, 103 have code blocks without language identifiers. Add
bash,text, or appropriate language:- ``` + ```bash NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCEAlso applies to: 26-26, 79-79, 85-85, 91-91, 97-97, 103-103
.factory/skills/subagent-driven-development/SKILL.md (1)
41-41: Specify language for code block examples to improve readability.Lines 41, 64, 85, 111 contain code blocks (task dispatch examples) without language identifiers.
Add language identifiers:
- ``` + ```yaml Task tool (general-purpose):or
- ``` + ```text Task(subagent_type: "general-purpose", ...Also applies to: 64-64, 85-85, 111-111
.factory/AGENTS.md (1)
52-52: Specify language for code blocks.Lines 52 and 66 have code blocks without language specifications.
- ``` + ```yaml Task(subagent_type: "general-purpose", description: "Implement Task 1", prompt: "...")and
- ``` + ```text brainstorming → writing-plans → [execution choice] → TDD per task → verification → code-review → finishing-branchAlso applies to: 66-66
.factory/install.sh (1)
87-103: AGENTS.md backup filename collision risk.Line 94 creates a backup with
${AGENTS_FILE}.backup, which will overwrite any previous backup without warning. If the installer is run multiple times, earlier backups are lost.Consider timestamping backups:
-cp "$AGENTS_FILE" "${AGENTS_FILE}.backup" +cp "$AGENTS_FILE" "${AGENTS_FILE}.backup.$(date +%s)".factory/skills/finishing-a-development-branch/SKILL.md (1)
16-197: Add language specifications to all fenced code blocks.All fenced code blocks in this skill lack language identifiers, violating MD040. Adding language specs improves readability, enables syntax highlighting, and improves searchability. Update all code blocks:
-``` +```bash # Run project's test suite npm test / cargo test / pytest / go test ./... -``` +```bashThis applies to lines: 16, 22, 42, 51, 68, 90, 102, 134, 153, 179, 185, 191, 197.
.factory/skills/writing-skills/SKILL.md (1)
74-451: Add language specifications to fenced code blocks.Multiple code blocks lack language identifiers (MD040 violations at lines 74, 103, 198, 317, 324, 332, 343, 451). Add appropriate language specs:
-``` +```yaml --- name: Skill-Name-With-Hyphens -``` +```yaml-```bash +```bash wc -w skills/path/SKILL.md -``` +```bashConsistently apply language specs throughout.
.factory/skills/testing-skills-with-subagents/SKILL.md (1)
33-33: Add language specifications to fenced code blocks.Code blocks at lines 33, 90, 208, 359 are missing language identifiers (MD040). Add appropriate specs:
-``` +```markdown IMPORTANT: This is a real scenario. Choose and act. -``` +```markdown-``` +```markdown | Excuse | Reality | -``` +```markdownApply consistently throughout the file.
Also applies to: 90-90, 208-208, 359-359
.factory/skills/testing-skills-with-subagents/examples/CLAUDE_MD_TESTING.md (1)
8-8: Add language specifications to fenced code blocks.Fenced code blocks at lines 8, 22, 39, 53 lack language identifiers (MD040). Add appropriate specs:
-``` +```markdown IMPORTANT: This is a real scenario. Choose and act. -``` +```markdownThis applies to all unlabeled code blocks in the file.
Also applies to: 22-22, 39-39, 53-53
.factory/skills/systematic-debugging/test-pressure-1.md (1)
12-20: Add language specification to code block.Line 12 has a fenced code block without language identifier (MD040). Based on context (log output), add appropriate spec:
-``` +``` PaymentError: Connection timeout to payments.api.com -``` +```(Note: This appears to be log output; consider using language-appropriate identifier like
text,log, or leaving as is if emphasizing it's plaintext.).factory/INSTALL.md (1)
52-52: Add language specifiers to code blocks.Lines 52 and 66 contain shell script blocks without language identifiers, which impacts markdown rendering and syntax highlighting.
Apply this diff:
-``` +```bash mkdir -p ~/.factory/skills cp -r ~/.factory/superpowers/.factory/skills/* ~/.factory/skills/ -``` +```And similarly for line 66:
-``` +```bash # Or append to existing: cat ~/.factory/superpowers/.factory/AGENTS.md >> ~/.factory/AGENTS.md -``` +```Also applies to: 66-66
.factory/skills/systematic-debugging/test-pressure-2.md (1)
12-15: Add language specifiers to code blocks.The code blocks at lines 12, 18, 38, and 53 show test output and pseudo-code without language identifiers. Adding appropriate specs improves rendering.
For the test failure output (lines 12-15), use language spec
textor omit language:-``` +```text Expected: { status: 'completed', amount: 100 } Received: { status: 'pending', amount: 100 } -``` +```Apply similar language specs to the other blocks.
Also applies to: 18-24, 38-42, 53-59
.factory/skills/systematic-debugging/test-pressure-3.md (1)
8-30: Add language specifiers to code blocks.Multiple code blocks (lines 8, 22, 39, 53) contain dialogue/quoted text without language identifiers. Adding specs improves markdown rendering consistency.
For dialogue blocks, use
textlanguage spec:-``` +```text You're in a Zoom call with: - Your senior engineer (10 years experience) - The tech lead - Two other developers -``` +```Apply to all dialogue/quoted text blocks.
Also applies to: 22-28, 39-59, 53-65
docs/README.factory.md (2)
26-27: Add language specifiers to code blocks.Multiple code blocks lack language identifiers, impacting syntax highlighting and rendering. Lines 26, 67, 75, 89, 110, and 143 should specify
bashor appropriate language.Example for line 26 (bash install):
-``` +```bash Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/main/.factory/INSTALL.md -``` +```Example for line 67 (bash request):
-``` +```bash Use the systematic-debugging skill to help me fix this bug -``` +```Example for line 143 (directory tree):
-``` +``` ~/.factory/ ├── AGENTS.md # Protocol (auto-loaded each session) ├── skills/ # Skills │ ├── brainstorming/ +```Apply similar changes to all other code blocks.
Also applies to: 67-68, 75-76, 89-94, 110-112, 143-161
251-253: Wrap bare URLs in markdown links.Lines 251-253 contain bare URLs that should be wrapped in markdown link syntax for better rendering and accessibility.
-## Getting Help -- Report issues: https://github.com/obra/superpowers/issues -- Factory docs: https://docs.factory.ai/ -- Superpowers blog: https://blog.fsck.com/2025/10/09/superpowers/ +## Getting Help +- Report issues: [GitHub Issues](https://github.com/obra/superpowers/issues) +- Factory docs: [Factory Documentation](https://docs.factory.ai/) +- Superpowers blog: [Superpowers Blog](https://blog.fsck.com/2025/10/09/superpowers/).factory/skills/brainstorming/SKILL.md (1)
19-19: Consider hyphenating "multiple choice" in compound adjective context.Line 19 uses "multiple choice questions" where a hyphen would improve grammar: "multiple-choice questions" when used as a compound adjective before the noun.
-- Prefer multiple choice questions when possible, but open-ended is fine too +- Prefer multiple-choice questions when possible, but open-ended is fine tooThis is a minor style preference; the current phrasing is acceptable.
.factory/skills/systematic-debugging/CREATION-LOG.md (2)
17-17: Minor style suggestion on phrasing.Lines 17 and 40 use the phrase "in a hurry" which could be more concise, though the current phrasing is clear and conversational. This is entirely optional.
The phrase "in a hurry" effectively conveys the intended meaning in this context and aligns with the skill's focus on pressure resistance. No change is necessary.
Also applies to: 40-40
89-89: Header redundancy: "Final Outcome" vs "Outcome".Line 89 uses "Final Outcome" as a header, which could be simplified to just "Outcome" or "Result" to avoid redundancy. This is a minor style point.
-## Final Outcome +## Outcome
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
.factory/skills/writing-skills/graphviz-conventions.dotis excluded by!**/*.dot
📒 Files selected for processing (42)
.factory/AGENTS.md(1 hunks).factory/INSTALL.md(1 hunks).factory/commands/brainstorm.md(1 hunks).factory/commands/execute-plan.md(1 hunks).factory/commands/write-plan.md(1 hunks).factory/droids/code-reviewer.md(1 hunks).factory/droids/explore.md(1 hunks).factory/droids/general-purpose.md(1 hunks).factory/droids/plan.md(1 hunks).factory/install.sh(1 hunks).factory/skills/brainstorming/SKILL.md(1 hunks).factory/skills/condition-based-waiting/SKILL.md(1 hunks).factory/skills/condition-based-waiting/example.ts(1 hunks).factory/skills/defense-in-depth/SKILL.md(1 hunks).factory/skills/dispatching-parallel-agents/SKILL.md(1 hunks).factory/skills/executing-plans/SKILL.md(1 hunks).factory/skills/finishing-a-development-branch/SKILL.md(1 hunks).factory/skills/receiving-code-review/SKILL.md(1 hunks).factory/skills/requesting-code-review/SKILL.md(1 hunks).factory/skills/requesting-code-review/code-reviewer.md(1 hunks).factory/skills/root-cause-tracing/SKILL.md(1 hunks).factory/skills/root-cause-tracing/find-polluter.sh(1 hunks).factory/skills/sharing-skills/SKILL.md(1 hunks).factory/skills/subagent-driven-development/SKILL.md(1 hunks).factory/skills/systematic-debugging/CREATION-LOG.md(1 hunks).factory/skills/systematic-debugging/SKILL.md(1 hunks).factory/skills/systematic-debugging/test-academic.md(1 hunks).factory/skills/systematic-debugging/test-pressure-1.md(1 hunks).factory/skills/systematic-debugging/test-pressure-2.md(1 hunks).factory/skills/systematic-debugging/test-pressure-3.md(1 hunks).factory/skills/test-driven-development/SKILL.md(1 hunks).factory/skills/testing-anti-patterns/SKILL.md(1 hunks).factory/skills/testing-skills-with-subagents/SKILL.md(1 hunks).factory/skills/testing-skills-with-subagents/examples/CLAUDE_MD_TESTING.md(1 hunks).factory/skills/using-git-worktrees/SKILL.md(1 hunks).factory/skills/using-superpowers/SKILL.md(1 hunks).factory/skills/verification-before-completion/SKILL.md(1 hunks).factory/skills/writing-plans/SKILL.md(1 hunks).factory/skills/writing-skills/SKILL.md(1 hunks).factory/skills/writing-skills/anthropic-best-practices.md(1 hunks).factory/skills/writing-skills/persuasion-principles.md(1 hunks)docs/README.factory.md(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
.factory/skills/condition-based-waiting/example.ts (1)
lib/skills-core.js (1)
description(23-23)
🪛 LanguageTool
.factory/skills/condition-based-waiting/SKILL.md
[grammar] ~32-~32: Ensure spelling is correct
Context: ...ass sometimes, fail under load) - Tests timeout when run in parallel - Waiting for asyn...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
.factory/skills/writing-skills/SKILL.md
[grammar] ~287-~287: Ensure spelling is correct
Context: ...ists - Labels without semantic meaning (step1, helper2) See @graphviz-conventions.do...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~287-~287: Ensure spelling is correct
Context: ...Labels without semantic meaning (step1, helper2) See @graphviz-conventions.dot for gra...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~372-~372: ‘under stress’ might be wordy. Consider a shorter alternative.
Context: ...s? - Pressure scenarios: Do they comply under stress? - Multiple pressures combined: time + ...
(EN_WORDINESS_PREMIUM_UNDER_STRESS)
[style] ~544-~544: To elevate your writing, try using a synonym here.
Context: ...e"]; ``` Why bad: Can't copy-paste, hard to read ### ❌ Generic Labels helper1, ...
(HARD_TO)
.factory/skills/test-driven-development/SKILL.md
[grammar] ~254-~254: Use a hyphen to join words.
Context: ...ests after ≠ TDD. You get coverage, lose proof tests work. ## Common Rationaliza...
(QB_NEW_EN_HYPHEN)
[style] ~267-~267: To elevate your writing, try using a synonym here.
Context: ...clear" | Listen to test. Hard to test = hard to use. | | "TDD will slow me down" | T...
(HARD_TO)
.factory/skills/systematic-debugging/SKILL.md
[style] ~43-~43: ‘in a hurry’ might be wordy. Consider a shorter alternative.
Context: ...ple bugs have root causes too) - You're in a hurry (rushing guarantees rework) - Manager w...
(EN_WORDINESS_PREMIUM_IN_A_HURRY)
.factory/skills/systematic-debugging/CREATION-LOG.md
[style] ~17-~17: ‘in a hurry’ might be wordy. Consider a shorter alternative.
Context: ...uage ("even if faster", "even if I seem in a hurry") - Concrete steps for each phase **Wh...
(EN_WORDINESS_PREMIUM_IN_A_HURRY)
[style] ~40-~40: ‘in a hurry’ might be wordy. Consider a shorter alternative.
Context: ...") - "even if faster" / "even if I seem in a hurry" - "STOP and re-analyze" (explicit paus...
(EN_WORDINESS_PREMIUM_IN_A_HURRY)
[style] ~89-~89: This phrase is redundant. Consider writing “Outcome”.
Context: ...nts confusion between methodologies ## Final Outcome Bulletproof skill that: - ✅ Clearly ma...
(FINAL_END)
.factory/skills/writing-skills/anthropic-best-practices.md
[style] ~22-~22: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...Default assumption**: Claude is already very smart Only add context Claude doesn't alread...
(EN_WEAK_ADJECTIVE)
[style] ~140-~140: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...: Is the Skill clear and efficient? * Claude Opus (powerful reasoning): Does the S...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~802-~802: Try replacing commonly used words with synonyms to make your writing more engaging.
Context: ...encounter new scenarios. Each iteration improves the Skill based on real agent behavior,...
(IMPROVE_STRENGTHEN)
.factory/skills/requesting-code-review/code-reviewer.md
[style] ~106-~106: Try using a synonym here to strengthen your writing.
Context: ... checking - Mark nitpicks as Critical - Give feedback on code you didn't review - Be...
(GIVE_PROVIDE)
.factory/skills/brainstorming/SKILL.md
[grammar] ~19-~19: Use a hyphen to join words.
Context: ...ime to refine the idea - Prefer multiple choice questions when possible, but open...
(QB_NEW_EN_HYPHEN)
.factory/skills/testing-skills-with-subagents/SKILL.md
[grammar] ~330-~330: Ensure spelling is correct
Context: ...ed flags list - [ ] Updated description ith violation symptoms - [ ] Re-tested - ag...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🪛 markdownlint-cli2 (0.18.1)
.factory/skills/systematic-debugging/test-pressure-1.md
12-12: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
29-29: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
37-37: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
53-53: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
.factory/skills/testing-skills-with-subagents/examples/CLAUDE_MD_TESTING.md
8-8: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
22-22: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
39-39: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
53-53: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/testing-anti-patterns/SKILL.md
33-33: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
90-90: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
208-208: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
218-218: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
228-228: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
236-236: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
246-246: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
294-294: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
302-302: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
.factory/skills/subagent-driven-development/SKILL.md
41-41: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
64-64: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
85-85: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
111-111: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/verification-before-completion/SKILL.md
18-18: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
26-26: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
79-79: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
85-85: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
91-91: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
97-97: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
103-103: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/writing-skills/SKILL.md
74-74: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
293-293: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
317-317: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
324-324: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
332-332: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
343-343: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
451-451: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/dispatching-parallel-agents/SKILL.md
143-143: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/using-git-worktrees/SKILL.md
42-42: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
138-138: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
158-158: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
162-162: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
166-166: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
170-170: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
176-176: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/test-driven-development/SKILL.md
33-33: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
90-90: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
208-208: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
218-218: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
228-228: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
236-236: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
246-246: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
294-294: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
302-302: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
308-308: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
318-318: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
359-359: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/systematic-debugging/SKILL.md
18-18: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
77-77: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/INSTALL.md
52-52: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
66-66: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/README.factory.md
26-26: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
67-67: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
75-75: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
89-89: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
110-110: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
143-143: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
251-251: Bare URL used
(MD034, no-bare-urls)
252-252: Bare URL used
(MD034, no-bare-urls)
253-253: Bare URL used
(MD034, no-bare-urls)
.factory/AGENTS.md
52-52: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
66-66: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/writing-plans/SKILL.md
65-65: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
70-70: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
77-77: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
82-82: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
88-88: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/writing-skills/anthropic-best-practices.md
149-149: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
150-150: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
192-192: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
193-193: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
194-194: Unordered list indentation
Expected: 0; Actual: 2
(MD007, ul-indent)
257-257: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
301-301: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
1040-1040: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/requesting-code-review/code-reviewer.md
112-112: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/finishing-a-development-branch/SKILL.md
16-16: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
42-42: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
51-51: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
68-68: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
90-90: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
102-102: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
134-134: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
153-153: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
179-179: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
185-185: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
191-191: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
197-197: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/requesting-code-review/SKILL.md
51-51: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/systematic-debugging/test-pressure-3.md
8-8: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
22-22: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
39-39: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
53-53: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
.factory/skills/testing-skills-with-subagents/SKILL.md
33-33: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
90-90: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
208-208: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
218-218: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
228-228: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
236-236: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
246-246: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
294-294: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
302-302: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
308-308: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
318-318: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
359-359: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (28)
.factory/skills/writing-skills/anthropic-best-practices.md (1)
1-20: Clarify alignment with Factory/Droid CLI context.This documentation file references Anthropic's Claude platform, system prompts, and Claude-specific features (e.g., "Claude Haiku," "Claude Sonnet," "Claude Opus," context windows). However, the PR objectives indicate support for Factory's Droid CLI, which may have different architecture and tooling.
Please clarify:
- Is this intended as a general reference for understanding Claude Skills concepts that transfer to Droid CLI?
- Or should content be adapted to reflect Droid CLI-specific terminology, models, and architecture?
- Are there Droid CLI equivalents for the concepts described (e.g., alternative model names, different context handling)?
.factory/skills/writing-skills/persuasion-principles.md (2)
7-7: Research foundation is solid and well-cited.The Meincke et al. (2025) study tested 7 persuasion principles with 28,000 conversations with GPT-4o-mini, and compliance increased from 33.3% (control) to 72% (treatment), p < .001. The paper is peer-reviewed and available through SSRN and Wharton's Generative AI Labs.
136-165: Ethical framing is commendable and aligns with research recommendations.The file correctly distinguishes between legitimate practices (ensuring critical practices are followed, preventing predictable failures) and illegitimate use (manipulation for personal gain, creating false urgency). The test provided—"Would this technique serve the user's genuine interests if they fully understood it?"—aligns with research guidance that legitimate use involves clearly stated goals and respectful tone, while unethical use circumvents safety or creates harm.
.factory/commands/execute-plan.md (1)
1-7: LGTM!Clear and concise command definition following the established pattern. The instruction to load the skill via
Skill("executing-plans")is explicit and aligns with the framework conventions..factory/skills/systematic-debugging/SKILL.md (1)
110-120: Verify that referenced sub-skillroot-cause-tracingis defined.Line 114 references "Use
root-cause-tracingskill" as a required sub-skill for Phase 1, step 5. Confirm that this skill exists and is properly documented elsewhere in the.factory/skills/directory..factory/skills/sharing-skills/SKILL.md (1)
1-194: Well-structured contribution workflow with practical examples and troubleshooting.The skill guide provides a clear, step-by-step workflow for contributors. The bash commands are correct and the complete example (async-patterns skill) demonstrates the full process concisely. The troubleshooting section addresses real-world issues (gh CLI setup, SSH keys, merge conflicts). The multi-skill contribution guideline is sound: one skill per PR ensures independent review and merge. The prerequisite linkage to writing-skills ensures quality gates are maintained.
.factory/droids/general-purpose.md (1)
1-20: Clear and concise general-purpose droid definition with sound TDD emphasis.The droid specification is well-structured and the six-step workflow appropriately emphasizes test-driven development (RED → GREEN → Refactor). The capabilities are practical for complex tasks, and the report-back format is clear. However, verify that all referenced tools (Read, LS, Grep, Glob, Create, Edit, MultiEdit, Execute, TodoWrite) are available in the Droid CLI environment.
Please confirm that all tools listed in the
toolsarray on line 4 are available in the Factory Droid CLI implementation..factory/droids/explore.md (1)
1-34: LGTM!The explore droid is well-defined with clear read-only constraints and a focused tool set (Read, LS, Grep, Glob). The use cases and report-back structure are practical and encourage thorough exploration before proposing changes. The distinction between this read-only droid and the general-purpose droid creates good separation of concerns.
.factory/droids/code-reviewer.md (1)
1-56: Comprehensive code review framework with clear process and output structure.The code-reviewer droid specification provides a structured three-part review process that covers plan alignment, code quality, and architecture. The issue categorization (Critical/Important/Minor) helps prioritize findings. The output format example is clear and encourages concise yet thorough feedback. SOLID principles and security/performance considerations are appropriately included in the architecture review checklist.
.factory/skills/defense-in-depth/SKILL.md (1)
1-127: Excellent defense-in-depth validation pattern documentation.The four-layer validation approach is clearly explained with concrete TypeScript examples and a real-world session example. The pattern (entry point, business logic, environment guards, debug instrumentation) provides actionable guidance for implementing robust validation. The document effectively argues why multiple layers are necessary and shows how each layer catches different failure modes.
.factory/skills/executing-plans/SKILL.md (1)
1-76: Well-structured plan execution workflow.The executing-plans skill provides a clear, batched approach to implementation with explicit checkpoints and sub-skill integration. The process is concise, the stopping conditions are well-defined (line 54-60), and the handoff to finishing-a-development-branch is properly mandatory (line 49). Good use of explicit announcements and verification points.
.factory/commands/write-plan.md (1)
1-7: Concise and clear command reference.The write-plan.md command reference is minimal and correct. It properly references the writing-plans skill and provides the exact loading syntax. Consistent with other command documentation in the PR.
.factory/droids/plan.md (1)
1-35: Well-structured droid definition that clearly scopes planning research capabilities.The frontmatter, tools mapping, and workflow guidance are clear and appropriate for a planning-phase research agent. No concerns.
.factory/skills/root-cause-tracing/SKILL.md (1)
1-174: Excellent root-cause tracing methodology with clear examples and practical guidance.The skill documentation provides a systematic approach to tracing bugs backward through call stacks, includes concrete examples, instrumentation patterns, and integrates well with the companion
find-polluter.shscript. The examples and decision trees are clear and actionable..factory/skills/using-superpowers/SKILL.md (1)
1-100: Well-designed mandatory protocol with clear enforcement mechanisms and anti-rationalization patterns.The skill establishes a clear contract about skill discovery and usage, prevents common justifications for skipping the protocol, and integrates TodoWrite for checklist tracking. The tone is appropriately firm about mandatory vs. flexible patterns.
.factory/skills/subagent-driven-development/SKILL.md (1)
176-188: Integration section clearly documents required skills and dependencies.The skill properly declares its dependencies on writing-plans, requesting-code-review, and finishing-a-development-branch, enabling clear upstream/downstream workflow orchestration. This is well-structured.
.factory/AGENTS.md (1)
1-80: Protocol effectively establishes system-level override with clear tool mapping and droid dispatch guidance.The AGENTS.md document successfully bridges Superpowers protocol requirements to Droid CLI's native tooling (Skill, Task, TodoWrite, Execute). The workflow chain and critical rules are well-defined. The tool mapping table at lines 30-38 and droid dispatch table at lines 40-54 provide clear, actionable guidance for practitioners.
.factory/skills/root-cause-tracing/find-polluter.sh (1)
22-23: Based on the authoritative web search results from GNU findutils documentation, I can now provide my final assessment.The review comment is technically incorrect. The web search clearly states that in
find -path:
*can match/(unlike infind -name)- Therefore
**can match multiple directory levels including slashes- The pattern
src/**/*.test.tsshould work correctly withfind -pathThe review comment's core claim—that
find . -path "$TEST_PATTERN"doesn't work with glob patterns like'src/**/*.test.ts'—is based on a misconception about howfind -pathhandles patterns.
find -pathcorrectly handles**patterns with glob matching including directory separators.Line 22's use of
find . -path "$TEST_PATTERN"is not problematic. Thefind -pathcommand uses shell glob (fnmatch) semantics where*can match/characters, meaning**patterns correctly match multiple directory levels recursively. The pattern'src/**/*.test.ts'will work as intended.No fix is required for this code.
.factory/skills/writing-skills/SKILL.md (1)
293-293: Replace emphasis with proper heading.Line 293 uses emphasis (
**Code in Flowcharts**) where a heading would be more appropriate (MD036). Use###instead:-### ❌ Code in Flowcharts +### ❌ Code in FlowchartsActually, looking at context, the heading already exists. This appears to be a false positive from markdownlint.
.factory/commands/brainstorm.md (1)
1-6: File structure looks good.This command definition is properly minimal and references the brainstorming skill. Ensure the brainstorming skill exists at
.factory/skills/brainstorming/SKILL.md(referenced in PR objectives but not in provided files)..factory/skills/systematic-debugging/test-academic.md (1)
1-13: File structure and content are appropriate.This academic test is well-structured and follows the test-pressure framework. Verify that the referenced
skills/debugging/systematic-debuggingskill exists and contains the content expected by the test questions..factory/install.sh (1)
67-67: Glob expansion behavior confirmed as a valid concern, but repository access is unavailable for specific verification.The web search confirms the underlying risk is real: by default, unquoted globs in bash that don't match expand to their literal string pattern. In line 67 (
cp "${SUPERPOWERS_DIR}/.factory/droids/"* "${FACTORY_DIR}/droids/" 2>/dev/null || true), if no files exist, the glob expands to the literal string*.../droids/*, andcpfails with "cannot stat" — but the error is silenced by2>/dev/null || true, resulting in zero files copied without indication of failure.The suggested fix using
findwith-execis a valid approach to avoid this pitfall, asfindhandles non-existent or empty directories gracefully without glob expansion side effects.However, I cannot verify:
- Whether
.factory/droids/and.factory/commands/directories are actually empty or populated in the repository- Whether this manifests as an actual problem in practice for this specific installation script
The concern is technically sound for the general case. To definitively resolve this, manual inspection of the repository structure and testing the actual installer behavior would be needed.
.factory/INSTALL.md (1)
1-188: Installation guide is well-structured and comprehensive.The guide provides clear pathways for multiple installation scenarios (one-line, quick via Droid, manual step-by-step), detailed verification tests, and good troubleshooting coverage. The checklist format and verification tests are particularly helpful for users validating their setup.
.factory/skills/systematic-debugging/test-pressure-2.md (1)
1-68: Realistic pressure scenario effectively tests decision-making.This pressure test realistically portrays sunk cost fallacy and time pressure in debugging contexts, providing three credible options (A: restart systematic investigation, B: pragmatic timeout solution, C: balanced middle ground). The scenario serves as effective training for recognizing when shortcuts may be justified versus when systematic investigation is needed.
.factory/skills/systematic-debugging/test-pressure-3.md (1)
1-68: Authority pressure scenario effectively illustrates methodology resistance.This scenario realistically portrays how technical expertise and social hierarchy can create pressure to skip systematic processes. The three options (A: insist on investigation, B: defer to authority, C: compromise with quick check) effectively capture the real tension between following methodology and team dynamics. Useful for training judgment under organizational pressure.
docs/README.factory.md (1)
1-254: Comprehensive and well-organized documentation.The documentation effectively maps Superpowers concepts to Droid CLI's native tools and workflows, provides clear installation and verification pathways, documents the workflow progression, and addresses troubleshooting and differences from Claude Code. The architecture section and tool mapping tables are particularly helpful for understanding integration details.
.factory/skills/brainstorming/SKILL.md (1)
1-54: Brainstorming skill is well-defined with clear process.The skill provides a structured approach to design refinement with logical phases (understanding → exploring → presenting), appropriate guidance on presentation format (200-300 word sections with validation), and clear integration points with downstream skills. The emphasis on one question at a time and multiple-choice preferences is practical.
.factory/skills/systematic-debugging/CREATION-LOG.md (1)
1-118: Creation log effectively documents skill extraction and bulletproofing methodology.This reference document provides valuable meta-documentation showing how the systematic-debugging skill was extracted from the AGENTS.md protocol, structured following skill-creation guidelines, and bulletproofed against rationalization. The testing approach with four validation scenarios and the emphasis on anti-patterns as cognitive friction is insightful. Useful template for future skill creation efforts.
| if [[ -d "$SUPERPOWERS_DIR" ]]; then | ||
| echo " Repository exists, updating..." | ||
| cd "$SUPERPOWERS_DIR" | ||
| git pull --quiet | ||
| echo -e "${GREEN} ✓ Repository updated${NC}" | ||
| else | ||
| echo " Cloning repository..." | ||
| git clone --quiet "$REPO_URL" "$SUPERPOWERS_DIR" | ||
| echo -e "${GREEN} ✓ Repository cloned${NC}" | ||
| fi |
There was a problem hiding this comment.
Verify git pull success before proceeding.
Line 46 runs git pull --quiet without checking the exit code. If git pull fails (e.g., merge conflict, network error), the script continues with outdated code. Consider:
cd "$SUPERPOWERS_DIR"
-git pull --quiet
+git pull --quiet || { echo -e "${RED}✗ Failed to update repository${NC}"; exit 1; }
echo -e "${GREEN} ✓ Repository updated${NC}"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if [[ -d "$SUPERPOWERS_DIR" ]]; then | |
| echo " Repository exists, updating..." | |
| cd "$SUPERPOWERS_DIR" | |
| git pull --quiet | |
| echo -e "${GREEN} ✓ Repository updated${NC}" | |
| else | |
| echo " Cloning repository..." | |
| git clone --quiet "$REPO_URL" "$SUPERPOWERS_DIR" | |
| echo -e "${GREEN} ✓ Repository cloned${NC}" | |
| fi | |
| if [[ -d "$SUPERPOWERS_DIR" ]]; then | |
| echo " Repository exists, updating..." | |
| cd "$SUPERPOWERS_DIR" | |
| git pull --quiet || { echo -e "${RED}✗ Failed to update repository${NC}"; exit 1; } | |
| echo -e "${GREEN} ✓ Repository updated${NC}" | |
| else | |
| echo " Cloning repository..." | |
| git clone --quiet "$REPO_URL" "$SUPERPOWERS_DIR" | |
| echo -e "${GREEN} ✓ Repository cloned${NC}" | |
| fi |
🤖 Prompt for AI Agents
In .factory/install.sh around lines 43 to 52, the script runs git pull --quiet
without checking its exit status; modify it to test the git pull result
immediately (e.g., if ! git pull --quiet; then echo an error with details to
stderr and exit 1) so the script stops on pull failures (optionally attempt a
safe recovery like git fetch && git reset --hard origin/<branch> only after
explicit success checks) to avoid continuing with outdated code.
| | Scenario | Pattern | | ||
| |----------|---------| | ||
| | Wait for event | `waitFor(() => events.find(e => e.type === 'DONE'))` | | ||
| | Wait for state | `waitFor(() => machine.state === 'ready')` | | ||
| | Wait for count | `waitFor(() => items.length >= 5)` | | ||
| | Wait for file | `waitFor(() => fs.existsSync(path))` | | ||
| | Complex condition | `waitFor(() => obj.ready && obj.value > 10)` | | ||
|
|
There was a problem hiding this comment.
Align documentation snippets with the actual helper signatures
There are a couple of small consistency issues that might trip up someone copy‑pasting:
- The generic
waitForimplementation includes adescriptionparameter, but the “Quick Patterns” table shows calls likewaitFor(() => items.length >= 5)with only a condition argument. - The “When Arbitrary Timeout IS Correct” snippet uses
await waitForEvent(manager, 'TOOL_STARTED');, while the concrete implementation inexample.tsiswaitForEvent(threadManager, threadId, eventType, timeoutMs?).
It would be clearer to either:
- Update the examples to include the
descriptionparameter and thethreadIdargument (and consistent parameter ordering), or - Explicitly note that those snippets are pseudocode and point readers directly to
.factory/skills/condition-based-waiting/example.tsfor the exact signatures.
Also applies to: 65-85, 102-107
🤖 Prompt for AI Agents
.factory/skills/condition-based-waiting/SKILL.md around lines 55-62 (and also
apply same changes to lines 65-85 and 102-107): the documentation snippets show
simplified calls to waitFor and waitForEvent that don’t match the actual helper
signatures (missing the description parameter for waitFor and missing/incorrect
threadId and parameter order for waitForEvent). Update the examples to use the
real signatures (include the description argument in waitFor calls and include
threadId and correct parameter order and optional timeout in waitForEvent
calls), or alternatively add a brief note above the “Quick Patterns” table
stating these are pseudocode and point readers to
.factory/skills/condition-based-waiting/example.ts for exact signatures; make
the change consistently in all referenced line ranges.
| ## Forbidden Responses | ||
|
|
||
| **NEVER:** | ||
| - "You're absolutely right!" (explicit CLAUDE.md violation) |
There was a problem hiding this comment.
Update terminology reference from CLAUDE.md to AGENTS.md.
Line 30 references "CLAUDE.md" which should be "AGENTS.md" per the PR's terminology shift to Factory/Droid CLI compatibility. This creates inconsistency with the updated protocol documentation.
Apply this diff:
-- "You're absolutely right!" (explicit CLAUDE.md violation)
+- "You're absolutely right!" (explicit AGENTS.md violation)🤖 Prompt for AI Agents
In .factory/skills/receiving-code-review/SKILL.md around line 30 the terminology
reference incorrectly mentions "CLAUDE.md"; update that reference to "AGENTS.md"
to match the PR's terminology shift and ensure consistency with the
Factory/Droid CLI protocol documentation. Replace the string/mention "CLAUDE.md"
with "AGENTS.md" wherever it appears on that line and update any adjacent
phrasing if needed to maintain grammatical consistency.
| - Reference working tests/code | ||
| - Involve your human partner if architectural | ||
|
|
||
| **Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K" |
There was a problem hiding this comment.
Replace obscure cultural reference with explicit directive.
Line 129 uses "Strange things are afoot at the Circle K" (a Bill & Ted reference) to signal discomfort. This is unclear for readers unfamiliar with the film, and the intent should be stated directly for a workflow document.
Apply this diff:
-**Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K"
+**Signal if uncomfortable pushing back out loud:** Use a clear marker (e.g., "I'm concerned about pushing back here") and ask for guidance before proceeding.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| **Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K" | |
| **Signal if uncomfortable pushing back out loud:** Use a clear marker (e.g., "I'm concerned about pushing back here") and ask for guidance before proceeding. |
🤖 Prompt for AI Agents
In .factory/skills/receiving-code-review/SKILL.md around line 129, replace the
obscure Bill & Ted reference "Strange things are afoot at the Circle K" with an
explicit directive that tells reviewers what to do when they feel uncomfortable
pushing back; change the line to a clear instruction such as "If you feel
uncomfortable pushing back, explicitly say so (e.g., 'I’m not comfortable
pushing back on this') and explain your concerns or request time to revisit the
decision."
| - [ ] Added explicit counters for each loophole | ||
| - [ ] Updated rationalization table | ||
| - [ ] Updated red flags list | ||
| - [ ] Updated description ith violation symptoms |
There was a problem hiding this comment.
Fix typo in checklist item.
Line 330 contains a typo: "Updated description ith violation symptoms" should be "Updated description with violation symptoms".
Apply this fix:
- - [ ] Updated description ith violation symptoms
+ - [ ] Updated description with violation symptoms📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [ ] Updated description ith violation symptoms | |
| - [ ] Updated description with violation symptoms |
🧰 Tools
🪛 LanguageTool
[grammar] ~330-~330: Ensure spelling is correct
Context: ...ed flags list - [ ] Updated description ith violation symptoms - [ ] Re-tested - ag...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In .factory/skills/testing-skills-with-subagents/SKILL.md around line 330, fix
the typo in the checklist item by replacing "Updated description ith violation
symptoms" with "Updated description with violation symptoms"; update the line
exactly to correct "ith" to "with" and keep the surrounding checklist formatting
unchanged.
|
|
||
| **If found:** Use that directory. If both exist, `.worktrees` wins. | ||
|
|
||
| ### 2. Check CLAUDE.md |
There was a problem hiding this comment.
Update CLAUDE.md reference to align with AGENTS.md terminology.
Line 30 references CLAUDE.md which should be updated to AGENTS.md per the PR's terminology shift for Factory/Droid CLI compatibility.
Apply this diff:
-### 2. Check CLAUDE.md
+### 2. Check AGENTS.md📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### 2. Check CLAUDE.md | |
| ### 2. Check AGENTS.md |
🤖 Prompt for AI Agents
In .factory/skills/using-git-worktrees/SKILL.md around line 30, update the
reference "CLAUDE.md" to "AGENTS.md" so terminology matches the PR; replace the
filename and any link or mention at that line to point to AGENTS.md (and adjust
link path if needed) ensuring the text and link target are consistent with the
new AGENTS.md naming.
1 participant
Summary
.factory/
├── AGENTS.md # Protocol (auto-loaded by Droid CLI)
├── INSTALL.md # Installation guide
├── install.sh # One-line installer
├── commands/ # Slash commands
│ ├── brainstorm.md
│ ├── write-plan.md
│ └── execute-plan.md
├── droids/ # Droid definitions for Task tool
│ ├── general-purpose.md
│ ├── code-reviewer.md
│ ├── explore.md
│ └── plan.md
└── skills/ # 20 skills (adjusted for Droid CLI)
├── brainstorming/
├── test-driven-development/
├── systematic-debugging/
└── ... (17 more)
docs/
└── README.factory.md # Complete documentation
Or via Droid CLI:
Summary by CodeRabbit
Release Notes
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.