agentic-harness.pi

Drive a real browser with the browser_go, browser_see, browser_do and browser_check tools: navigate, read the page as an accessibility outline, query the DOM across frames and shadow roots, inspect one element's box and cascade, run expressions, press keys and gestures, wait for conditions, read console and network telemetry, emulate devices, shape the network, take screenshots, and form verdicts about accessibility, layout, design drift, visual diffs and performance. Use when asked to "open a page", "look at this site", "click the button", "what does the page say", "why is this element red", "check the console", "what requests did it make", "test it on mobile", "is this accessible", "did the layout break", "what changed visually", or any request that involves looking at or operating a web page.

How to audit a web page for accessibility with browser_check and browser_see: the keyboard walk, the axe and structural rule sets, reading order, live region announcements, contrast and target size. Covers what the tools decide, what they deliberately refuse to decide, and how to report findings without overstating them. Use when asked "is this accessible", "check accessibility", "run an a11y audit", "will a screen reader work", "can you use this with a keyboard", "check the contrast", "is this WCAG compliant", or when reviewing a change that touches markup, focus, colour or interaction.

Output contract for round-1 council reviewer subagents in pr-workflow. The JSON shape of findings, location kinds, thread-relation fields, and the verify_output self-check protocol. Loaded into each reviewer subagent via --skill.

Output contract for round-3 critique reviewer subagents in pr-workflow. The JSON shape of critique entries, position vocabulary, rationale requirements, and the verify_output self-check protocol. Loaded into each critique reviewer subagent via --skill.

Output contract for round-2 judge subagents in pr-workflow. The JSON shape of consolidated findings, attribution fields, the optional self-signal, and the verify_output self-check protocol. Loaded into each judge subagent via --skill.

Output contract for stack-wide judge subagents in pr-workflow. The JSON shape with per-PR and cross-PR findings, attribution fields, optional self-signal, membership rules, and the verify_output self-check protocol. Loaded into each stack-judge subagent via --skill.

Output contract for stack-wide reviewer subagents in pr-workflow. The JSON shape with per-PR and cross-PR findings, perPr key rules, cross-PR span fields, and the verify_output self-check protocol. Loaded into each stack-review reviewer subagent via --skill.

How to drive the `pr_workflow` tool: a conversation-first PR review system with multi-model council pipeline (fan- out reviewers, judge consolidation, optional critique, user synthesis) and posting to GitHub. Use when the user asks to "review PR N", "run a council review", "look at this PR", "post a review", or any request to read or comment on a pull request. Pairs with code-review-standard for evaluation criteria, comment-format for comment shape, and prose-standard for written voice.

Naming taxonomy for skills and extensions in this package. Domains, type suffixes, location rules and the decision framework for when to create a new skill, extension or add to AGENTS.md. Use when creating, renaming or reorganizing skills and extensions.

Structure of a quest README and the documents that live under it: frontmatter shape, the four core and four optional body sections, emoji glyphs, ID format, alias notation, Cast bullets and Journey entries. Use when writing or editing a quest README, a plan, research, brief or report document under a quest. Pairs with quest-convention for choices like kind, promotion and reordering. Follow the prose-standard for voice.

Operational conventions for the quest system: when to use a quest versus a subquest versus a sidequest, when to scaffold a plan or research document, how to reorder priorities, when to add optional sections, when to conclude versus retire, the resuscitate pattern. Use when driving the quest tool, deciding kind, promoting or parking work, or organising a project as quests. Pairs with quest-format for the on-disk shape.

Access Slack: search messages, read threads, send messages, send threads, edit messages, upload files, look up users and channels, manage reactions. Use when asked to "check Slack", "find messages", "search Slack", "send a message", "post a thread", "send these as a thread", "edit that message", "fix that message", "update what I said", "upload a file", "share this file", "attach this", "what did X say", "show me the thread", "who is", "react to", or any query about Slack messages, channels or users.

The single planning skill: how to plan collaboratively and how to structure the living plan document. Covers the staged plan workflow (think, draft, build), debating before deciding, the front-matter contract, the recommended sections, checkbox progress and deviation. Use when planning, designing before building, driving the plan tool, or writing a plan file. Works for code, investigation, writing and ops plans alike. Follow the user's prose standard for any text in the plan.

Command syntax for GitHub CLI operations. Heredoc format for PR and issue bodies, title conventions and metadata flags. Use when running gh pr create, gh issue create or any gh command with structured input.

Conventional commit message structure: types, scopes, subject and body rules. Use when writing a commit message or amending a commit. Pairs with git-cli-convention for command syntax and git-commit-convention for when to commit. Follow the user's writing voice and prose style guides for body text.

How to measure whether convention corrections keep recurring in the pi session logs, by category and by week. Use to record a baseline before the convention gates take effect and to re-run afterwards to confirm the recurring categories bend down. Pairs with the convention gates (pr-guardian, issue-guardian, commit-guardian, slack-integration) and the convention-context extension.

Issue body structure and narrative. The closed three-section body (Situation, Outcome, Acceptance), URI indexing and title conventions. Use when writing or editing a GitHub issue. Pairs with github-cli-convention for command syntax and markdown-standard for markdown structure. Follow the user's writing voice and prose style guides for issue text.

PR description structure and narrative. The closed three-section body (Situation, Resolution, Validation), URI indexing, self-review guidance and title conventions. Use when writing or editing a pull request description. Pairs with github-cli-convention for command syntax and markdown-standard for markdown structure. Follow the user's writing voice and prose style guides for description text.

Markdown structure rules: Title Case headings with their exceptions, the line-width target and its legitimate exceptions, reference-style links, fenced code blocks with language tags, tables and lists. Use when writing or editing any markdown file (README, AGENTS, docs, plans, skill files), or when adding a heading, link, table or code block. Owns markdown structure; pairs with prose-standard, which owns voice, grammar, spelling and punctuation.

Voice and style rules for all written output. Spelling (Canadian English), punctuation, tone and sentence structure. Use when writing or editing commit messages, PR descriptions, issue bodies, review comments, code comments, markdown, skill files, agent instructions or any other prose for humans or language models.

How to drive the `subagent` tool: spawn N pi processes concurrently for persona sweeps (security/performance/ readability of the same artifact), multi-angle investigation (data flow vs lifecycle vs config of the same bug), or fleet brainstorming (N answers from N models). Use when the user asks to "examine from various angles", "get multiple perspectives", "fan out across personas", "parallel investigation", "have N models try this", or any request that benefits from divergent independent passes. Pairs with prose-standard for written voice and any domain skills the personas should inherit.

Test-driven development methodology. Red-green-refactor cycle, when to stub, how to validate failure reasons, commit cadence. Use when implementing with TDD, writing tests first or driving the tdd_loop tool.

Conventional Comments structure for review feedback. Labels, decorations and tone. Use when writing review comments, giving code feedback or posting PR review observations. Pairs with code-review-standard for what to evaluate. Follow the user's writing voice and prose style guides for comment text.

How to research and present findings about a codebase. Reading code, tracing flows, summarizing architecture. Use when understanding, exploring or explaining existing code before proposing changes.

Access Google Workspace (Gmail, Calendar, Drive, Docs, Sheets, Slides). Use when asked to "check email", "read inbox", "get calendar", "what's on my schedule", "find in drive", "search drive", "read doc", "open spreadsheet", "show slides", "list emails", "emails from [person]", "send email", "reply to", "schedule meeting", "create event", "cancel meeting", or any query about the user's Google account data. Handles email, calendar, documents, and files.

Code design and style rules applied to all code. Readability, naming, structure, abstraction, testing and domain-driven design. Use when writing, modifying or reviewing code in any language. Follow the user's writing voice and prose style guides for code comments and doc comments.

Evaluation criteria for code review: test quality, implementation quality, naming, consistency, scope and PR descriptions. Use when reviewing code or a pull request. Pairs with comment-format for review comment structure.

Branch naming, creation and safe transitions. Use when creating a branch, switching branches, moving commits between branches or starting new work.

Command syntax for git operations. Heredoc format for commit messages, shell quoting and multi-line input patterns. Use when running git commit, git tag or any git command with structured input.

Operational commit rules: when to commit, what goes in each commit, commit frequency and history management. Use when committing code, deciding commit boundaries or managing git history. Pairs with commit-format for message structure.

Resolving rebase conflicts with design intent preservation. Use when rebasing, resolving merge conflicts or choosing a conflict resolution strategy.

PR merge strategy, branch cleanup and post-merge hygiene for any pull request. Use when merging a PR, cleaning up after a merge or deciding how to land changes. See github-pr-stack-convention when PRs depend on other PRs.

Stacked PR lifecycle: creating, retargeting, rebasing and merging PRs that depend on other PRs. Use when working with PRs based on other PRs or rebasing branches that have dependents. Pairs with github-pr-merge-convention for general merge strategy.

How to develop Pi extensions. Discovery workflow for TUI components, available APIs, composition patterns and common mistakes. Use when building or modifying extensions.

Keybinding system for Pi extensions. Rules, verb set, footer layout and conventions for panels, gates and interactive prompts. Use when writing or modifying extensions that have user-facing UI.

Pi session log format and extraction patterns. How to find session files, parse the JSONL structure, and extract user messages, tool calls, and errors. Use when analyzing past pi sessions or debugging session behaviour.

Managing items in GitHub Projects v2. Query project items, reorder them, and resolve project IDs. Use when working with GitHub project boards or reordering items in a project.

Managing sub-issues in GitHub Issues. Query, reorder, and create sub-issues using the GraphQL API. Use when working with parent/child issue relationships or reordering sub-issues within an epic.