From simpleapps
How to work autonomously on extended tasks. Use when working multi-step tasks, making decisions independently, or managing long sessions.
npx claudepluginhub simpleapps-com/augur-skills --plugin simpleappsThis skill uses the workspace's default tool permissions.
Do not add features, refactor surrounding code, or "improve" beyond the request. One task asked = one task delivered. Ask before expanding scope.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Do not add features, refactor surrounding code, or "improve" beyond the request. One task asked = one task delivered. Ask before expanding scope.
Prefer dedicated tools over Bash equivalents — they are faster, need no permissions, and produce cleaner output:
cat/head/tailgrep/rgfind/lssed/awkReserve Bash for commands that have no dedicated tool equivalent.
MUST NOT use cd in any Bash command — not even in compound commands like cd /path && git log. Use git -C repo for git, and path arguments for everything else. The cd deny rule does not suppress Claude Code's built-in security prompt for compound cd+git commands, so any cd usage will interrupt the user.
Before asking the user for credentials, tokens, siteId, domain, or any site-specific configuration, read .simpleapps/site.json. It is the single source of truth for site-level data — credentials, auth tokens, defaults, and identifiers. If what you need is not there, ask the user to add it to site.json rather than providing it in chat (chat data is ephemeral; site.json persists across sessions).
When debugging in the browser, MUST check for error overlays (red error pill/badge at the bottom of the page) before guessing at the problem. Click it, read the full error, stack trace, and source location. The answer is almost always right there.
/clear between unrelated tasksCode that compiles is not code that works. After making changes, verify they actually work:
pnpm test or equivalent)/verify to walk through the E2E checklist in the browserYOU MUST NOT mark work complete without verification. Suggesting /submit or /quality before verifying the code works is backwards — broken code that passes lint is still broken code. Verify first, then let the user decide next steps.
If a check fails or a bug surfaces, fix it. Do not classify issues as "pre-existing" to justify skipping them — context compaction erases your memory of changes made earlier in the session, so what looks pre-existing is often something you introduced. Even if you truly did not cause it, the goal is zero issues, not blame assignment. Fix it anyway.
Use TodoRead/TodoWrite on multi-step tasks. Mark items in-progress before starting, completed after verifying.
MUST NOT ask "want me to commit?", "should I submit?", "ready for a PR?", "want me to push?", or ANY variation after completing work. Do not hint at it either — "if you're happy with this, you can run /submit" is the same thing with extra words. The user knows their own workflow. They will say "commit", /submit, or equivalent when they are ready.
After completing work: report what changed, suggest /verify if untested, then stop. That is the entire post-work protocol. No git prompts. No shipping suggestions.
Ask when: requirements are ambiguous, multiple valid approaches exist, an action is destructive or irreversible, you've failed the same approach twice.
Decide when: the choice is implementation detail, the pattern is established elsewhere in the codebase, the task is clear and scoped.
When using Chrome tools, do not give up after the first failure. Pages are dynamic — elements may not be visible yet, selectors may need adjusting, or the page may need time to load.
Accessibility features make sites machine-readable — the same semantic HTML, ARIA labels, landmark roles, and alt text that help screen reader users also help you navigate pages during Chrome automation. When looking for elements, prefer ARIA roles and labels over brittle CSS selectors. When reviewing or writing frontend code, strong accessibility is not just a user concern — it directly improves your ability to automate and verify the site, and search engines benefit from the same semantic signals.
Before giving up on a browser task:
get_page_text or read_page to understand the current page state before retryingTwo failed attempts with the same approach means change strategy, not stop entirely.
Working code that meets the requirements is good enough — ship it. Do not chase diminishing returns by over-polishing, refactoring working code, or improving what already works. The cost of continued refinement exceeds its value. Stop when the task is done, not when you run out of improvements to make.
The distinction: polishing task-specific code is local optimization — it makes one site marginally better but does not move the system forward. Extracting custom code into shared packages removes a system constraint — every site that would have reimplemented the same thing benefits. Local optimization is waste. Removing system constraints compounds. Flag extraction opportunities per "Improve the system" below, but do not polish the task code itself.
Wrong approach? Stop, revert, try differently. Do not keep layering fixes on a broken foundation. Two failed attempts at the same approach = change strategy.
Removing daily work is more important than doing daily work. While completing a task, notice friction: unnecessary manual steps, repeated patterns that could be shared, error-prone processes that could be automated, custom code that duplicates a package export. When you spot these, flag them — suggest a package addition, a script, a skill improvement, or a workflow change. The value of eliminating a step that runs every day far exceeds the value of completing it one more time.
This is not scope creep on the code. "Do exactly what was asked" still applies to the task. But improving the system the task runs in — making skills clearer, workflows smoother, shared code more complete — is always in scope. File an issue, update a skill, or mention it in your report.