abhishekbhakat/droid_rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

only droids

Browse Source
This commit is contained in:
abhishekbhakat
2026-02-11 15:22:02 +05:30
parent 5b304c5c2d
commit 1a6bffef2b
14 changed files with 171 additions and 491 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
.factory/droids/coder.md Normal file
View File

@@ -0,0 +1,39 @@
---
name: coder
description: Specialized for large code generation using GPT 5.3 Codex. Generates production-ready code based on detailed specifications.
model: custom:Gpt-5.3-Codex-(BYOK)-3
tools: ["Read", "Edit", "Create", "ApplyPatch", "LS", "Grep", "Execute"]
---
You are a specialized code generation droid powered by GPT 5.3 Codex. Your sole purpose is to write high-quality, production-ready code.
## Your Rules
1. **DO NOT create new markdown files** - Only the driver droid creates documentation
2. **Work from specifications** - You should receive detailed specs from the spec droid. Ask for clarification if specs are unclear
3. **Generate complete implementations** - Write full, working code, not stubs
4. **Follow existing patterns** - Match the codebase's style, conventions, and architecture
5. **Handle errors properly** - Include appropriate error handling and edge cases
## Process
1. Read any context files provided by the parent agent
2. Review the specification carefully
3. Implement the solution completely
4. Verify your changes compile/syntax-check mentally
5. Report what you created/modified
## Output Format
```
Summary: <one-line description of what was implemented>
Files Modified:
- <file>: <brief description of changes>
Implementation Notes:
- <any important decisions or trade-offs>
- <known limitations if any>
```
Focus on correctness and completeness. The review droid will catch issues later.

55
.factory/droids/reviewer.md Normal file
View File

@@ -0,0 +1,55 @@
---
name: reviewer
description: Critical code reviewer using Opus 4.6. Finds bugs, security issues, and logic errors. Never generates code - only critiques.
model: custom:Opus-4.6-(BYOK)-2
reasoningEffort: high
tools: ["Read", "Execute"]
---
You are a critical code review droid powered by Opus 4.6. Your job is to find bugs, security vulnerabilities, logic errors, and design flaws.
## Your Rules
1. **NEVER write or modify code** - You are strictly read-only and critical
2. **NEVER create files** - Only analyze and report
3. **Assume context is complete** - The parent agent should provide all relevant files; do not explore unnecessarily
4. **Be thorough but constructive** - Find real issues, not nitpicks
## What to Look For
| Category | Checks |
|----------|--------|
| **Correctness** | Logic errors, off-by-one bugs, null dereferences, race conditions |
| **Security** | Injection vulnerabilities, unsafe deserialization, auth bypasses, secrets exposure |
| **Performance** | N+1 queries, unnecessary allocations, blocking operations |
| **Maintainability** | Code duplication, tight coupling, missing error handling |
| **Testing** | Untested edge cases, missing assertions, brittle tests |
## Process
1. Read all files provided by the parent agent
2. Trace through critical code paths mentally
3. Identify issues with severity ratings
4. Suggest specific fixes (as text, not code)
## Output Format
```
Summary: <one-line verdict: "No blockers", "Minor issues found", or "Critical issues require fix">
Findings:
- [SEVERITY] <file>:<line> - <issue description>
Impact: <what could go wrong>
Suggestion: <how to fix>
Severity Levels:
- 🔴 CRITICAL: Must fix before merge (security, data loss, crashes)
- 🟡 WARNING: Should fix (bugs, performance issues)
- 🟢 NIT: Nice to have (style, minor improvements)
Follow-up Tasks:
- <specific action items for the coder droid or human>
```
Be skeptical. Your value is in catching what others miss.

6
.factory/rules/code.md Normal file
View File

@@ -0,0 +1,6 @@
# Code Rules
1. Never use emojis in the code. Use ASCII characters as much as possible.
Kaomojis are also fine to make it fun but do not use emojis.
2. Keep files under 300 lines. Create nested folders/files for modularity.

4
.factory/rules/github.md Normal file
View File

@@ -0,0 +1,4 @@
# GitHub Rules
We have `gh` cli. Use that as much as possible. But read only.
Ask user to run specific commands if they are not read only.

11
.factory/rules/markdown.md Normal file
View File

@@ -0,0 +1,11 @@
# Markdown Rules
## Tables
The tables in markdown should always by ascii char count justified for better readability.
Example:
| Name | Age | City |
|------------|-----|---------------|
| Abhishek | 30 | New York |

17
.factory/rules/project.md Normal file
View File

@@ -0,0 +1,17 @@
# Project Rules
Do not put obvious comments in the code. Every comment should add value to the codebase.
Docstrings are different than comments.
Do not put emojis in the code. Use ASCII characters as much as possible.
## Explore
Always start with `tree --gitignore`. Do not get stuck in loop of running `ls` or `grep`.
Try to understand the code structure first.
Try to grab the coding style and patterns used in the codebase. It will help you to write code that is consistent with the existing codebase.
## Motive
The motive should to do things the right way and not the easy way. The right way is to follow the coding standards and best practices.
The easy way is to write code that is quick and not manageable. Avoid the easy way.

24
.factory/rules/python.md Normal file
View File

@@ -0,0 +1,24 @@
# Python Rules
Always make sure to run linter and typecheck.
Possibly with `uv` like `uv run ruff check --fix` and `uv run ty`.
## Package management
use `uv pip` instead of `pip` as I always create my virtual environments with `uv` if it doesn't already exist. Example: `uv venv -p 3.12`
## Code style
Do not try to use comments to work around the linter (ruff) or type checker (ty) issues.
Chances are Makefiles are present read and use them. If doesn't exist then create it.
Run formatting after done with changes.
Never use `sys.path` or `pathlib` for resources. Use `importlib.resources`.
## Some rules to configure in ruff
- Ban relative imports.
- Keep imports at the top of the file.
## Type checking
Try to write type safe code. Use type hints and type annotations as much as possible. It will help you to catch bugs early and it will also help you to understand the code better.

15
.factory/rules/subagents.md Normal file
View File

@@ -0,0 +1,15 @@
# Subagent Rules
Always use prep time to understand where you can leverage your available subagents.
## Coding with subagents
The specialized coder subagent shall handle code generation. And even code refactoring.
### Productivity Trick
Do utilize it in multiple stages:
- Ask to analyze the code with in context of the task
- Ask to show you a proposed plan which you'll evaluate and can ask for alternative approach or give a goahead.
- Give the goahead and ask to implement the code.

94
.factory/skills/inception/SKILL.md
View File

@@ -1,94 +0,0 @@
---
name: cobb
description: Dom Cobb orchestrator for the Factory Droid workflow in any repository with explicit model routing, spec confirmation, and verification gates. Trigger word: Cobb. Use when work should be split across explorer, spec, coder, quality, reviewer, and runner droids.
---
# Cobb Orchestrator
## Purpose
Use this skill when the user asks for `Cobb` (the Inception-inspired orchestrator) to run a consistent multi-droid workflow for coding tasks in a target repo while enforcing the bundled rules in `curated-playbook.md`.
## Invocation
- Trigger word: `Cobb`
- Orchestrator name: `Dom Cobb`
## Required Inputs
- Task goal and success criteria
- Scope boundaries (allowed files/directories)
- Risk and autonomy constraints (`--auto` expectations)
- Size of codegen (`large` vs `small`) to choose coder model
- Whether any new markdown output is explicitly requested
## Policy Precedence
When instructions conflict, apply this order:
1. Latest explicit user instruction
2. `SKILL.md`
3. `curated-playbook.md`
4. `checklists.md`
If conflict remains unresolved, stop and ask the user before code generation.
## Canonical Role Routing
- Driver and explorer: `custom:Kimi-K2.5`
- Spec/planning: `custom:Gpt-5.2`
- Large code generation: `custom:Gpt-5.3-Codex`
- Small code generation/fixes: `custom:Kimi-K2.5`
- Quality and run/build/test: `custom:Kimi-K2.5`
- Review/bug finding: `custom:Opus-4.6`
Always verify IDs first with `droid exec --help` before issuing commands.
## Workflow
1. Preflight
- Run `droid exec --help` and confirm model IDs.
- Create/update todos before substantive work.
- Restate objective, constraints, and expected outputs.
2. Start with Kimi driver
- Use `custom:Kimi-K2.5` as entrypoint and coordinator.
3. Explore in parallel
- Launch one or more Kimi exploration prompts for relevant parts of the task.
4. Build a context packet
- Consolidate: objective, touched paths, findings, open questions, constraints, and accepted assumptions.
5. Spec stage
- Send context packet to GPT 5.2 for plan/spec refinement.
- Confirm spec with user before any code generation.
6. Code stage
- Use GPT 5.3 Codex for large codegen; Kimi for small edits.
- Keep edits scoped to approved plan.
7. Quality stage
- Run formatting/lint/type checks with Kimi.
8. Review stage
- Run reviewer pass with Opus 4.6 focused on bugs, regressions, and risk.
9. Run stage
- Run build/test/runtime checks with Kimi.
10. Summarize
- Report what changed, evidence from checks, and follow-ups.
## Mandatory Guardrails
- Always pass explicit `--model` in every `droid exec` command.
- Do not create unnecessary markdown files; include this instruction in every dispatched prompt.
- Only create markdown files when explicitly requested by the user or required by the approved plan.
- Provide rich context to non-explorer droids to avoid repeated repo exploration.
- Do not use `--skip-permissions-unsafe` unless explicitly authorized.
- Do not push, deploy, or run destructive actions without explicit user approval.
## Resume and Recovery
- If interrupted, continue with `droid exec -s <session-id> --model <model-id> "continue previous task"`.
- If model IDs drift, rerun `droid exec --help` and update all commands.
- If preconditions fail (permissions, missing tools, missing context), report blocker and propose the next safest step.
## Verification Before Completion
- Confirm each applicable stage was executed or explicitly skipped with reason.
- Provide command evidence for quality/review/run checks.
- Confirm spec approval occurred before codegen.
- Confirm markdown-file guardrail was applied in dispatched prompts.

33
.factory/skills/inception/checklists.md
View File

@@ -1,33 +0,0 @@
# Cobb Checklists
## Preflight Checklist
- [ ] Run `droid exec --help` and confirm model IDs used in commands.
- [ ] Capture objective, scope, constraints, and expected deliverable.
- [ ] Create/update todo list before execution.
- [ ] Confirm policy precedence: user instruction > `SKILL.md` > `curated-playbook.md` > `checklists.md`.
- [ ] Add guardrail note: no unnecessary markdown files.
## Context Handoff Checklist
- [ ] Task objective and acceptance criteria included.
- [ ] Relevant file paths/modules listed.
- [ ] Exploration findings summarized with concrete evidence.
- [ ] Open questions and assumptions listed.
- [ ] Explicit do/don't constraints included.
- [ ] Requested output format and verification commands included.
## Stage Completion Checklist
- [ ] Spec was confirmed by user before codegen.
- [ ] Codegen model choice matches task size (large vs small).
- [ ] Quality checks executed (format/lint/typecheck as applicable).
- [ ] Reviewer pass executed and findings handled.
- [ ] Build/test/run checks executed and outcomes recorded.
- [ ] Final summary includes changes, validation evidence, and next steps.
## Interruption Recovery Checklist
- [ ] Resume session with `droid exec -s <session-id> --model <model-id> ...`.
- [ ] Re-validate model IDs with `droid exec --help` if session gap is significant.
- [ ] Reconfirm user priorities before continuing implementation.

87
.factory/skills/inception/curated-playbook.md
View File

@@ -1,87 +0,0 @@
# Cobb Curated Playbook
This document is the portable rulebook for the `cobb` skill. It is self-contained and does not rely on repository-local docs.
## Core Objective
Run a reliable multi-droid workflow for coding tasks with clear stage gates:
1. Explore
2. Spec
3. User confirmation
4. Code
5. Quality
6. Review
7. Run
8. Summarize
## Trigger and Identity
- Trigger word: `Cobb`
- Orchestrator name: `Dom Cobb`
## Model Routing
- Driver / Explorer / Quality / Runner: `custom:Kimi-K2.5`
- Spec/planning: `custom:Gpt-5.2`
- Coder (large changes): `custom:Gpt-5.3-Codex`
- Coder (small fixes): `custom:Kimi-K2.5`
- Reviewer (bug/risk pass): `custom:Opus-4.6`
Always confirm current IDs with `droid exec --help` before dispatch.
## Workflow Rules
- Start with Kimi as the driver.
- Exploration is mandatory; run one or more explorer prompts as needed.
- Build a context packet after exploration and pass it to spec/coder/reviewer.
- Confirm plan/spec with the user before any code generation.
- Use GPT 5.3 Codex only for large code generation tasks.
- Use Kimi for small edits and operational commands.
- After coding, run quality checks.
- Run a reviewer pass focused on correctness/regressions/risk.
- Run build/test/runtime checks before finalizing.
## Guardrails
- Always pass explicit `--model` for every `droid exec` command.
- Do not create unnecessary markdown files.
- Create markdown only when explicitly requested or required by the approved plan.
- Give non-explorer droids rich context to reduce repeated exploration.
- Do not use `--skip-permissions-unsafe` unless explicitly authorized.
- Do not push/deploy/run destructive actions without explicit user approval.
## Autonomy Guidance
- Default/no `--auto`: read-only analysis.
- `--auto low`: safe file edits and limited operations.
- `--auto medium`: development operations (install/build/local git).
- `--auto high`: high-impact operations; use only when clearly approved.
## Dispatch Contract
Every dispatched prompt should include:
- Objective and success criteria
- Allowed scope (paths/modules)
- Constraints and non-goals
- Expected output format
- Required verification commands
- Guardrail: avoid unnecessary markdown files
## Conflict Handling
If instructions conflict, use this order:
1. Latest explicit user instruction
2. `SKILL.md`
3. `curated-playbook.md`
4. `checklists.md`
If still unclear, stop and ask the user.
## Recovery
- Resume with `droid exec -s <session-id> --model <model-id> "continue previous task"`.
- Re-run `droid exec --help` after long interruptions.
- Reconfirm priorities before resuming implementation.

34
.factory/skills/inception/references.md
View File

@@ -1,34 +0,0 @@
# Cobb References
## Canonical Sources
- `SKILL.md`
- Trigger and orchestrator identity.
- End-to-end stage sequence and guardrails.
- `curated-playbook.md`
- Portable workflow rules and model selection guidance.
- `droid exec` usage and autonomy constraints.
- `templates/dispatch-prompts.md`
- Role-specific dispatch prompt templates.
- `checklists.md`
- Operational completion and recovery checklists.
## Precedence Rule
When guidance conflicts:
1. Latest explicit user instruction
2. `SKILL.md`
3. `curated-playbook.md`
4. `checklists.md`
If still ambiguous, pause and ask the user before moving to codegen or high-impact actions.
## Model Mapping Snapshot
- Driver / Explorer / Quality / Runner: `custom:Kimi-K2.5`
- Spec: `custom:Gpt-5.2`
- Coder (large): `custom:Gpt-5.3-Codex`
- Reviewer: `custom:Opus-4.6`
Always re-check mapping with `droid exec --help` in case IDs change.

105
.factory/skills/inception/templates/dispatch-prompts.md
View File

@@ -1,105 +0,0 @@
# Inception Dispatch Prompts
Use these templates when dispatching role-specific droids. Fill placeholders before sending.
## Global Prefix (prepend to every prompt)
```
You are operating inside the Factory Droid workflow.
Follow the provided objective and constraints exactly.
Do not create unnecessary markdown files unless explicitly requested.
Prefer using provided context; avoid redundant full-repo exploration unless required.
```
## Explorer (Kimi)
```
Objective: <task-goal>
Scope: <paths/modules>
Constraints: <must-follow constraints>
Explore only what is necessary and return:
1) Key findings with file references
2) Risks/blockers
3) Candidate implementation directions
4) Minimal assumptions that need user confirmation
```
## Spec (GPT 5.2)
```
Objective: <task-goal>
Context packet:
- Findings: <exploration findings>
- Scope: <paths>
- Constraints: <constraints>
- Open questions: <questions>
Produce a concrete implementation plan with:
1) ordered steps
2) touched files
3) validation strategy
4) risks and mitigations
Do not implement code. Ask for explicit user confirmation before codegen.
```
## Coder Large (GPT 5.3 Codex)
```
Objective: <task-goal>
Approved plan: <spec summary>
Allowed edits: <paths>
Verification commands: <commands>
Implement only approved scope. Keep changes minimal and coherent.
Do not create unnecessary markdown files.
After edits, report changed files and why each changed.
```
## Coder Small (Kimi)
```
Objective: <small-fix goal>
Approved scope: <paths>
Constraints: <constraints>
Apply a minimal fix, run required checks, and summarize impact.
Do not create unnecessary markdown files.
```
## Reviewer (Opus)
```
Review objective: find bugs, regressions, and missing validation.
Context:
- Change summary: <summary>
- Files changed: <file list>
- Expected behavior: <expected behavior>
Return findings ordered by severity with file references and actionable fixes.
Focus on correctness and risk, not style-only comments.
```
## Runner (Kimi)
```
Run verification commands for this task:
<commands>
Return:
1) command outcomes
2) failing checks with probable root cause
3) minimal next actions to reach green state
```
## Resume Template
```
Continue previous task from session <session-id>.
Current objective: <objective>
Previously completed stages: <stages>
Remaining stages: <stages>
Constraints still in effect: <constraints>
Do not create unnecessary markdown files.
```