agentic-rules-writer

Agentic Rules Writer

Generate a tailored rules/instruction file for any AI coding agent. Runs an interactive questionnaire, pulls the installed-skill and agent inventory from the using-ecosystem meta-skill, and writes the output in the correct format and location for the chosen agent and scope.

When to Use

• Setting up a new AI coding agent for the first time
• Creating team-shared project rules for consistent behavior across developers
• Adding personal dev-specific rules to a project (gitignored)
• After installing new skills to update the rules file with skill references

Quick Start

/agentic-rules-writer claude
/agentic-rules-writer cursor
/agentic-rules-writer codex
/agentic-rules-writer              # asks which agent

Phase 1: Agent Selection

If $ARGUMENTS is provided, map it to an agent from the table below (case-insensitive, partial match OK — e.g. "wind" matches Windsurf). If no argument or no match, present a selectable menu using AskUserQuestion (or the agent's equivalent interactive prompt tool).

Tier 1 — Full support with dedicated format/paths

Tier 2 — Supported with generic Markdown format

Other / Universal

For any agent not listed: write plain Markdown to a user-specified path. Ask the user for the output path.

See references/agent-targets.md for full details on each agent's format, paths, limits, and testing instructions.

Phase 2: Scope Selection

Present a selectable menu (using AskUserQuestion or the agent's equivalent) to ask the user which scope to generate rules for:

See references/agent-targets.md for the exact path for each agent + scope combination.

If the target file already exists, present a selectable menu to ask the user:

1. Overwrite — replace entirely with generated content
2. Merge — append generated content below existing content (separated by ---)
3. Abort — cancel and leave the file untouched

Phase 3: Workflow Questionnaire

IMPORTANT: Always present questions using a structured interactive menu, never as plain text. If AskUserQuestion is available, use it. Otherwise, use whatever equivalent interactive prompt tool the agent CLI provides. The goal is a selectable option list, not a wall of text the user has to parse and type answers to. Batch up to 4 independent questions per call when the tool supports it. If a question has more than 4 options, present the most common 4 and let the "Other" / free-text fallback cover the rest.

Wait for the user's answers before proceeding to the next batch.

Scope Matrix

Which questions to ask depends on the scope:

Rationale: Team-shared rules cover technical standards the whole team agrees on (stack, directory structure, commands, quality, testing, error handling, security, dependencies, branching, commits, PRs). Dev-specific rules cover personal workflow preferences (planning style, autonomy, boundaries, parallelization, task tracking, self-improvement, communication style, persona). Global includes everything.

See references/questionnaire.md for the full question reference with descriptions, option mappings, and example outputs.

Suggested Batching

For Global scope (all 20 questions), batch as follows:

• Batch 1 (Group A): Q1 (stack), Q2 (directory), Q3 (commands — free text)
• Batch 2 (Group B, part 1): Q4 (quality), Q5 (testing), Q6 (error handling), Q7 (security)
• Batch 2a (follow-ups): Q4 documentation follow-up
• Batch 3 (Group B+C): Q8 (dependencies), Q9 (branches), Q10 (commits), Q11 (PRs)
• Batch 3a (follow-ups): Q10 co-author follow-up
• Batch 4 (Group D, part 1): Q12 (planning), Q13 (autonomy), Q14 (boundaries), Q15 (parallelization)
• Batch 5 (Group D+E): Q16 (tracking), Q17 (self-improvement), Q18 (communication), Q19 (persona)
• Batch 5a (follow-ups): Q16 external tool follow-up
• Final: Q20 (additional comments — free text)

For other scopes, adjust batches to skip irrelevant questions per the scope matrix above.

Group A: Project Context

Q1. Primary stack Options (pick 4 most relevant, "Other" is added automatically): PHP+Symfony / TypeScript+React / Python+Django / Go / Rust / Java+Spring (If "Other", ask them to specify.)

Q2. Directory structure Options:

• Follow existing — always match the project's current directory structure and conventions
• Follow best practices — restructure toward industry conventions, suggest improvements
• Pragmatic middle — follow existing structure but suggest improvements when patterns are clearly wrong

Q3. Build/run commands Free-text. Ask: "What are the key commands the agent should know? (build, test, lint, dev server, deploy — leave blank to skip)"

• If provided, include verbatim in a ## Commands section in the generated file
• If blank, omit the section

Group B: Code Standards

Q4. Code quality bar Options:

• Staff engineer rigor — exhaustive edge cases, defensive coding, thorough documentation
• Senior pragmatic — solid quality with practical trade-offs
• Ship fast — working code with minimal ceremony

Follow-up: "Documentation level?" (Docblocks on public APIs / Inline comments for non-obvious logic only / Minimal — code should speak for itself)

Q5. Testing philosophy Options:

• Strict TDD — write tests before implementation, always
• Test alongside — write tests and code together
• Test after — implement first, add tests after
• Minimal — only test critical paths

Q6. Error handling Options:

• Fail fast — throw early, crash on unexpected state, surface errors immediately
• Defensive — handle gracefully, never crash, always recover
• Balanced — fail fast in development, handle gracefully in production

Q7. Security & secrets Options:

• Strict — never read/commit .env or credentials, flag potential vulnerabilities, OWASP-aware
• Standard — don't commit secrets, basic input validation at boundaries
• Minimal — just don't commit .env files

Q8. Dependency management Options:

• Always ask — never add or remove dependencies without explicit approval
• Ask for new only — can update existing versions, must ask before adding new packages
• Autonomous — can add dependencies freely

Group C: Version Control & Collaboration

Q9. Branch conventions Options:

• Type prefix — feature/, fix/, chore/, hotfix/ + description
• Ticket prefix — PROJ-123/description or PROJ-123-description
• Flat descriptive — just a kebab-case name, no prefix
• Other — ask them to specify

Q10. Commit conventions Options:

• Conventional commits — feat:, fix:, chore:, etc.
• Ticket prefix — PROJ-123: description
• Freeform — no enforced format

Follow-up: "Should the agent add itself as co-author on commits?" (Yes / No)

Q11. PR/MR creation Options:

• Structured template — ## Summary, ## Test Plan, linked issues
• Minimal — title + short description
• Don't create PRs — agent should never push or create PRs without asking

Group D: Agent Workflow

Q12. Planning discipline Options:

• Always plan first — enter plan mode for every task
• Plan for 3+ steps — plan mode only for multi-step tasks
• Minimal planning — jump straight to implementation

Q13. Autonomy level Options:

• Autonomous — fix bugs, failing CI, lint errors without asking
• Semi-autonomous — ask before destructive o

Content truncated.