(project) Daisy Mode - Autonomous feature implementation from branch creation through PR submission with CI loop integration
Implements features end-to-end from branch creation through PR submission with tests.
/plugin marketplace add panguin6010/daisy-mode-plugin/plugin install daisy-mode@daisy-modefull-feature-descriptionsonnetGoal: Implement the feature described in "$ARGUMENTS" completely and autonomously—from branch creation through PR submission with working tests. Emit a <pr>NUMBER</pr> tag to enable optional CI loop integration via stop hooks.
If no description is provided or the request is unclear, ask for details before proceeding.
<default_to_action> Implement changes by default rather than only suggesting them. Infer intent from the description and proceed autonomously. Use tools to discover missing details rather than asking unless truly ambiguous. Complete the full workflow: branch, code, tests, commit, push, PR, and tag emission. </default_to_action>
<use_parallel_tool_calls> When multiple independent actions are needed (e.g., reading multiple files, checking multiple directories), execute tool calls in parallel to maximize efficiency. Only call tools sequentially when later calls depend on earlier results. </use_parallel_tool_calls>
<thinking_process>
Before taking action, use a <thinking> section to:
After receiving tool results (especially test failures or file reads), reflect on what you learned and determine the best next action before proceeding. </thinking_process>
Start by understanding the environment. Check if this is a git repository, identify the default branch, detect the project type and testing tools:
git rev-parse --git-dir 2>/dev/null || echo "ERROR: Not a git repository"
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
git status --short
git branch --show-current
Detect project type by examining manifest files: package.json, Cargo.toml, go.mod, pyproject.toml, pom.xml, Gemfile, composer.json, etc. Infer the appropriate test command, linter, and formatter from project conventions.
If not in a git repository, stop immediately and inform the user.
From the feature description, intelligently infer the change type (feat, fix, refactor, chore), create an appropriate branch name in kebab-case (e.g., feature/jwt-auth-with-roles), and generate a conventional commit message (e.g., feat: add JWT authentication with role-based access control).
Explore the codebase structure to understand where changes belong. Follow existing patterns for file organization, naming, error handling, and documentation style. Add any necessary dependencies to the project manifest.
Write comprehensive tests that cover the primary use cases, edge cases, and error scenarios implied by the feature description. Match the project's existing test structure and conventions.
Run tests locally before committing. If tests fail, analyze the error output, fix the issue, and retry. Make up to three attempts to resolve failures before committing with a note about remaining issues.
Commit changes with a clear conventional commit message, push the branch with upstream tracking, and create a draft PR using gh pr create. The PR body should summarize what was implemented, what was tested, and any notable decisions or trade-offs.
Ensure code meets basic quality standards: no hardcoded secrets or credentials, no debug logging in production code, proper error handling appropriate to the language, type annotations if the project uses them, and formatting consistent with existing code.
Security considerations: validate inputs, handle errors gracefully, use parameterized queries, and never expose sensitive data in logs or responses.
If a CLAUDE.md file exists in the repository, read it first for project-specific guidelines and follow those conventions.
After successfully creating the PR, emit the PR number in this exact format:
<pr>NUMBER</pr>
This tag allows optional integration with stop hooks that monitor CI status. The stop hook can parse this tag, query GitHub's API for test results, and block the stop action if tests fail—providing error logs that trigger another iteration. This enables autonomous 6-8 hour sessions where Claude iterates on failures until all checks pass.
Note: The stop hook is external infrastructure and may not be configured. Do your best work upfront rather than relying on the hook to catch issues.
After completing all work, provide a concise summary in prose:
Confirm the branch name, link to the PR, and briefly describe what was implemented and tested. Note any issues encountered or areas that may need human review. Include the <pr>NUMBER</pr> tag at the end.
Do not stop until the branch is pushed, the PR is created, and the tag is emitted.
<long_horizon_persistence> This task may span multiple context windows as you iterate on test failures or refine the implementation. Focus on making steady, incremental progress. If your context budget is running low, save your current state (commit your work, note what remains) before the window refreshes. Never artificially stop the task early due to token concerns—complete it fully. </long_horizon_persistence>